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.

Update 14.03.2013: added workaround information

SYMPTOMS

Consider the following scenario. You install and configure Certificate Enrollment Web Service (CES) against a Certification Authority (CA) that has spaces and other disallowed by HTML URL scheme characters in the certificate name. When you attempt to use the service for certificate enrollment, the following message appears:

Updated 20.06.2018: clarified the purpose of NTAuthCertificates DS container.

Hello folks! Today I want to explain in details about Active Directory containers related to ADCS (Active Directory Certificate Services), their purposes and how they work.

Intro

All ADCS related containers are stored in configuration naming context under Public Key Services container:

CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}

Since Public Key Services container is stored in configuration naming context, any it’s content is replicated between all domain controllers in the current forest (not only current domain) and are available to any client in the forest. This means that there is no way to limit PKI containers only to specific domain or domains.

Here is a screenshot from ADSIEdit.msc tool:

Hi again! Recently I faced an issue with my Test-WebServerSSL function which is also available in my Powershell PKI module.

Issue

In certain cases, the function returns certificate chain errors, while Internet Explorer (as well as other web browsers) works normally and do not report anything wrong. For example, you can open https://www.nic.lv/ web site without any issues in your web browser. When you run Test-WebServerSSL function against this web site, you get the following: