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.

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