3.3 Configuring and Using Certificate Management

Public-key cryptography allows secure communication on an insecure
public network and verification of the identity of the entity at
the other end of a network connection. Public-key cryptography is
based on establishing pairs of secret and public keys. Either key
can be used to encrypt some data, and the other key can then be
used to decrypt that data. You cannot use just one of the keys to
perform both operations on the same data. Because of the
asymmetric nature of the key operations, you can distribute the
public key without fear of compromising security. Possession of
the private key is required to be able to read messages that are
encrypted with the public key.

However, if you receive a public key, this in itself does not
establish the identity of the sender. A public-key infrastructure
implements digital certificates that allow public keys to be
distributed in a hierarchy of trusted relationships. A
Certification Authority (CA) acts as a trusted third party that
can issue signed certificates on behalf of another entity on a
network. The CA uses its own private key to encrypt the
certificate, which contains the entity's public key together with
other information about the entity (subject),
the CA (issuer), the period of validity of
the certificate, and the cryptographic algorithms used. Assuming
that you trust the CA, you can also trust the entity's public key
stored in the certificate. Decrypting the certificate with the
CA's public key yields the entity's public key, and this key can
be used to establish a secure communications channel.

For the Internet, there are many public top-level
(root) CAs and there are also many
intermediate CAs that are trusted by a root CA to issue
certificates on behalf of entities. An intermediate CA usually
returns a certificate chain, where each certificate in the chain
authenticates the public key of the signer of the previous
certificate in the chain up to and including a root CA. The secure
communication channels that are required for website security
usually use the Transport Layer Security (TLS) or Secure Sockets
Layer (SSL) cryptographic protocols. Because most financial
transactions on the Internet rely on TLS and SSL, a more limited
number of CAs are permitted to issue TLS/SSL certificates that web
browsers trust, and these CAs are regularly audited for security.

OpenSSL is an open-source implementation of the TLS and SSL
protocols. If a hierarchy of trust is confined to your
organization's intranet, you can use OpenSSL to generate a root
certificate and set up a CA for that domain. However, unless you
install this self-signed root certificate on each system in your
organization, browsers, LDAP or IPA authentication, and other
software that use certificates will prompt the user about the
potentially untrusted relationship. If you use certificates for
your domain that are validated by a root or intermediate-level CA,
you do not need to distribute a root certificate as the
appropriate certificate should already be present on each system.

Typically, TLS/SSL certificates expire after one year. Other
certificates, including root certificates that are distributed
with web browsers, and which are issued by root and intermediate
CAs usually expire after a period from five to 10 years. To avoid
applications displaying warnings about out-of-date certificates,
you should plan to replace TLS/SSL certificates before they
expire. For root certificates, this is not usually a problem as
you would typically update the software before the certificate
would expire.

If you request a signed certificate from a CA for which a root
certificate or certificate chain that authenticates the CA's
public key does not already exist on your system, obtain a trusted
root certificate from the CA. To avoid a potential
man-in-the-middle attack, verify the authenticity of the root
certificate before importing it. Check that the certificate's
fingerprint matches the fingerprint that the CA publishes.

The openssl command allows you to generate
self-signed certificates that web browsers can use. You can also
use the keytool command to generate self-signed
certificates, but this command's primary purpose is to install and
manage JSSE (Java Secure Socket Extension) digital certificates
for use with Java applications.

Note

For production environments, you should obtain external
CA-signed certificates, which can be revoked if the private key
is compromised. Self-signed certificates cannot be revoked, and
should only be used when developing, testing, or demonstrating
software.

For more information about using TLS/SSL and certificates with the
Apache HTTP server, see the Apache documentation at
http://httpd.apache.org/docs.