3.3 Configuring and Using Certificate Management

3.3.1 About the openssl Command
3.3.2 About the keytool Command

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 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.

3.3.1 About the openssl Command

The openssl command, which is included in the openssl package, allows you to perform various cryptography functions from the OpenSSL library including:

  • Creating and managing pairs of private and public keys.

  • Performing public key cryptographic operations.

  • Creating self-signed certificates.

  • Creating certificate signing requests (CSRs).

  • Creating certificate revocation lists (CRLs).

  • Converting certificate files between various formats.

  • Calculating message digests.

  • Encrypting and decrypting files.

  • Testing both client-side and server-side TLS/SSL with HTTP and SMTP servers.

  • Verifying, encrypting and signing S/MIME email.

  • Generating and testing prime numbers, and generating pseudo-random data.

The following are some sample openssl commands.

Create a self-signed X.509 certificate that is valid for 365 days, writing the unencrypted private key to prikey.pem and the certificate to cert.pem.

# openssl req -x509 -nodes -days 365 -subj '/C=US/ST=Ca/L=Sunnydale/CN=www.unserdom.com' \
  -newkey rsa:1024 -keyout prikey.pem -out cert.pem

Test a self-signed certificate by launching a server that listens on port 443.

# openssl s_server -accept 443 -cert cert.pem -key prikey.pem -www

Test the client side of a connection. This command returns information about the connection including the certificate, and allows you to directly input HTTP commands.

# openssl s_client -connect server:443 -CAfile cert.pem

Convert a root certificate to a form that can be published on a web site for downloading by a browser.

# openssl x509 -in cert.pem -out rootcert.crt

Extract a certificate from a server.

# echo | openssl s_client -connect server:443 2>/dev/null | \
  sed -ne '/BEGIN CERT/,/END CERT/p' > svrcert.pem

Display the information contained in an X.509 certificate.

# openssl x509 -text -noout -in svrcert.pem

Display the SHA1 fingerprint of a certificate.

# openssl x509 -sha1 -noout -fingerprint -in cert.pem

Generate a CSR, writing the unencrypted private key to prikey.pem and the request to csr.pem for submission to a CA. The CA signs and returns a certificate or a certificate chain that authenticates your public key.

# openssl req -new -nodes '/CN=www.unserdom.com/O=Unser Dom, Corp./C=US/ST=Ca/L=Sunnydale' \
  -newkey rsa:1024 -keyout prikey.pem -out csr.pem

Display the information contained in a CSR.

# openssl req -in csr.pem -noout -text

Verify a certificate including the signing authority, signing chain, and period of validity.

# openssl verify cert.pem

Display the directory that holds information about the CAs trusted by your system. By default, this directory is /etc/pki/tls. The /etc/pki/tls/certs subdirectory contains trusted certificates.

# openssl version -d

Create an SHA1 digest of a file.

# openssl dgst -sha1 file

Sign the SHA1 digest of a file using the private key stored in the file prikey.pem.

# openssl dgst -sha1 -sign prikey.pem -out file.sha1 file

Verify the signed digest for a file using the public key stored in the file pubkey.pem.

# openssl dgst -sha1 -verify pubkey.pem -signature file.sha1 file

List all available ciphers.

# openssl list-cipher-commands

Encrypt a file using Blowfish.

# openssl enc -blowfish -salt -in file -out file.enc

Decrypt a Blowfish-encrypted file.

# openssl enc -d -blowfish -in file.enc -out file.dec

Convert a base 64 encoded certificate (also referred to as PEM or RFC 1421) to binary DER format.

# openssl x509 -in cert.pem -outform der -out certificate.der

Convert the base 64 encoded certificates for an entity and its CA to a single PKCS7 format certificate.

# openssl crl2pkcs7 -nocrl -certfile entCert.cer -certfile CACert.cer -out certificate.p7b 

For more information, see the openssl(1), ciphers(1), dgst(1), enc(1), req(1), s_client(1), s_server(1), verify(1), and x509(1) manual pages.

3.3.2 About the keytool Command

Most Java applications use the keystore that is supplied with the JDK to store cryptographic keys, X.509 certificate chain information, and trusted certificates. The default JDK keystore on Oracle Linux is the file /etc/pki/java/cacerts. You can use the keytool command to generate self-signed certificates and to install and manage certificates in the keystore. Note that the keytool command syntax changed in Java SE 6. The examples given here are for that version of keytool.

The following are some sample keytool commands.

List the contents of the keystore /etc/pki/java/cacerts. The default keystore password is changeit. If specified, the verbose option -v displays detailed information.

# keytool -list [-v] -keystore /etc/pki/java/cacerts

Change the password for a keystore (for example, /etc/pki/java/cacerts).

# keytool -storepasswd -keystore /etc/pki/java/cacerts

Create a new keystore keystore.jks for managing your public/private key pairs and certificates from entities that you trust, generate a public/private key pair using the RSA algorithm and a key length of 1024 bits, and create a self-signed certificate that includes the public key and the specified distinguished name information. pkpassword is the private key password and storepassword is the keystore password. The certificate is valid for 100 days and is associated with the private key in a keystore entry that has the alias engineering.

# keytool -genkeypair -alias mycert -keyalg RSA -keysize 1024 \
-dname "CN=www.unserdom.com, OU=Eng, O=Unser Dom Corp, C=US, ST=Ca, L=Sunnydale" \
-alias engineering -keypass pkpassword -keystore keystore.jks \
-storepass storepassword -validity 100

Print the contents of a certificate file in a human-readable form. If specified, the verbose option -v displays detailed information.

# keytool -printcert [-v] -file cert.cer

Generate a CSR in the file carequest.csr for submission to a CA. The CA signs and returns a certificate or a certificate chain that authenticates your public key.

# keytool -certreq -file carequest.csr

Import the root certificate or certificate chain for the CA from the file ACME.cer into the keystore keystore.jks and give it the alias acmeca. If specified, the -trustcacerts option instructs keytool to add the certificate only if it can validate the chain of trust against the existing root CA certificates in the cacerts keystore. Alternatively, use the keytool -printcert command to check that the certificate's fingerprint matches the fingerprint that the CA publishes.

# keytool -importcert -alias acmeca [-trustcacerts] -file ACME.cer \
  -keystore keystore.jks -storepass storepassword

Import the signed certificate for your organization after you have received it from the CA. In this example, the file containing the certificate is ACMEdom.cer. The -alias option specifies the entry for the first entity in the CA's root certificate chain. The signed certificate is added to the front of the chain and becomes the entity that is addressed by the alias name.

# keytool -importcert -v -trustcacerts -alias acmeca -file ACMEdom.cer \
  -keystore keystore.jks -storepass storepassword

Delete the certificate with the alias aliasname from the keystore keystore.jks.

# keytool -delete -alias aliasname -keystore keystore.jks -storepass storepassword

Export the certificate with the alias aliasname as a binary PKCS7 format file, which includes the supporting certificate chain as well as the issued certificate.

# keytool -exportcert -noprompt -alias aliasname -file output.p7b \
  -keystore keystore.jks -storepass storepassword

Export the certificate with the alias aliasname as a base 64 encoded text file (also referred to as PEM or RFC 1421). For a certificate chain. the file includes only the first certificate in the chain, which authenticates the public key of the aliased entity.

# keytool -exportcert -noprompt -rfc -alias aliasname -file output.pem \
  -keystore keystore.jks -storepass storepassword

For more information, see the keytool(1) manual page.