Hello S-1-1-0, CryptoGuy is back with some good news!

About two years ago Windows PKI team posted about a SSL certificate expiration checking tool: Verifying The SSL Certificate Expiration with a tool. However, the download link is broken and PKI blog writers aren’t responsive, so there is no chance to get the utility. Although I have this tool, it is useless a bit more than completely. This is because the utility just checked leaf certificate for expiration without performing any additional checks.

A week ago I decided to make my own tool with “Black Jack and Hookers”. For a first attempt I asked myself to implement the following wishes:

  1. Validate the SSL certificate and validate all certificates in the chain for possible errors;
  2. Implement certificate expiration checking (as in original tool). Certificate expiration should be checked for all certificates in the chain;
  3. When we connect to a host, it may decide to redirect us to another site. Say, we connect to paypal.com, the server will redirect us to www.paypal.com. The fact is that these two servers may use different certificates (as is the case for paypal.com). Therefore, the tool must process all redirects and collect certificate status information for all of them.
  4. Write trace/debug log for each processed entry;
  5. Provide an ability to save server list to a file and read the list from a file.

It is enough for a simple utility. Maybe.

After a week I ended with a tool that was written in WPF and .NET Framework 4.0 (Client Profile) which looks as this:

image

I decided to retain original tool UI concept, just added a tab control under grid splitter which will contain extended information. We can add multiple entries and check all, or selected entries. Here is a simple example:

image

Here we see trace log and the status of the certificate. Trace log contains very useful debugging information you may need. Once scanned, you can switch to Certificates tab and review all SSL certificates:

image

Also, you can view all certificates in the chain by clicking View Certificate button. The root node of tree view contains an URL (there is no certificates) and nested elements are chain certificates. If we are redirected, we may see the following information:

image

We see that when you enter “paypal.com” in the web browser, we are redirected two times and three SSL handshakes are occurred. What if something went wrong:

image

We see the following errors: partial chain (one or more intermediate/root CA certificates are missing and cannot be retrieved) and offline revocation (revocation information is unavailable). This means that web browser will most likely reject this certificate. Look at the following figure and compare it with previous:

image

In the first figure, we see red errors in the “Native errors” textbox and in the second figure they appear in the “Propagated errors” and are in orange. When you see red errors (native), this means that these errors came from selected certificate (intermediate CA, in the first figure). Propagated errors are errors followed from up-level certificates in the chain. In the second figure, I selected leaf certificate and see that the certificate itself is ok, but some upper certificates are not. As per RFC5280, effective certificate status is: current certificate status plus all statuses from upper certificates in the chain.

And the last note. In the Options menu, you can enable strong Server Authentication EKU checking. Normally, the tool behavior is the same as in Internet Explorer: verify if Server Authentication usage is presented in the SSL certificate’s Enhanced Key Usage extension. However, Internet Explorer and most other browsers do not check whether the certificate (along the entire chain) is valid for Server Authentication usage. For example, if you enable this option, some SSL certificates will fail. For example, login.live.com will fail:

image

Actually, SSL certificates issued by VeriSign (which are issued by a SSL SGC CA) are not valid for any particular usage.

A bit of theory. Once again, RFC5280 dictates the rules about how certificate chain should be built and verified. Generally speaking, if some sort of restriction (which includes, but is not limited to: Application Policies constraints, Certificate Policies constraints, Name Constraints, etc.), all subsequent certificates in the chain must match these restriction. Let’s examine root certificate, it is restricted to the following EKU’s (via extended properties):

  • Server Authentication
  • Client Authentication
  • Secure Email
  • Code Signing

however, intermediate CA certificate contains the following usages in the EKU extension:

  • Unknown Key Usage (2.16.840.1.113730.4.1)
  • Unknown Key Usage (2.16.840.1.113733.1.8.1)

These usages stand for Server Gated Crypto (SGC) usage (it is another story, more details can be found in this great post: A quick look at the on-the-fly created server certificate by Forefront TMG 2010 RTM’s Outbound HTTPS Inspection). As already said, if a restriction is set in the root certificate, all subsequent certificates must match them. However, intermediate CA do not contains any EKU listed in the root CA certificate.

When you perform scanning, you can see the progress of each item:

image

And the last word: when certificate (any certificate in the session is about to expire, then the entry (if there are no errors) is moved to Warning category:

image

Although, “AboutExpire” status is marked in red, it is not an error, it is just a warning.

And finally, download link:

>> SSL Certificate Verifier <<

the archive contains two files: verifier itself and PresentationFramework.Aero.dll which is a theme DLL for WPF (signed by Microsoft). DLL must be placed in the same folder as SSLVerifier.exe.

p.s. I accept feedbacks for the tool. Please, write in comments what you think about it.


Share this article:

Comments:

Peter

Hi! First of all: great tool! I like it! :-) I have tested it and I catched a bug. Where should I send the logs? Many thanks! Peter

Vadims Podans

Send them to "support & sysadmins.lv"

John Provencher

A suggestion: Import a list of machines from a text file or from Active Directory. Having to individually add machines (could be in the 100's) is cumbersome.

Vadims Podans

I published a new version on CodePlex (http://sslverifier.codeplex.com/), which accepts server list import from CSV.

Randy

I like the tool, is there anyway to export the results to be able to present to managers?

Vadims Podans

Can you file an issue on CodePlex page?

Warren

Hi. When I try run the application it just crashes. I downloaded the 32bit version from the codeplex site. Would love to get this application running

Vadims Podans

Did you download PresentationFramework.dll file from the download page?

elman

Hi. Great tool. Thanks. Thou I have one suggestion. I have SSL certificates for sites, where default page returns error messages, like 404 or 403. Certificate itself is valid (Certificate chain successfully passed all checks.), but servers are displayed in red. I would like to have an option to only check certificate and ignore http codes returned by server. Is this possible?

Vadims Podans

Currently, it is not possible. This fix was already requested, but I'm not sure when I can fix this.

Ken

Your download link is broken.

Ken

I should clarify, the link to VerifySSLCertificate.zip is broken from your PowerShell article. I meant to post this there.


Post your comment:

Please, solve this little equation and enter result below. Captcha