Implementing a PKI, Part III: Managing Microsoft Certification Services
In our third and final article about implementing a public key infrastructure, Eliana Stavrou explains the importance of managing certification services, and how to do it correctly. Will the administration procedures you have in place work -- or will they lead to security risks that you won't know about until it's too late? Read on to find out.
Contributed by Eliana Stavrou Rating: / 14 February 01, 2005
By now you should have implemented your own Certification Authority (CA) discussed in part I of this article, and configured your Internet Information Server (IIS) and client Web browsers discussed in part II of this article.
Beyond the implementation of the CA server, I feel that it is equally important to provide information regarding the management of the certification services. Without the proper management you create a leaky bucket; you may have developed a PKI infrastructure and think that you are secure, but without the proper administration of procedures you may end up with a bucket leaking security under your nose.
Web Interface
Clients communicate with the Certification Authority server using their Web browser. Recall that you may use the Web interface of Microsoft’s Certification Services in order to:
Request a digital certificate
View the status of a pending certificate request, or
Download a CA certificate or a Certificate Revocation List (CRL)
You may find the certification management console at:
Start -> All Programs -> Administrative tools -> Certification Authority
Through CA’s console you can manage the following procedures:
Pending Requests. When a user requests a certificate, his / her request will be taken to this section. After evaluating the provided authentication information, the administrator will decide on the trustworthiness of the user and whether to issue the digital certificate or not.
By right–clicking on the request at the Pending Certificates folder on the right pane of the console, you have the option to issue or deny the certificate. Based on the evaluation, you could choose one of the two options.
Issued Certificates. All the digital certificates that are issued by your CA server will appear in this section. If you need to revoke a certificate, select it, right-click on it, select All tasks and then Revoke.
Revoked Certificates. In several cases it may be required to revoke a digital certificate in order to maintain the integrity of your PKI; for example, revocation occurs when an employee leaves the organization or when a user loses his / her private key, or if the private key is compromised. Every time you revoke a certificate, it is added to the CA’s Certificate Revocation List (CRL). I believe that this functionality is vital for maintaining the security achieved through the usage of digital certificates, thus this subject will be discussed in detail in a later section.
Failed Requests. In cases where the provided information was inadequate or the trustworthiness of the client cannot be verified, the administrator rejects the request. If you want to issue the certificate at a later time, right-click on the request, select All tasks and then select Issue.
On the right pane of the console you may see several attributes such as the request id, revocation date, requester name, binary certificate etc., depending on the option you choose (Pending, Issued, Revoked or Failed).
The following figure presents a snapshot of the Certification Authority console.
As I stated earlier, when a certificate is cancelled it is added to the CRL. Each certificate includes a CRL distribution point and cannot be modified after a certificate is issued. The CRL distribution point is used by the client programs that use digital certificates in order to specify the validity of the certificate. If a certificate’s serial number is included within the CRL, then the client marks the certificate as invalid. Doing so, you cannot use a revoked certificate for signing or encrypting any messages. However, you can use it for decryption.
A CRL is automatically published after a specified period of time. You may set the CRL’s publication interval by right-clicking on the Revoked Certificates folder, selecting Properties, and on the CRL Publishing Parameters window setting the publication interval. It is recommended that you set the publishing period between 90 and 180 days, because revocation of a certificate is usually a rare operation.
As long as the client program has a valid CRL in its local cache, it will not attempt to retrieve another CRL from the CA which publishes it. However, if a CRL is absent or is not updated, the client program could not use the certificate because it cannot verify its status.
In addition, you may use the CRL Publishing wizard to manually publish a CRL before the scheduled publication period. However, client programs that have a cached copy of a valid CRL will continue using it until its expiration period, even though a new CRL has been published. The client program will use the new CRL after the expiration of the first one.
If you need to set the new CRL in effect immediately, you must open Internet Explorer and select Internet Options -> Content tab -> Clear SSL State, in order to remove all client authentication certificates from the Secure Sockets Layer (SSL) cache.
You may need to modify some properties on the digital certificate for smooth operation of the certification services.
To access the digital certificate’s properties, right-click on the local Root CA and go to <Properties> from the CA’s console.
Policy Module
Under the Policy Module -> Request Handling you could set the action required when a certificate request is received.
There are two options when a certificate request is received:
Set the certificate request status to pending. The administrator must explicitly issue the certificate.
Follow the settings in the certificate template, if applicable. Otherwise automatically issue the certificate.
I recommend that you select the first option.
CRL & AIA Distribution points
Click on the Extensions tab that provides information about the CRL Distribution Points and the Authority Information Access (AIA).
Depending on your implementation, you may need to change the distribution points for the CRL and the AIA included on every issued certificate. I covered CRL in a previous section so I will just explain what AIA is.
The AIA distribution location allows the client program to obtain a current copy of the CA’s current certificate. CA certificates are required when a certificate chain is built. Chain building is performed as part of the certificate verification process.
Follow the steps provided below to configure the distribution points for CRL:
Remove all the CRL distribution locations, except the local CRL distribution point.
DO NOT remove the local CRL distribution point location. The local distribution point is similar to the following path: C:\Windows\System32\CertSrv\CertEnroll\RootCA.crl. The CA uses the local CRL to validate all certificates that are generated before the certificates are issued to users. The local path is not included in the CRL distribution point extension of issued certificates.
On the Extensions tab, in Select Extension, select CRL Distribution Point (CDP).
In Specify Location from which users can obtain a CRL, select one by one the CRL distribution locations (except the local location), click Remove, and then click Yes.
After you remove the locations, the remaining list of CRL distribution points will be similar to the following figure.
Next, you have to specify the distribution locations (HTTP or LDAP) you are going to use for the CRL publication. It’s best to use an HTTP location when it’s critical not to have any latencies or when clients are not joined in an Active Directory; HTTP locations generally do not replicate and do not have latency issues, whereas an LDAP distribution point might be located in a distributed directory service, like Active Directory.
Click Add, and in Location give the CRL distribution location, and then click OK. Repeat for each type of access protocol if you wish to support more than one protocol.
Now you must configure some more properties about the CRL publishing. The properties must be set for every CRL distribution point path.
Select a path one-by-one.
For each path, and while on the Properties tab, select or clear the check box that is listed in the previous table, depending on the type of path, and then click Apply.
The procedure to configure AIA extensions is the same as the procedure to configure CRL distribution point extensions.
However, you must specify the following configuration parameters that control how the AIA extension is used by the CA in issued certificates. You must set the properties for every AIA path that is specified on the Extensions tab.
Table:AIA Distribution Point Properties
Conclusions
With this article I have completed the discussion on implementing and configuring your own Public Key Infrastructure (PKI) using Microsoft Windows Server 2003.
As I stated several times, a PKI is an essential technology for enhancing the security of your organization as long as you know how to use it. Therefore, be sure before implementing your PKI that you know what it is, how it is used, how to implement and configure it and above all have a management strategy in place.
If you need any further assistance on the subject, please don’t hesitate to contact me; I will be very happy to help you.
Windows Security 
Implementing a PKI, Part II: Configuring IIS 6.0
