1 About Public Key Infrastructure

This chapter provides a brief overview of the public key cryptography and how it works, including information about the public key infrastructure, which is used for the general management of keys on Oracle Linux.

What is Public Key Cryptography?

Public key cryptography is an encryption technique that's used to enable secure communications on an insecure public network and also to verify the identity of the entity on the other end of a network connection. Public key cryptography works by establishing an asymmetric pair keys. Data encrypted by one key is decrypted by the other key. One key is kept private and the other key is made public. Someone decrypting the data using the public key can be sure that the data was encrypted by someone who has access to the private key. Similarly, someone encrypting data using the public key can be sure that the data can only be decrypted by someone who has access to the private key.

Neither key on its own can establish the identity of the sender of the data. To achieve this, the public key is typically signed as belonging to the owner of the private key. The signing process is done by a trusted third party, known as a Certification Authority (CA). The creator of the private and public key pair sends the public key to the CA in the form of a Certificate Signing Request (CSR). The CA uses its own private key to sign a certificate, which contains an encrypted version of the originator'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. This certificate can be made public or provided to any client that need to decrypt data that has been encrypted using the private key.

Clients that trust the CA can also trust the public key stored in the certificate. Decrypting the certificate with the CA certificate yields the public key that can then be used to create a secure communication channel that keeps the data confidential and which can be used to establish the identity of the originator of data moving through the channel.

For the Internet, many public top-level or root CAs and intermediary CAs exist that are trusted by a root CA to issue certificates on behalf of entities. An intermediary CA 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.

CA certificates are only used to establish the identity of a public key and the period for which the public key is considered valid. When the certificate expires, data encrypted using the public key can still be decrypted by the private key. This means that the private key must be kept safe forever for communications to always be considered secure. A mechanism also exists within public key cryptography that can be used to help mitigate against private key compromises. This mechanism is known as Perfect Forward Secrecy (PFS) and uses a key exchange algorithm to securely agree on a random and disposable session key that can be used with a symmetric cipher to encrypt data. The advantage of this approach is that if the session key is compromised, only the communications in that particular communication session are exposed. Equally, if the private key is compromised, all the actual communication sessions aren't automatically exposed either.

Another added benefit of PFS is that it simplifies the computationally expensive and slow process of decrypting and validating each piece of information using the asymmetric key pair and the CA certificate. In reality, the process of decrypting the public key and validating it against the CA certificate and then using it to decrypt data within a communication session is only done at the beginning of the session, until PFS is established. The algorithm to create and share the random session key is typically the Diffie-Hellman key exchange. The session key then uses a symmetric cipher to perform more rapid encryption and decryption of data through the rest of the session. The cipher most commonly used for this purpose is AES, which can take advantage of hardware to make encryption and communication in ciphertext almost as fast as communicating with plaintext.

The handling of the communication channel and the negotiation where the client and server side switch from asymmetric to symmetric cryptography are all achieved using the Transport Layer Security (TLS) or Secure Sockets Layer (SSL) cryptographic protocols.

OpenSSL, GnuTLS, and Network Security Services (NSS) provide open source implementations of the TLS and SSL protocols. You can also use the keytool command provided with OpenJDK package to manage Java Keystores, often used by Java-based applications. If a hierarchy of trust is confined to the organization's intranet, you can use these implementations 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 the organization, browsers, LDAP or IPA authentication, and other software that use certificates would prompt the user about the potential untrusted relationship.

Note:

If you do use certificates for a domain that are validated by a root or intermediary-level CA, you don't need to distribute a root certificate, as the appropriate certificate is already 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 intermediary CAs, expire after a period of five to 10 years. To avoid having applications display warnings about out-of-date certificates, plan to replace TLS/SSL certificates before they expire. For root certificates, you would typically update the software before the certificate expires.

If you request a signed certificate from a CA for which a root certificate or certificate chain that authenticates the CA's public key doesn't already exist on the 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's published by the CA.

About SSL and TLS

Both Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are communications protocols that ensure secure connections and exchanges between server and client systems. Both protocols provide encryption and authentication to secure network communications. However, SSL is an older technology and has been replaced by TLS. The cryptography used by TLS is more complex, advanced, robust, and secure. Authentication with TLS is faster and alert messaging is improved.

Despite this change to the underlying protocol, the OpenSSL project retains its name and the SSL terminology is often used interchangeably to describe TLS functionality. In the context of secure communications, SSL is now understood as referring to the TLS protocol and TLS certificates. Any references to SSL in this documentation are intended to be understood in the context of TLS.

Automatic Certificate Management Environment (ACME)

Automatic Certificate Management Environment (ACME) is a protocol and framework that's published by the IETF in RFC 8555 and which can be used for the signing and creation of certificates where domain validation is required.

The protocol uses JSON formatted messages over HTTPS with a CA to handle validation of domain ownership automatically by having the ACME client perform an action that can only be done with control of the domain name. For example, the CA could either request the provision of a DNS record, or could request a specific HTTP resource to be made available on a web server at the domain name.

After the CA validates that the entity requesting a certificate has ownership of the domain, the CA can sign the certificate that's sent to it by the ACME client. Typically, the client can automatically install the certificate at a location that's usable by services running on the system.

ACME lowers the cost and complexity associated with managing public key infrastructure. Sometimes, obtaining signed certificates for systems within domains can be free, depending on the selection of CA. For example, Let's Encrypt, the originator of the ACME protocol, provides a free and open CA service. Other commercial CAs are starting to also offer free ACME based certificates as well.

While the first version of the ACME protocol could be used to create only single domain certificates, ACME v2 can be used for the creation and signing of certificates with wildcard domains, such as *.example.com. Therefore, you can use a single certificate across all subdomains. Note that ACME only validates domains. If you need certificates that require more validations, you might need signed certificates from an established CA that offers services beyond ACME.

If you need to create and issue certificates across an infrastructure to use TLS/SSL protected services, consider using a CA that supports ACME and using an ACME client. ACME can automatically generate the key pairs and CSR, submit the CSR to a CA for validation, perform any validation steps for the CA, and obtain the signed certificate and store it somewhere that's accessible to services and applications. Many clients automatically set periodic cron tasks to check for certificate expiry and to automatically request a new certificate before the current certificate expires.