Chapter 20 Introduction to Publishing Certificates and CRLs

In Certificate Management System, publishing refers to the ability of the Certificate Manager to publish certificates, CRLs, and other certificate-related objects to any of the supported repositories--an LDAP-compliant directory, a flat file, and an online validation authority--using the appropriate protocol. Configuring the Certificate Manager for publishing is optional--you can turn this feature off without affecting any of the certificate issuance and management operations handled by the server.

• Publishing of Certificates
• Publishing of CRLs

Large corporations typically use Lightweight Directory Access Protocol (LDAP) directories, such as Netscape Directory Server, to store and manage corporatewide data, including user and group information and network resource data. If you have deployed an LDAP-compliant directory, you can configure the Certificate Manager to automatically publish your CA and end-entity certificate-related information to that directory. For example, if you have configured the Certificate Management System to employ directory-based authentication, you should consider publishing the CA and end-entity certificates to the same directory. This way, you can keep your users' security credentials with the rest of the user information (see Figure 20.1).

If the LDAP directory is properly configured to work with the Certificate Manager (and vice versa), any changes to the certificate information in the Certificate Manager are automatically made also in the publishing directory.

• When the Certificate Manager starts up, it publishes its CA signing certificate to the directory.
• When the Certificate Manager issues a new certificate, it stores a copy of the certificate in its internal database and then publishes the certificate to the directory.
• When the Certificate Manager revokes a certificate, it marks the copy of the certificate in its internal database as revoked and then unpublishes or removes the revoked certificate from the directory.

• If an end-entity entry is not present or if an entry cannot be found to publish the certificate.
• If the directory's schema doesn't include the appropriate attributes. To configure the directory for LDAP publishing, see "Step 2. Set Up the Directory for Publishing". Note that the Certificate Manager publishes to the userCertificate;binary attribute, which is an LDAP v3 standard. Unless you are using a non-standards compliant directory, this situation shouldn't arise.
• When the directory is unreachable because maintenance work is being performed, or because of network or system failures.

As indicated in Table 20.1, when a Certificate Manager is requested to issue a certificate, update certificate information, or publish a CRL, it automatically updates the corresponding entry in the configured directory with relevant information. To locate the correct directory entry, the Certificate Manager relies on object-mapping rules, which can be defined using the mapper modules; for details, see "Mapper Modules". Once an entry is located, to publish the object to the correct attribute, the server relies on object-publishing rules, which can be defined with the help of publisher modules; for details, "Publisher Modules".

The Certificate Manager and the publishing directory can become out of sync if certificates are issued or revoked while Directory Server is down. Certificates that were issued or revoked need to be published or unpublished manually when Directory Server comes back up.

• Search the internal database for certificates that are out of sync and publish or unpublish accordingly.
• Publish certificates that were issued from time A to time B while Directory Server was down. Similarly, unpublish certificates that were revoked or that expired while Directory Server was down.
• Publish or unpublish a range of certificates based on serial numbers (from serial number xx to serial number yy).

In addition to publishing to a directory, the Certificate Manager can publish the certificate to a file. The certificate is published as a DER-encoded binary blob and applications that are capable of reading such data may read the file for certificate information. For example, you can customize the sample code for Flat File CRL and certificate publisher can be customized to store certificates and CRLs in a relational database management system.

• Revoke the certificate if any of the certificate assertions becomes false--for example, if the subject's key gets compromised or the status of the subject's role or right changes. (See "Reasons for Revoking a Certificate".)
• Make the revoked certificate available to parties or applications that need to verify its validity status.

A Certificate Manager can revoke any certificate it has issued. A certificate needs to be revoked if one or more of the following situations occur:

• The owner of the certificate has changed status and no longer has the right to use the certificate.
• The private key of a certificate owner has been compromised.
• The certificate owner doesn't want to use the certificate.
• The private key of the CA that issued the certificate has been compromised.

At the time of this writing, Netscape Communicator versions 4.7 and later, when used in conjunction with the security module called Netscape Personal Security Manager, enable automatic revocation-status verification of certificates using the OCSP protocol. The section "Publishing of CRLs to an Online Validation Authority" explains how the revocation status of a certificate is verified in an OCSP-compliant PKI setup.

Because Netscape servers currently cannot check the revocation status of a certificate, you should use other forms of access control. For example, you can remove individual users from access groups to prevent them from accessing the server.

Revocation status of a certificate can be made available to PKI entities by publishing the CRL to various repositories. To aid you in this process, the Certificate Manager supports publishing of CRLs to the following repositories:

• An LDAP-compliant directory
• A flat file
• An Online Certificate Status Protocol (OCSP)-compliant validation authority or OCSP responder

