Checking for SHA1 Signatures using PowerShell

 

Certificates are complex. They can be tough to view and difficult to understand. This is even more true when the topic is related to determining certificate signature details. In the past, there were really no reasons to look so closely at an issued certificates signature details. That has all changed now in conjunction with an ever changing security landscape.

Microsoft has plans to deprecate the use of some certificates which have SHA1 signatures. The plans are nuanced by date and the deprecation strategy does not apply to just any certificate. The current plans apply to server authentication certificates (certificates which are used to secure network communication using TLS) as well as to the certificates used to sign executables in Windows (code signing and time stamping certificates).

Of course, the authoritative place to find out about the Microsoft strategy for SHA1 deprecation is https://aka.ms/sha1 .

We’ve done a pretty good job of preparing people for the scenario of getting a Microsoft certificate authority (Windows Server with the Active Directory Certificate Services role) updated to not issue SHA1 signatures.

Earlier this year my colleague Rob Greene published a blog post about migrating certificate authorities from SHA1 to SHA2 hashing algorithms for future issued certificates. That blog post can be found at the AskDS TechNet blog here.

The migration can be complex so my colleague Jim Tierney wrote a detailed blog on migrating a two tier CA hierarchy from SHA1 to SHA2 on the AskDS blog here.

We are left with the question of “does the certificate I’m using have a SHA1 signature?”. That’s a tough question to answer.  Due to the complexity of certificates and PKI in general it can be confusing and difficult to determine whether the SHA1 deprecation applies to a particular certificate or code signed application.

To help make that easier I wrote a PowerShell script. The script is available in the TechNet script gallery at this link.

There are two scenarios this script checks. One is a server auth (TLS) certificate which is signed with SHA1, and the other is an application (EXE) which is signed with SHA1.

More details of the script:

• The script can check either an exported certificate (filename.cer) or a signed executable but not both at once.
• The script checks only one certificate or executable at a time.
• The certificate to check in the Server Auth scenario must be exported to a file and the file path must be specified.
• The script reviews the specified certificate to make sure it is a Server Auth one.
• The script checks the signature to make sure that the signature algorithm matches one of the OIDs below

• 1.3.14.3.2.29, 1.2.840.10040.4.3, 1.2.840.10045.4.1, 1.2.840.113549.1.1.5, 1.3.14.3.2.13, 1.3.14.3.2.27

• The script has two switches and a Path parameter

• File: The is the default. This tells the script you will be checking an exported certificate file.
• EXE: This specifies that you will be checking an executable’s code signing and time stamping certificate(s).
• Path: The path to the exported certificate or executable to check.

• The script checks for both code signing and time stamping certificates and will display either or both if found.

Here’s an example of using the script when SHA1 was not found:

And an example if using the script where SHA1 was found:

I hope this script helps you gain some clarity on whether your environment or services are at risk from SHA1 so you can prepare for the SHA1 deprecation as easily as possible.