I am trying to implement signed code for some PS scripts, and I have a question about trusting certificates.
I know the "right" way to address this is for IT to use Group Policy to trust the certificate office wide. But many of my customers just don't really have that option. My thought is to provide instructions on using CertUtil.exe to do the job, but I wanted to be 100% sure that adding to trustedpublisher this way still results in the certificate being validated by the issuing authority at startup or login, so a revoked certificate in trusted publishers would in fact not be trusted, correct?
Also, give that the tool to be run is a management tool, my initial thought is to use the tool to drive CertUtil.exe. Basically the first time you use it it adds its own certificate, so you get some user interaction required on first use only. But the idea of code creating a trust for itself seems potentially sketchy, and would raise a little flag for me if I was on the other side wearing my IT hat. So, from a PS distribution model standpoint, is setting up one's own certificate considered appropriate, or verboten, or something of a gray area?
If I recall correctly revocation is almost immediate, with a possible short time lag due to pre-fetching. you can find more info on how exactly revocation is handled here - https://technet.microsoft.com/en-us/library/ee619754(v=ws.10).aspx
As far as adding your own cert I don't see an issue with it but if they require code signing for scripts it won't be able to do it's initial launch, personally I'd send the certutil stuff as a separate script (potentially a batch file) and keep the code you are actually sending over all signed.
Related
I've been writing client certificate code for iOS using many of the resources here: iOS Client Certificates and Mobile Device Management and I've broken out the process to these steps:
Get the Cert via email or AppConfig
Store the Cert (securely)
Extract Identity and Trust from the Cert.
Intercept failed web requests, create NSURLConnection to manually handle auth responses as per Eskimo's advice.
Turn Identity and Trust into the auth response challenge.
My problem is step 2. SecPKCS12Import function appears to automatically add Identity to the keychain as well as return all Identities and Trusts from the certificates, thus eliminating the need for the convenience function often given ExtractIdentityAndTrust().
But on my 2nd run, I will need the Identity and Trust, not just Identity. My current plan is to store the entire cert raw using SecItemAdd, test for duplicates and use it, but I feel like I should be able to just use SecPKCS12Import then later grab it without also using SecItemAdd.
The documentation that is most confusing is SecPKCS12Import, and I would like a clearer understanding of what it does vs secItemAdd, and if secItemCopyMatching() is the same in the end just to grab the certificate. Is Trust not needed or am I just being literal and it's stored with the identity?
The general save, use, store, grab is working, but I'm using NSData and would prefer to store it correctly
I eventually became more familiar with the KeyChain and Identity vs Trust and learned this:
The Trust is a Cert stored in a place that determines who your custom Certificate Authorities are. It only needs to be tested once, which is why it isn't stored.
Storing the Identity is also a certificate, but needed for later. The keychain considers Certificates/Identities to be a Special/Unique thing so it is stored as its own thing, which is why all the keychain code looks different than just securing a password.
Basically, storing the Trust is unnecessary for future reference, but should be checked for good practice. I personally think an expiration might be handy
I want to provide some administrative services that will be implemented against the Office365 PowerShell, but I don't want to store decryptable administrators credentials - is there any option for authenticating without direct usage of the credentials? I am thinking about something like OAuth or another application key system.
Not 100% clear from the question but since you don't want to store creds I assume that this will be running on client computers rather than on systems that are directly under your control. I can think of two options but they both add considerably to the complexity of a script like this.
Option 1
Split your script into 2 pieces, one set up as a web listener on a server that is running with elevated privileges and the other running on the system where you want the script to be placed that makes REST calls to your web listener, this lets you only expose the functions that you actually want the lower-privileged script to have access to without having to deal with storing the creds. This is more complex to set up but doesn't require anything third-party to be in place.
Option 2
Use a privledged identity management system(I'm most familiar with CyberArk but any of them should be ok for this purpose) to store the creds, You would then sign your script with a certificate and set the identity manager to only allow a process signed with that cert and connecting from a known valid IP to access the credential, again using a web call. This is easier to do once you get the PIM installed but that can be a massive headache to do properly, not to mention expensive.
Hope I understood the problem correctly and that one of these methonds helps you.
SignedCms.ComputeSignature(cert) is very slow at the first request (rather intermittent) ,sometimes taking 20 sec. Tried the solution below, but didnt work since we cannot avoid that part of signature.
Message Signing using X509 certificate
Can anyone please throw some light on why this statement is very slow and is there any resolution for it.
Most likely this issue is related to signer (and counter-signer, if available) certificate validation, which requires chain building and revocation checking by downloading required objects (certificates, CRLs, OCSP). Network retireval may cause such delays. In addition, there might be issue with CDP/AIA extension URLs which contain inaccessible URLs.
What I would suggest to do: extract signer certificate to a file and run certutil command against this file:
certutil -verify -urlfetch path\signer.cer
and examine output. Pay attention to URL retrieval information. If presented, repeat this command against counter-signer (timestamp) certificates. If necessary, post certutil output here to get additional help.
I've been included in an analysis project or "cleaning up" of information which includes fields from certificates. I don't know how to access the actual certificates. I'd like to learn as much as I can about how/what can be verified in relation to a certificate. (I'm not doing security work, I just need to read the information.)
I have several spreadsheets with information including certificate data, all different sources with different fields. I'm trying to consolidate this information into a single table with as much verified as possible. Most records have Control Name, Serial Number, URL, etc., but based on the inconsistencies throughout other fields I think wrong or incomplete data has been added.
For instance, I'd like to verify that the expiration date on a spreadsheet is what is actually on the certificate. It also looks like one of the spreadsheets converted long serial numbers into a numeric data type, truncating(all 0's) the last half of the SN. Is there a way to look up all of a CN's certificates issued by a CA?
I'm very new to this, any tips would be appreciated.
Thank you
There is no general, public way I know of.
However, you might be able to get in touch with some CAs and do a research cooperation, but I doubt it. Handing out certificates to somebody else could be a privacy concern. And there's no chance you'll get certificates from all the CAs out there.
What you can do is obtain the certificates when they are used for publicly available services. For example if a certificate is issued to mail.example.com you could try to establish a TLS session to the host. You may have to try different ports, and maybe you are lucky and the host presents the certificate you are looking for.
We have a .net WPF application running as both XBAP and Desktop etc.I haven't signed any assemblies etc.My question is that
Q1.What kind of Digital Certificate do I need to purchase from VeriSign, Inc., or another certificate authority. to sign my application,use it as Authenticode Certificate (in clickonce) ?
Q2.Can I use this Digital Certificate to sign other applications like installers,assemblies,pdf etc?
Q3.Is one Digital Certificate enough for a company or I have to buy other?
Q4.What happens when the Certificate expires? (So is it better to not have it and screw yourself if no one is gonna hack and plant a virus in you app folder or something ???)
A1. You need a code signing certificate. They come in several flavours, and typically can be converted from one to the other, but it's probably easiest to get an Authenticode one rightaway.
A2. You can use the same cert to sign installers and assemblies (and any .EXE, .DLL, .OCX file). I think the same applies to .PDF, but I've never used that.
A3. I'd go for a single cert for your company.
A4. When the cert expires, you cannot use it for signing anymore. However, as long as you use a timestamping service when you sign your code, already signed files remain valid.
A1: You need code signing certificate. You may choose any provider, but do notice that not all of them are recognized by Windows as "trusted". Among trusted and cheaper ones (cheaper then VeriSign) there is Comodo.
A2: Yes.
A3: One is enough.
A4: You will not be able to sign new code. Old code will remain signed if you used timestamp server (you'll get location of one with certificate). If you opt not to use timestamp server, certification will remain valid, but users will get message that it it expired.