Forum Discussion
The PowerShell script that's worked for 2 years to find a signing certificate, stopped working
I also meant to add: is there some reason Set-AuthenticodeSignature won't work for you?
The only gap I see between it and signtool.exe is the ability to control the timestamping algorithm, but I wouldn't have thought this would have mattered.
It would be a little easier/more readable to use Set-AuthenticodeSignature but if you need that finer-grain control from signtool.exe then that's fair enough.
Cheers,
Lain
Hey, Rod. Here's some short-form responses.
Sort-Object
Expanding on my "Sort-Object" comment, this is what I meant:
Going from this original line:
$cert = ls cert:\ -Recurse -CodeSigningCert | ? {$_.Verify()} | Select -First 1
To this:
$cert = ls cert:\ -Recurse -CodeSigningCert | Sort-Object -Property NotAfter -Desc | ? {$_.Verify()} | Select -First 1
This ensures that the command returns the certificate with the furtherest-away expiration date, and not just any randomly-ordered matching certificate.
CRL distribution point
An example of a CRL distribution point is shown below. If your TFS host can't reach the CRL location (multiple CRL locations can be listed, meaning you'd want to check them all) then the call within your command line to the .Verify() method will fail, which is why I listed this as an option.
If the CRL begins with "http" then you can simply try accessing that location (including the file name) from a browser. If it begins with ldap: then perhaps for now, just skip this test (you'd need to leverage something like certutil.exe to run this test) since there's a good chance this won't be the issue anyway.
Example of plugging a http-based CRL into the browser bar to test existence:
Active Directory policy endpoint
If you don't see a "Certificate Template Information" line as shown below in the Details tab, then just ignore this part as it's most likely you're not using an Active Directory policy anyway.
If you do see such a line, then you will have a policy and therefore an endpoint but as with the "ldap" statement above, I'd just assume this is working for now as it's not as easy to test as a "http"-based CRL.
Summary of my initial thoughts
My thoughts at this early stage are:
- I doubt the script is actually the issue;
- I feel like it's either selecting an expired certificate (i.e. current date > NotAfter value on the selected certificate); or
- All of the CRLs from the chosen certificate are unreachable.
While I don't think the script will be at fault, it does bother me that it's scoped to search both the local machine store (which is what I'd expect to see) but also the current user store (which I didn't expect to see.) That doesn't sit well with me since if the script selected a certificate from within the user store, I'd expect that TFS could not read it - at least not from where it sits in the user store.
While that bothers me, it's also not a reason for the call to .Verify() to fail, which your testing shows is happening (i.e. ".Verify()" will be returning $false.)
Purely as a testing exercise, you can run the following. If all the results back as "False" then that serves as confirmation about what you've hypothesized regarding the "null" return value:
cert:\ -Recurse -CodeSigningCert | ForEach-Object {$_.Verify()}
Naturally, there are other options but these are my initial guesses, as per my first response.
Make sure you take a peek at Event Viewer for clues, too.
Cheers,
Lain
Edited: Corrected multiple typos.
LainRobertson I'm at my work laptop so I can try what you suggested. I took this line:
ls cert:\ -Recurse -CodeSigningCert | Sort-Object -Property NotAfter -Descending | Select -First 1
Then changed it, per your suggestion, to this:
ls cert:\ -Recurse -CodeSigningCert | Sort-Object -Property NotAfter -Descending | ? {$_.Verify()} | Select -First 1
The first line does return 1 of the records from the Certificate store. The second line doesn't return anything from the Certificate store. And I know there's a valid certificate in the certificate store that won't expire until June of 2023.
Hey, Rod.
The key difference between those lines is that your first line doesn't contain the call to ".Verify()", which almost confirms what I expected to be true, which is that the returned result is failing the call to .Verify().
Try running the following (which is mostly the same as what I posted earlier) and see if it returns True or False.
$cert = ls cert:\ -Recurse -CodeSigningCert | Sort-Object -Property NotAfter -Descending | Select -First 1; $cert | fl Thumbprint, NotAfter, Subject, @{n="Verified"; e={ $_.Verify() }};You should see output like the following, with the value for Verified being what you're most interested in.
Failing verification doesn't mean the certificate is invalid (though it could be.) It just means the verification process failed, which takes me back to things like ensuring the CRL can be reached, etc.
For now, you're only interested in seeing if Verified is coming back as false. If it is, then that's why the script is failing to find a certificate to assign.
Cheers,
Lain
Edited to correct the two-line PowerShell example.
- Hi Lain,
I ran the two lines of PS script you gave me. It didn't produce anything, after running the second line. After running it, PS just returned to the PS prompt.My apologies, Rod.
I'd made a copy-and-paste fail since I forgot to remove the .Verify() section from line 1.
I've updated line 1 now, so perhaps try it again.
From what you described about not getting anything at all though, I expect the result will indeed be False.
Cheers,
Lain
