Verifying The SSL Certificates with a tool

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, the server will redirect us to The fact is that these two servers may use different certificates (as is the case for 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:


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:


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:


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:


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


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:


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, will fail:


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:


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:


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.


Peter 02.12.2013 20:35 (GMT+3)

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
Vadims Podans 02.12.2013 21:41 (GMT+3)

Send them to "support &"

John Provencher
John Provencher 12.09.2014 07:13 (GMT+3)

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
Vadims Podans 12.09.2014 16:54 (GMT+3)

I published a new version on CodePlex (, which accepts server list import from CSV.

Randy 28.02.2015 09:58 (GMT+3)

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

Vadims Podans
Vadims Podans 02.03.2015 06:24 (GMT+3)

Can you file an issue on CodePlex page?

Warren 09.04.2015 19:21 (GMT+3)

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
Vadims Podans 10.04.2015 00:32 (GMT+3)

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

A1 19.09.2015 18:53 (GMT+3)

Download link => 404 - File or directory not found.
Fix please

Vadims Podāns
Vadims Podāns 19.09.2015 19:13 (GMT+3)


elman 16.12.2015 18:44 (GMT+3)

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
Vadims Podans 16.12.2015 19:33 (GMT+3)

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

Ken 22.08.2016 22:01 (GMT+3)

Your download link is broken.

Ken 22.08.2016 23:31 (GMT+3)

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