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.

Warning: this post is the shortest post in the entire blog.

Microsoft announced a deprecation policy for certificates signed with SHA1 (sha1RSA) signature algorithm. The algorithm should not be used after January 1 2016. US NIST Guidance has counseled that SHA1 should not be trusted past January 2014 for the higher level of assurance communications over the US Federal Bridge PKI.

More on Windows PKI weblog: SHA1 Deprecation Policy.

Disclaimer: this article is a rewritten, updated and clarified version of the article posted by John Morello: How EffectiveDate (thisupdate), NextUpdate and NextCRLPublish are calculated.

This article is also available on TechNet Wiki.

This article describes how CA server calculates estimated CRL validity. By default, CRL validity is configured in a safe manner, so everything works without administrator interaction. However, if you are an experienced PKI administrator and plan custom CRL validity, it is important to understand how validity is calculated.

Time by time I receive questions about difference between current time on CA server and actual signing time which is included in the NotBefore (Valid From) field in the issued certificates. Most users notice that Valid From field is set 10 minutes prior to current time and attempts to find possible issues with time synchronization.

Don’t worry, it is expected behavior. By default Microsoft CA sets Valid From 10 minutes before current time. To explain this we need to recall time difference allowed in Active Directory domains. As you may know, Key Distribution Center (KDC) allows time difference between KDC time and remote service that utilizes Kerberos up to 5 minutes (by default) in each direction.

And now consider the following scenario: we have three servers: remote service, KDC and CA server. Current time at remote service is 10:00, at KDC 10:05, at CA 10:10. From KDC perspective both, CA and remote service are time-synchronized. It is easy to see that if CA server receives certificate request, the Valid From is set to: 10:10 minus 10 minutes = 10:00. This guarantees that issued certificate can be immediately used for authentication at remote service. Otherwise there could be issues that remote service considers presented certificate as not yet valid.

If you have configured custom time difference between KDC and clients, you should consider to configure your CA accordingly. Clock skew on CA server must be set as a double allowed time difference for Kerberos. The following command can be used to set new clock skew value:

certutil –setreg ca\ClockSkewMinutes 20

where 20 is new clock skew value. As always, you need to restart certificate services to apply changes:

net stop certsvc && net start certsvc

Update 06.04.2020: clarified the last section by mentioning that everything expressed in this blog post is primary opinion-based.

Update 16.06.2022: updated recommendations on HTTP URL host name.

Information in this article should be used only when you plan ADCS installation.

Hello Internet!

Today I’m going to describe one of the ugliest and, on the other hand, one of the most important topic in PKI — chain building and revocation checking and how to design/plan them by conforming best practices.