Digital certification uses cryptographic processes to encrypt data, protecting the data from access by unauthorized people. The user data is encrypted using a second data record, or key. The key is applied to the user data in a mathematical process, producing an altered data record in which the original content can no longer be identified. Asymmetrical encryption is now in general use (public key method). Keys always occur in pairs:
The private key must be kept safely by the key owner. Accidental publication of the private key compromises the key pair and renders it useless.
The key owner circulates the public key for use by third parties.
Because the public key process is in widespread use, there are many public keys in circulation. Successful use of this system requires that every user be sure that a public key actually belongs to the assumed owner. The assignment of users to public keys is confirmed by trustworthy organizations with public key certificates. Such certificates contain the name of the key owner, the corresponding public key, and the electronic signature of the person issuing the certificate.
Trustworthy organizations that issue and sign public key certificates are
usually part of a
certification infrastructure that is also responsible for the
other aspects of certificate management, such as publication,
withdrawal, and renewal of certificates. An infrastructure of this kind is
generally referred to as a public key infrastructure
or PKI. One familiar PKI is the
OpenPGP standard in which users publish their
certificates themselves without central authorization points. These
certificates become trustworthy when signed by other parties in the
web of trust.
The X.509 Public Key Infrastructure (PKIX) is an alternative model defined by the IETF (Internet Engineering Task Force) that serves as a model for almost all publicly-used PKIs today. In this model, authentication is made by certificate authorities (CA) in a hierarchical tree structure. The root of the tree is the root CA, which certifies all sub-CAs. The lowest level of sub-CAs issue user certificates. The user certificates are trustworthy by certification that can be traced to the root CA.
The security of such a PKI depends on the trustworthiness of the CA certificates. To make certification practices clear to PKI customers, the PKI operator defines a certification practice statement (CPS) that defines the procedures for certificate management. This should ensure that the PKI only issues trustworthy certificates.
An X.509 certificate is a data structure with several fixed fields and, optionally, additional extensions. The fixed fields mainly contain the name of the key owner, the public key, and the data relating to the issuing CA (name and signature). For security reasons, a certificate should only have a limited period of validity, so a field is also provided for this date. The CA guarantees the validity of the certificate in the specified period. The CPS usually requires the PKI (the issuing CA) to create and distribute a new certificate before expiration.
The extensions can contain any additional information. An application is only required to be able to evaluate an extension if it is identified as critical. If an application does not recognize a critical extension, it must reject the certificate. Some extensions are only useful for a specific application, such as signature or encryption.
X.509v3 Certificate shows the fields of a basic X.509 certificate in version 3.
Table 37-1 X.509v3 Certificate
Field |
Content |
---|---|
Version |
The version of the certificate, for example, v3 |
Serial Number |
Unique certificate ID (an integer) |
Signature |
The ID of the algorithm used to sign the certificate |
Issuer |
Unique name (DN) of the issuing authority (CA) |
Validity |
Period of validity |
Subject |
Unique name (DN) of the owner |
Subject Public Key Info |
Public key of the owner and the ID of the algorithm |
Issuer Unique ID |
Unique ID of the issuing CA (optional) |
Subject Unique ID |
Unique ID of the owner (optional) |
Extensions |
Optional additional information, such as
|
If a certificate becomes untrustworthy before it has expired, it must be blocked immediately. This can be needed if, for example, the private key has accidentally been made public. Blocking certificates is especially important if the private key belongs to a CA rather than a user certificate. In this case, all user certificates issued by the relevant CA must be blocked immediately. If a certificate is blocked, the PKI (the responsible CA) must make this information available to all those involved using a certificate revocation list (CRL).
These lists are supplied by the CA to public CRL distribution points (CDPs) at regular intervals. The CDP can optionally be named as an extension in the certificate, so a checker can fetch a current CRL for validation purposes. One way to do this is the online certificate status protocol (OCSP). The authenticity of the CRLs is ensured with the signature of the issuing CA. Table 37-2 shows the basic parts of a X.509 CRL.
Table 37-2 X.509 Certificate Revocation List (CRL)
Field |
Content |
---|---|
Version |
The version of the CRL, such as v2 |
Signature |
The ID of the algorithm used to sign the CRL |
Issuer |
Unique name (DN) of the publisher of the CRL (usually the issuing CA) |
This Update |
Time of publication (date, time) of this CRL |
Next Update |
Time of publication (date, time) of the next CRL |
List of revoked certificates |
Every entry contains the serial number of the certificate, the time of revocation, and optional extensions (CRL entry extensions) |
Extensions |
Optional CRL extensions |
The certificates and CRLs for a CA must be made publicly accessible using a repository. Because the signature protects the certificates and CRLs from being forged, the repository itself does not need to be secured in a special way. Instead, it tries to grant the simplest and fastest access possible. For this reason, certificates are often provided on an LDAP or HTTP server. Find explanations about LDAP in Section 26.0, LDAP—A Directory Service. Section 30.0, The Apache HTTP Server contains information about the HTTP server.
YaST contains modules for the basic management of X.509 certificates.
This mainly involves the creation of CAs, sub-CAs, and their certificates.
The services of a PKI go far beyond simply creating and distributing
certificates and CRLs. The operation of a PKI requires a well-conceived
administrative infrastructure allowing continuous update of certificates
and CRLs. This infrastructure is provided by commercial PKI products and
can also be partly automated. YaST provides tools for creating and
distributing CAs and certificates, but cannot currently offer this
background infrastructure. To set up a small PKI, you can use the available
YaST modules. However, you should use commercial products to set up an
official
or commercial PKI.