The Certificate Manager can publish the CRL to an LDAP-compliant directory using the LDAP protocol or LDAP over SSL (LDAPS) protocol, and applications can retrieve the CRL over HTTP. Support for retrieving CRLs over HTTP enables some browsers, such as Netscape Communicator, to automatically import the latest CRL from the directory that receives regular updates from the Certificate Manager. The browser can then use the CRL to automatically check all certificates to ensure that they have not been revoked.

Because CRLs can grow very large, several methods have been developed to minimize overhead of retrieving and delivering large CRLs. One of these methods is based on partitioning the entire certificate space and associating a separate CRL with every partition. This partition is called a CRL issuing or distribution point--it is the location where a subset of all the revoked certificates are maintained. Partitioning can be based on revocation reason, on whether the revoked certificate is a CA certificate or end-entity certificate, on end users' names, and so on. Each issuing point is identified by a set of names, which can be in various forms.

In this method, the Certificate Manager publishes the CRL to a file. The CRL is published as a DER-encoded binary blob and applications that are capable of reading such data may read the file for CRL information. You may also use the file to import the CRL to other repositories.

Certificate Management System supports the Online Certificate Status Protocol (OCSP) as defined in the PKIX standard RFC 2560 (see http://www.ietf.org/rfc/rfc2560.txt). The Certificate Manager can publish a CRL to an OCSP-compliant online validation authority or server, such as ValiCert Certificate VA.

• A CA, which issues and revokes certificates, and periodically publishes a CRL to the OCSP responder.
• An OCSP responder, which maintains the CRL it receives periodically from the CA and, when queried by an OCSP-compliant client about the status of a certificate, sends a digitally signed response.
• OCSP-compliant applications, which, when trying to validate a certificate, query the appropriate OCSP responder (using the OCSP protocol) for the status of the certificate. The applications determine the location of the OCSP responder by using the Authority Information Access extension in the certificate being validated. (Certificate Management System allows you to add this extension to certificates; see "Authority Information Access Extension Policy".)

1. When a certificate's status needs to be verified, the OCSP client (an OCSP-compliant application) sends a request to the OCSP responder for verification and waits for a response from the responder.

The OCSP request that the client submits generally contains all the information required by the responder to identify the certificate whose status it needs to determine.

(Consider this process is similar to a cashier scanning your credit card and waiting for a response from the credit-card processing unit. The scanning unit sends identifying information, such as the credit card number, its type, validity period, and so on.)

2. Upon receipt of the request, the OCSP responder determines if the request contains all the information required by the responder to process it.
• If the request lacks any information required by the responder to process it or if the responder is not configured to provide the requested service to the client, the responder sends a rejection notification to the client. The responder also writes an appropriate error message to its log file.
• If the request meets all the criteria, the responder returns a response to the client that requested it: it checks its list of revoked certificates for the one whose status is being requested, verifies its status, composes a report, signs the report, and sends the report to the client.

• The CA that issued the certificate and whose status is being verified by the responder.
• A responder whose public key, which corresponds to the private key it uses to sign responses, is trusted by the client. Such a responder is called a trusted responder.
• A responder that holds a specially marked certificate issued to it directly by the CA that revokes the certificates and publishes the CRL. Possession of this certificate by a responder indicates that the CA has authorized the responder to issue OCSP responses for certificates revoked by the CA. Such a responder is called a CA-designated responder or a CA-authorized responder.

Certificate Management System allows you to request OCSP responder certificates. The end-entity interface of both Registration Manager and Certificate Manager includes a form that allows you to manually request a certificate for the OCSP responder. The default enrollment form includes all the attributes (for example, HTTP_PARAMS.certType==ocspResponder) that identify the certificate as an OCSP responder certificate. The required extensions, such as OCSP No Check and OCSP Signing, can be added to the certificate when the certificate request is subjected to policy checking; see "OCSP No Check Extension Policy"and "OCSPSigningExt Rule".

• Good--specifying a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate has not been revoked, but it does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc.
• Revoked--specifying that the certificate has been revoked, either permanently or temporarily.
• Unknown--specifying that the OCSP responder doesn't know about the certificate whose status is being requested by the client.

As mentioned in the preceding section, in addition to a CA, you also need an OCSP responder and OCSP-compliant clients if you want to set up an OCSP-compliant PKI setup. To aid you in this process, Certificate Management System bundles the following components:

• ValiCert Certificate VA (or Certificate VA), version 3.0.1--this is an online validation authority or OCSP responder. You can use this server to set up a CA-designated OCSP responder.
• Netscape Personal Security Manager (or Personal Security Manager)--this is an OCSP-compliant security plug-in module for Netscape Communicator. The module, in addition to many other features, enables Communicator to check certificate validity in real time using the OCSP protocol: it enables the client to read the authority information access extension in a certificate, locate the OCSP responder specified by the extension, request the revocation status of the certificate from the OCSP responder, and use the response to validate the certificate. For a brief introduction to Personal Security Manager, see page 51.