Certificate Authorities

Certificate Authorities (CAs) are organizations that verify the identity of a subject (represented in a certificate request) and issue signed X.509 certificates. CAs can be internal or external to an organization and can issue different types of certificates that are for a specific purpose or to confer varying levels of trust.

External CAs are typically commercial entities that provide certificate issuance to customers for a fee. Examples of External CAs include Thawte, VeriSign and RSA.

CAs offer different "grades" of signed certificates for purchase. Some have a nominal fee, and come with minimal requirements to prove the subject's identity. For example, a certificate used to sign emails may be only cost a few dollars and only requires email confirmation to prove that the email address represented by the Subject in the certificate is authentic. By contrast, a certificate used for more trusted activities may cost upwards of a hundred dollars and require a far more rigorous screening process to ensure the subject meets the requirements for the certificate. Parties that wish to use any type of certificate must decide that the criteria to qualify for such a certificate are sufficient for their needs, and that they consider the CA itself to be sufficiently reputable.

Internal CAs such as those provided by Windows Server can simplify certificate management activities, but in this case the trust of the certificate is now based on the organization that issued it. Issued certificates for Subjects within the organization's security domain (usually defined within Active Directory) are typically signed with the organization's root certificate or another other "parent certificate" allowed to sign certificates.

The chain of certificates, from the Subject's certificate to the root certificate used by the CA for signing subject's certificate, is known as a trust chain. A party may decide to trust certificates at any level within the trust chain. This allows them to trust certificates further down the chain, as long as they are able to trace the trust chain back to the level of the certificate they original trusted.

Note: In test environments, you may choose to use certificates that do not have rigorous requirements for proving the identity of the subject. Certificates can be generated and self-signed using the makecert utility, however there are known performance issues when verifying digital signatures using certificates generated by the makecert utility. For more details on the makecert utility, see Certificate Creation Tool (makecert.exe)

Obtaining an X.509 Certificate

Depending on the type of CA, X.509 certificates can be obtained in a variety of ways. For external CAs, certificates are typically obtained for a subject by submitting a Certificate Signing Request (CSR). A CSR contains the subject’s name, public key and algorithm for which the key is used (the vast majority of X.509 certificates you are likely to encounter use RSA for its algorithm).

The public key included in the CSR comes from a public/private key pair generated specifically for use with the requested certificate. As soon as the public/private key pair is generated, the private key should be immediately stored in a secure place such as a machine key store, with access to the key solely restricted to authorized parties. Ideally, the only party able to access the private key file would be the subject represented in the X.509 certificate, although some infrastructures may allow access to the certificate private key by other accounts. When parties other than the subject represented by the X.509 certificate are allowed to access the certificate private key, the ability to support non-repudiation may not be possible. While the public key of the public/private key pair is required for the CSR, the private key should never be sent to the CA under any circumstance.

Internal CAs may also use CSR’s to process X.509 certificate requests; however, since the CA is internal to a specific organization, there can be additional options that reduce the overhead required to process requests and verify subject identities. For example, an internal CA using Windows Certificate Server may enable auto-enrollment, which automates certificate request and issuance for user accounts created within an Active Directory domain.

Figure 1 depicts the process of a Subject requesting and issuing an X.509 certificate involving a CA that processes Certificate Signing Requests:

Figure 1

Requesting and obtaining a certificate from a CA

Certificate Revocation

X.509 certificates can be revoked by the issuing CA if the integrity of the certificate has somehow been compromised. The justification to revoke an issued certificate varies with each CA, but some general causes for certificate revocation include:

The private key has been stolen or wrongly disclosed due to improper storage or use. For example when the subject’s private key is attached to an outgoing message instead of their X.509 certificate containing the public key.
The subject represented in the X.509 certificate has breached the trust of the CA that issued the certificate. For example, if information about the subject was intentionally misrepresented to the CA during the process of verifying the subject’s identity.
An identity corresponding to a certificate has been removed from an organization that manages an Internal CA. For example a user account is removed from the system, or disabled when the user's employment is terminated.
A subject no longer requires the certificate (cessation of operation.) A CA may revoke a certificate if the certificate is no longer required and will not be used by the Subject any more.

X.509 CAs typically publish a list of certificates that have been revoked, based on the CA’s criteria for certificate revocation. These lists are known as Certificate Revocation Lists (CRLs). CRLs are made publicly available, so that a recipient can verify whether or not a certificate used to sign a message is valid. Any message recipient that receives a signed message, should verify that the subject’s certificate has not been revoked, to ensure the integrity of the signatures, based on the expected level of trust associated with the type of certificate.

Certificate Storage and Access

X.509 Certificates can be stored and accessed in a number of ways, including:

Local repository X.509 certificates may be exchanged out-of-band and stored in a locally accessible repository such as the machine certificate store in Windows. A local repository should only be used if a small number of certificates are required for use by the Requestor or Service.
PKI distribution Public Key Infrastructure (PKI) is a platform that allows an organization to centrally manage X.509 certificates required by the organization's Services and Subjects to authenticate and verify digital signatures. Certificates for that organization's Subjects may also be made accessible outside of the organization. An example of a PKI solution would be one included Microsoft Windows Server 2003. For more information, see: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/63e3ba1c-cc23-40b1-9ca2-853869677318.mspx
Direct presentation X.509 certificates may be presented to a message recipient by attaching the certificate directly to the message. The recipient may subsequently decide to cache the certificate locally, pass it off to a central repository for storage or simply re-process it when it is attached to a new message.

Certificate Management

There are many issues related to certificate management and this chapter does not attempt to provide complete coverage. One issue that is significant to consider for message layer security is whether distinct certificates should be created for signing and encrypting message layer data.

For message based security, it is considered good practice to use distinct certificates and key pairs for encryption and digital signatures rather than using a single key pair for both. One reason is that the contents of the certificates, as well as policies for issuance, key distribution, revocation, notification of revocation, and key backup are likely to differ depending on the purpose the keys are used for. This is particularly true when signatures are used for longer term authentication and integrity of business documents, rather than merely temporary authentication of a session. Also, if encrypted messages are persisted to disk you may need to decrypt the messages using an archived version of the private key. However, you would not want new digital signatures to be created with this private key.