Wednesday, January 4, 2017

PKI - ADCS: certificate validation (review)

In what might seem like reverse order (going backwards), after my previous blog post about certificate revocation, I'm going to review some aspects of certificate validation in general.

I will address the subject in this form...

Certificate validation provides an answer to several questions (not necessarily in this order):


Certificate format and content (X.509)

Does the certificate being validated respect the X.509 standards? Are all the required fields present and do they contain valid information?

If, for example, the certificate had no subject name or expiration date at all, the certificate would be rejected because these are necessary fields.

Trust

Is the certificate trusted? In other words, has it been issued by a certificate authority (CA) that is trusted? Trust is established by the presence in the client certificate store of the certificate of the issuing CA and the certificates of any other CAs situated above the issuing CA in the PKI hierarchy (a root CA for example, or possibly a "policy CA" in more complex PKI implementations).


Digital Signature

Is the digital signature correct?


Revocation

Has the certificate been revoked? Revocation checking was addressed in my previous blog post.


Expiration

Is the certificate still within its validity period?


Certificate chaining

Are the other certificates in the certificate chain valid? When the application is presented with a certificate (when accessing a website for example), it must not only validate the certificate of the web server but will attempt to access the certificates of the issuing CA and of the root CA (assuming a 2-tiers PKI). The entire validation process is repeated for each of these certificates.

This is called the "certificate chaining process" and is performed by the "certificate chaining engine".


***


Concerning certificate chaining, how does the engine locate the certificate of the issuing CA (assuming it is even present in the local certificate store)?

It attempts to match certain properties of the certificate being validated with corresponding properties of the issuing CA certificate, for example the subject name or serial number.

***

Where do we place CA certificates (and CRLs) so applications can access them?

We can place these items in a web share (accessed via http) or in Active Directory (accessed via ldap) or both.

A simple file share is no longer an option for AIA and CDP publication points. On the other hand, it can be used by CAs to publish certificates and CRLs to the web share. In that case, we would use the UNC path to the folder shared in IIS.

Some considerations...

  • HTTP will function for all clients and is the preferred method. LDAP will function only for domain-joined Windows machines (at least by default and without granting anonymous access to unauthenticated users). If both locations are used, HTTP should be used first. This is achieved by making it the first URL in the AIA and CDP properties of these registry keys (on the issuing CA):

HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<Name of CA>\CACertPublicationURLs

HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<Name of CA>\CRLCertPublicationURLs

Note: we can configure these values after the installation of the CA with a script so that all certificates issued afterwards will contain the proper values. We can adjust these values later (with the script or manually in the registry) but certificates already issued will have the old values and will most likely need to be re-issued).

  • If clients use certificates outside the internal network, the AIA and CDP publication points must be accessible externally. In this case, http would be the better access method, either alone or with priority over ldap, since we would probably not want our domain controllers to be directly accessible from the outside world.
  • The certificate chaining engine will attempt to access the first URL for 10 seconds and if that fails, the second URL (if present). If we have many non-Windows clients, that is why would should place the http url first (assuming we use ldap at all).
  • As stated in my blog post on certificate revocation, delta CRLs are almost never needed. 


***

If the certificate is considered invalid, what will happen? It depends on the application verifying the certificate. It may display a warning but allow us to ignore it and proceed or our attempt to establish a connection may fail altogether.

No comments:

Post a Comment