3 Managing digital certificates using PKI
3.2 Certification Authorities (CA)
A CA is responsible for issuing public key certificates which prove public key authenticity by ensuring that the person who claims to be the owner of the key actually is its owner. This prevents the communication endpoints from falling victim to a "man-in-the-middle" attack. Before issuing a certificate, the CA verifies the information provided by the certificate requester, includes his or her identifying data and public key in a standardized data structure (e.g. X.509) and signs this structure with the CA's own private key.
3.2.1 Certificates can be issued by different types of CA
Certificates can be issued by the following types of CA:
l Commercial CAs such as VeriSign (http://www.verisign.com), Thawte and TC TrustCenter GmbH Hamburg.
l Besides commercial CAs, some providers (e.g. CAcert) issue digital certificates free of charge.
l Large companies and institutions often have their own CAs.
Beyond that, anyone can set up their own CA. The certificates issued by such a CA are signed with the private key of the self-signed certificate previously created for the CA. A self-signed certificate is a certificate that is signed with its own
private key. For details on how to create self-signed certificates, see section
"Creating X.509 certificates" on page 44.
3.2.2 Hierarchical trust structure: Root CA and subordinate (intermediate) CAs
X.509 certificates work with a hierarchical trust structure in the form of a tree, at the top of which a specific CA, the Root CA, is legally liable for ensuring the proven identity of the certificate owners. A distinction is made between a strict hierarchical trust structure and a distributed hierarchical trust structure.
Root CA, subordinate CAs, and RAs
The Root CA is identified by a self-signed certificate and according to RFC 4210 represents a CA that is directly trusted by an end entity. Normally, the
trustworthiness of a root certificate is legally attested by passing through an out-of-band process.
For signing requests (certificate signing requests, CSR) from subordinate CAs, the Root CA uses the private key from its self-signed certificate. A self-signed certificate is a certificate that is digitally signed by the same entity (i.e. the Root CA) that the certificate identifies. Subordinate CAs are also known as
intermediate CAs.
A CA may delegate the end entity validation process to a Registration Authority (RA), which may be an integral part of the CA or act as a separate instance.
Depending on the CA's policy, the RA may sign the certification signing request (CSR) once validation has completed, or forward the CSR to the CA.
Hierarchical trust structure
In a hierarchical trust structure, interaction between the CAs is as follows:
1. The Root CA certifies its subordinate CAs which in turn certify their subordinate CAs.
2. A CA may accredit a Registration Authority (RA) to verify an end entity (which sends a certificate signing request, CSR).
3. Depending on the CA's policy, the RA may certify the end entity on its own or forward the CSR to the CA (indicated by 3' in the figure shown below).
4. A CA certifies an end entity.
The following figure outlines a hierarchy of CAs:
Figure 7: CAs - hierarchical trust structure Certificate chaining
The second-tier CAs get their certificates signed by the Root CA. Third-tier CAs get their certificates from the second-tier CAs and so on, all the way down to the end entities. This way, certificate chains are formed starting from the Root CA certificate down to the individual end entities that form the nodes of the tree.
Each certificate of a chain is therefore not only signed by the issuing CA but also by all CAs directly preceding the issuing CA in the trust hierarchy. The Root CA's certificate, which is known as the Root CA certificate, represents the trust anchor of the certificate chain.
To make the certificate chain comprehensible for e.g. the end user's browser, each chain certificate must be installed on the respective server.
The following figure shows an example of a certificate chain together with the issuing CAs:
Figure 8: Certificate chain and issuing CAs
3.2.3 Creating your own CA
The basic concept of creating and operating your own CA consists of creating a self-signed certificate whose private key will be used later on to sign the server certificates. The self-signed certificate thus serves as the Root CA certificate of your own CA.To avoid browser security warnings when accessing the server from a Web browser, the self-signed certificate must be imported to the trust store of all Web browsers which are intended to access the server via HTTPS. A significant advantage of using your own private CA is that it is free of charge.
Before creating your own CA, you should acquire a thorough
understanding of the subject PKI, for example by reading the relevant literature.
The following explains by way of example how you can use the OpenSSL toolkit to create your own CA. Creating your own CA primarily consists of creating a private key, which later on will be used for signing the server certificates.
Proceed as follows:
1. Create the private key that is to be used for your CA:
openssl genrsa -aes256 -out rootCAprivate.key 4096 You will then be prompted to enter a passphrase for the key. The created private key is output in the .key file (here: rootCAprivate.key)
Important!
The .key file containing the private key of your CA must be securely protected. An offender gaining unauthorized access to your CA's private key can easily sign certificates which will be trusted by the clients. This risk can be greatly reduced by securing the private key with a passphrase as shown above. Beyond that, it is strongly recommended to store the private key in a specially protected directory (e.g. on a separate server) or even on a smartcard.
2. Create a self-signed certificate (root certificate) using the previously created private key:
openssl req x509 new key rootCAprivate.key days 730 -out rootCApublic.pem
You will be prompted to enter the passphrase for the previously created private key (here: rootCAprivate.key). Then you will be prompted to enter the values for some identifying certificate attributes: Country Name, State or Province Name, City or Locality, Organization Name,
Organizational Unit, Common Name, Email Address.
The created root certificate is output in the .pem file (here:
rootCApublic.pem)
3.3 X.509 certificates
Public key certificates conforming to the X.509 standard (referred to as X.509 certificates or simply certificates in the following for short) are used in conjunction with SSL. An X.509 certificate is a data structure containing all the information required to identify the server or client, plus the public key of the certificate owner. Certificates are issued by a central authority, the Certification Authority (CA), by signing them with its private key once the identity of the organization named in the certificate and of an authorized representative has been checked. The signature is contained in the certificate and is disclosed at the time of connection setup so that the client can verify the trustworthiness of the certificate. Optionally, the server can also request a certificate from the client. A certificate has a limited lifetime.
3.3.1 Certificate types
SSL certificates can be classified with regard to the following aspects:
l Scope of validity
l Issuing instance
3.3.1.1 Certificate types relating to the scope of validity The most important are:
l Single-server certificates
l Intermediate certificates (chain certificates)
l Cross certificates
l Multi-domain certificates
l Multi-host certificates
l Wildcard certificates
These certificate types are not the subject of this manual and are only mentioned here for completeness.
3.3.1.2 Certificate types relating to the issuing instance
l Self-signed certificates
l CA certificates
l Root certificates, which are special cases of the above certificate types Self-signed certificates
A self-signed certificate is a certificate that is signed with the private key
belonging to the public key whose authenticity the certificate is to prove. In other words, the certificate is signed by the same entity that it identifies. Self-signed certificates are preferably used for establishing your own CA or in test
environments.
For details on how to create self-signed certificates, see section"Creating X.509 certificates" on page 44).
CA certificates
A CA certificate is a certificate that a CA issues to a subordinate CA or to an end entity.
For details on how to create a CA certificate, see section"Creating X.509 certificates" on page 44.
Root certificates
A root certificate is a certificate that is not signed by another CA. Therefore, a root certificate is at the top of a certificate chain.
As apparent from the above, there are two different types of root certificate:
l Root CA certificates, i.e. the self-signed certificate of the top-level CA.
l "Normal" self-signed certificates.
The"X.509 certificates" on page 37is also an example of a Root CA certificate.
3.3.2 Certificate Revocation Lists (CRL) and OCSP
Situations where it is necessary to withdraw the trust in a certificate within its validity period regularly occur in practice, e.g. in the case of a compromised private key or when the identifying data of a certificate owner has changed.
Certificate Revocation Lists (CRL)
For certificate revocation, CAs maintain Certificate Revocation Lists (CRL). A CRL lists all certificates issued by the CA that have been revoked before their scheduled expiration date.
Online Certificate Status Protocol (OCSP)
The Online Certificate Status Protocol (OCSP) is defined in RFC 2560 and allows applications to determine the (revocation) state of an SSL certificate online.
OCSP claims to provide more timely revocation information than is possible with CRLs and may also be used to obtain additional status information.
Revoking a CA certificate
When a CA certificate is revoked, all certificates issued by the corresponding CA or one of the related subordinate CAs also become invalid.
3.3.3 Structure of an X.509 certificate
X.509 certificates, which are normally issued by a CA, contain all the information required to identify the server or client, plus the public key of the certificate owner. Certificates are stored in separate files. When a connection is negotiated, SSL uses the certificate files to identify the server and, in some applications, also the client.
An X.509 certificate includes a variety of information fields. Some of the most important are listed below:
l Version of the certificate structure (e.g. 3)
l Serial number (unique to each issuer)
l Signature algorithm (e.g. SHA-1 with RSA encryption)
l Issuer of the certificate: Distinguished Name (DN) of the issuing authority
l Validity (Not before / not after)
l Subject: Distinguished Name (DN) of the entity to which the certificate is issued
l Subject public information
o Algorithm, i.e. the OID of the public key algorithm used
o The subject's public key, denoted as a string
o Algorithm used for public key encrytion (e.g. RSA)
l Extensions (e.g. Certificate Policies (CP), Certificate Practice Statements (CPS))
l Digital signature covering all the certificate data
3.3.4 Applying for and creating X.509 certificates
Depending on your security considerations, you have the following options for acquiring an X.509 certificate:
l Obtaining an X.509 certificate from a commercial CA.
l Creating your own CA.
l Using a self-signed certificate directly.
Obtaining an X.509 certificate from a commercial CA
Generally, you obtain an X.509 certificate from a commercial Certification Authority (CA) such as VeriSign (http://www.verisign.com), Thawte and TC TrustCenter GmbH Hamburg, to name but a few. The certificates issued by the CAs are normally classified by trust levels(e.g. “Class 3”). Alternatively, you can create your own CA which is based on a self-signed certificate, or you can use a self-signed certificate directly.
A distinguishing feature of the individual trust levels is the effort involved in identifying the applicant:
l In the case of low trust levels it is sufficient to be able to deliver e-mails to the specified-e-mail address.
In the case of higher trust levels the applicant must, for example, supply a verified extract from the commercial register for the company involved. In addition, an authorized signatory or PKI executive of the company must identify themselves using the Post Ident procedure or something similar.
l Higher trust levels generally also mean higher warranty sums in the event of loss, for example if the CA issues a certificate to an unauthorized entity.
Further details can be found on the CAs’ websites.
Creating your own CA
If the certificates are only intended for in-house applications, it may make sense to set up your own CA (see"Certification Authorities (CA)" on page 32).
Self-signed certificates
A self-signed certificate is a certificate that is signed with its own private key, i.e it is signed by the same entity whose identity it proves.
Due to their straightforward availability, self-signed certificates are ideally suited for test environments. However, to fulfill the high safety requirements that are typical for e.g. productive server management, it is strongly recommended to use a certificate that is signed by a trusted Certification Authority (CA certificate), or at least by a CA you have created yourself.
Updating certificates
A new certificate must be obtained and installed in good time before the old one expires. If the private key has been compromised or the information in the certificate is no longer applicable, the certificate must be revoked.
3.3.5 X.509 file formats (extensions) for certificates and keys
From the operating system's point of view, X.509 certificates are files containing digital encoded documents. Two categories of file format (extensions) can be distinguished:
l Encoding-specific file formats
l Purpose-specific file formats Encoding-specific file formats
The following file formats (extensions) indicate whether the related contents are binary-encoded or base64-encoded:
l .DER (Distinguished Encoding Rules)
.DER format is the basic container format for storing a single DER-encoded SSL certificate or a single private key. The DER format represents pure certificate and key data in binary ASN.1 notation and contains no header.
A .DER file may contain:
o A single private key (RSA, DSA)
o A single publc key (RSA, DSA)
o A single X.509 certificate
On Windows systems, .DER files are only used for storing digital certificates.
Files conforming to .DER are also used in conjunction with other file extensions (e.g. .CERT, .CRT, .PVK).
l .PEM (Privacy Enhanced Email)
.PEM format is the container format for storing base64-encoded ASN.1 or .DER SSL certificates and/or private keys. The certificate/private key itself is enclosed between two special comment lines. Private keys and/or certificate chains can be stored in the same .PEM file. The .PEM format is the standard with OpenSSL, which also allows you to convert .PEM files to .DER files.
A .PEM file may contain:
o Private keys (RSA, DSA)
o Public keys (RSA, DSA)
o X.509 certificates
On Windows systems, .PEM files are only used for storing digital certificates.
Files conforming to .PEM are also used in conjunction with other file extensions (e.g. .CERT, .CRT, .CSR).
Purpose-specific file formats
The following file formats which are designated for specific purposes can be available.
l .CER, .CRT
The .CER and .CRTformats are used for certificates which may be encoded in binary .DER or as ASCII (base64-encoded) .PEM format. The .CER and . CRT formats are used almost synonymously. Beyond that, .CER and .CRT are safely interchangeable if coded in the same format (.DER or .CRT).
.CER is most commonly used in Windows environments, whereas .CRT is used largely on Linux systems.
l .spc, .p7a, .p7b, .p7c
The .spc, .p7a, .p7b, and .p7c formats conforming to the PKCS#7 standard represent binary file formats which allow you to store one or more certificates in an encrypted and signed format.
l .PFX, .p12
The .PFX and .p12 formats conforming to the PKCS#12 standard are used for storing private keys, public keys, and X.509 certificates in a binary
format.
l .PVK
The .PVK format is a binary file format for storing private keys with a password-based encryption.
l .NET
The .NET format conforming to the PKCS#8 standard is a binary file format for storing private keys. The private key may be optionally encrypted.
l .CSR (Certificate Signing Request)
The .CSR format is used to submit a certificate signing request (CSR) to a Certification Authority (CA). The request can be in .PEM format (base64-encoded) and is enclosed between the comment lines "---BEGIN NEW CERTIFICATE REQUEST---" and "---END NEW CERTIFICATE REQUEST---".