Configuration of CDP and AIA for Issued Certificates
Certificate chain verification and revocation checking are very important parts of a certificate hierarchy. In order for an entity to validate that a certificate has not been tampered with, and is still valid, the entity needs to perform one required test and one optional test. It is required that the entity use the information in the root certificate to verify the certificate in question. This requires that the root certificate of the CA that signed the certificate in question be available. Secondly, some applications can be configured to check that the certificate is still “issued”. CAs have the option to revoke a certificate if they feel that the trust or security of the certificate has been violated. Perhaps the certificate was issued to an employee who was terminated. Revocation checking requires the presence of a Certificate Revocation List (CRL). On the CA, the administrator revokes a certificate by adding the certificates serial number to a list of revoked certificates. This list is then stored in a location that can be accessible to clients. Clients that require revocation checking must be able to locate a current CRL before they will accept a certificate.
Certificate chain verification is accomplished through the use of two fields, stored in certificate. These fields are the Authority Information Access and CRL Distribution Points. These fields tell the operating system where to find a copy of the root certificate used to sign the certificate being tested, as well as where to find a current CRL. In certificate services, these locations can be any valid URL including HTTP, FTP and UNC locations. If the CA or the clients participate in Active Directory, then this information can also be stored in Active Directory using an LDAP location. By default, Windows XP and later will check all locations in the CDP or AIA, plus the local certificate store and Active Directory if the computer is a member of an Active Directory domain.
Shown below is an example of what these fields look like when included in an issued certificate.
In order to configured this information to be included in certificates issued by our root CA, we must list the locations that AIA and CDP information can be found. This is done on the extensions tab of the CA property page. While there are many configuration options for both the AIA and CDP extensions, they are simplified when configuring a root CA. Generally, unrelated paths will be included for redundancy, and both will point to a web server. The web server can be any web server that is capable of serving a file. A sample CDP path is shown below.
Once your root CA configuration is complete, you only have to issue certificates to subordinate CAs. It is important to remember that if you fail to configure your root CA correctly, your subordinate CAs will be unable to start and the only solution may be to start over from the beginning. In the next article in this series, we will be looking at the configuration of a stand alone policy CA. A policy CA is used in many PKI implementations to provide rules and constraints to subordinate CAs.