Chapter 2. Creating and managing TLS keys and certificates You can encrypt communication transmitted between two systems by using the TLS (Transport Layer Security) protocol. This standard uses asymmetric cryptography with private and public keys, digital signatures, and certificates. 2.1. TLS certificates TLS (Transport Layer Security) is a protocol that enables client-server applications to pass information securely. TLS uses a system of public and private key pairs to encrypt communication transmitted between clients and servers. TLS is the successor protocol to SSL (Secure Sockets Layer). TLS uses X.509 certificates to bind identities, such as hostnames or organizations, to public keys using digital signatures. X.509 is a standard that defines the format of public key certificates. Authentication of a secure application depends on the integrity of the public key value in the application's certificate. If an attacker replaces the public key with its own public key, it can impersonate the true application and gain access to secure data. To prevent this type of attack, all certificates must be signed by a certification authority (CA). A CA is a trusted node that confirms the integrity of the public key value in a certificate. A CA signs a public key by adding its digital signature and issues a certificate. A digital signature is a message encoded with the CA's private key. The CA's public key is made available to applications by distributing the certificate of the CA. Applications verify that certificates are validly signed by decoding the CA's digital signature with the CA's public key. To have a certificate signed by a CA, you must generate a public key, and send it to a CA for signing. This is referred to as a certificate signing request (CSR). A CSR contains also a distinguished name (DN) for the certificate. The DN information that you can provide for either type of certificate can include a two-letter country code for your country, a full name of your state or province, your city or town, a name of your organization, your email address, and it can also be empty. Many current commercial CAs prefer the Subject Alternative Name extension and ignore DNs in CSRs. RHEL provides two main toolkits for working with TLS certificates: GnuTLS and OpenSSL. You can create, read, sign, and verify certificates using the openssl utility from the openssl package. The certtool utility provided by the gnutls-utils package can do the same operations using a different syntax and above all a different set of libraries in the back end. Additional resources RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile openssl(1) , x509(1) , ca(1) , req(1) , and certtool(1) man pages on your system 2.2. Creating a private CA using OpenSSL Private certificate authorities (CA) are useful when your scenario requires verifying entities within your internal network. For example, use a private CA when you create a VPN gateway with authentication based on certificates signed by a CA under your control or when you do not want to pay a commercial CA. To sign certificates in such use cases, the private CA uses a self-signed certificate. Prerequisites You have root privileges or permissions to enter administrative commands with sudo . Commands that require such privileges are marked with # . Procedure Generate a private key for your CA. For example, the following command creates a 256-bit Elliptic Curve Digital Signature Algorithm (ECDSA) key: The time for the key-generation process depends on the hardware and entropy of the host, the selected algorithm, and the length of the key. Create a certificate signed using the private key generated in the command: The generated ca.crt file is a self-signed CA certificate that you can use to sign other certificates for ten years. In the case of a private CA, you can replace <Example CA> with any string as the common name (CN). Set secure permissions on the private key of your CA, for example: steps To use a self-signed CA certificate as a trust anchor on client systems, copy the CA certificate to the client and add it to the clients' system-wide truststore as root : See Chapter 3, Using shared system certificates for more information. Verification Create a certificate signing request (CSR), and use your CA to sign the request. The CA must successfully create a certificate based on the CSR, for example: See Section 2.5, "Using a private CA to issue certificates for CSRs with OpenSSL" for more information. Display the basic information about your self-signed CA: Verify the consistency of the private key: Additional resources openssl(1) , ca(1) , genpkey(1) , x509(1) , and req(1) man pages on your system 2.3. Creating a private key and a CSR for a TLS server certificate using OpenSSL You can use TLS-encrypted communication channels only if you have a valid TLS certificate from a certificate authority (CA). To obtain the certificate, you must create a private key and a certificate signing request (CSR) for your server first. Procedure Generate a private key on your server system, for example: Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example: The extendedKeyUsage = serverAuth option limits the use of a certificate. Create a CSR using the private key you created previously: If you omit the -config option, the req utility prompts you for additional information, for example: steps Submit the CSR to a CA of your choice for signing. Alternatively, for an internal use scenario within a trusted network, use your private CA for signing. See Section 2.5, "Using a private CA to issue certificates for CSRs with OpenSSL" for more information. Verification After you obtain the requested certificate from the CA, check that the human-readable parts of the certificate match your requirements, for example: Additional resources openssl(1) , x509(1) , genpkey(1) , req(1) , and config(5) man pages on your system 2.4. Creating a private key and a CSR for a TLS client certificate using OpenSSL You can use TLS-encrypted communication channels only if you have a valid TLS certificate from a certificate authority (CA). To obtain the certificate, you must create a private key and a certificate signing request (CSR) for your client first. Procedure Generate a private key on your client system, for example: Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example: The extendedKeyUsage = clientAuth option limits the use of a certificate. Create a CSR using the private key you created previously: If you omit the -config option, the req utility prompts you for additional information, for example: steps Submit the CSR to a CA of your choice for signing. Alternatively, for an internal use scenario within a trusted network, use your private CA for signing. See Section 2.5, "Using a private CA to issue certificates for CSRs with OpenSSL" for more information. Verification Check that the human-readable parts of the certificate match your requirements, for example: Additional resources openssl(1) , x509(1) , genpkey(1) , req(1) , and config(5) man pages on your system 2.5. Using a private CA to issue certificates for CSRs with OpenSSL To enable systems to establish a TLS-encrypted communication channel, a certificate authority (CA) must provide valid certificates to them. If you have a private CA, you can create the requested certificates by signing certificate signing requests (CSRs) from the systems. Prerequisites You have already configured a private CA. See Section 2.2, "Creating a private CA using OpenSSL" for more information. You have a file containing a CSR. You can find an example of creating the CSR in Section 2.3, "Creating a private key and a CSR for a TLS server certificate using OpenSSL" . Procedure Optional: Use a text editor of your choice to prepare an OpenSSL configuration file for adding extensions to certificates, for example: Note that the example illustrates only the principle and openssl does not add all extensions to the certificate automatically. You must add the extensions you require either to the CNF file or append them to parameters of the openssl command. Use the x509 utility to create a certificate based on a CSR, for example: Additional resources openssl(1) , ca(1) , and x509(1) man pages on your system 2.6. Creating a private CA using GnuTLS Private certificate authorities (CA) are useful when your scenario requires verifying entities within your internal network. For example, use a private CA when you create a VPN gateway with authentication based on certificates signed by a CA under your control or when you do not want to pay a commercial CA. To sign certificates in such use cases, the private CA uses a self-signed certificate. Prerequisites You have root privileges or permissions to enter administrative commands with sudo . Commands that require such privileges are marked with # . You have already installed GnuTLS on your system. If you did not, you can use this command: Procedure Generate a private key for your CA. For example, the following command creates a 256-bit ECDSA (Elliptic Curve Digital Signature Algorithm) key: The time for the key-generation process depends on the hardware and entropy of the host, the selected algorithm, and the length of the key. Create a template file for a certificate. Create a file with a text editor of your choice, for example: Edit the file to include the necessary certification details: Create a certificate signed using the private key generated in step 1: The generated <ca.crt> file is a self-signed CA certificate that you can use to sign other certificates for one year. <ca.crt> file is the public key (certificate). The loaded file <ca.key> is the private key. You should keep this file in safe location. Set secure permissions on the private key of your CA, for example: steps To use a self-signed CA certificate as a trust anchor on client systems, copy the CA certificate to the client and add it to the clients' system-wide truststore as root : See Chapter 3, Using shared system certificates for more information. Verification Display the basic information about your self-signed CA: Create a certificate signing request (CSR), and use your CA to sign the request. The CA must successfully create a certificate based on the CSR, for example: Generate a private key for your CA: Open a new configuration file in a text editor of your choice, for example: Edit the file to include the necessary certification details: Generate a request with the previously created private key: Generate the certificate and sign it with the private key of the CA: Additional resources certtool(1) and trust(1) man pages on your system 2.7. Creating a private key and a CSR for a TLS server certificate using GnuTLS To obtain the certificate, you must create a private key and a certificate signing request (CSR) for your server first. Procedure Generate a private key on your server system, for example: Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example: Create a CSR using the private key you created previously: If you omit the --template option, the certool utility prompts you for additional information, for example: steps Submit the CSR to a CA of your choice for signing. Alternatively, for an internal use scenario within a trusted network, use your private CA for signing. See Section 2.9, "Using a private CA to issue certificates for CSRs with GnuTLS" for more information. Verification After you obtain the requested certificate from the CA, check that the human-readable parts of the certificate match your requirements, for example: Additional resources certtool(1) man page on your system 2.8. Creating a private key and a CSR for a TLS client certificate using GnuTLS To obtain the certificate, you must create a private key and a certificate signing request (CSR) for your client first. Procedure Generate a private key on your client system, for example: Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example: Create a CSR using the private key you created previously: If you omit the --template option, the certtool utility prompts you for additional information, for example: steps Submit the CSR to a CA of your choice for signing. Alternatively, for an internal use scenario within a trusted network, use your private CA for signing. See Section 2.9, "Using a private CA to issue certificates for CSRs with GnuTLS" for more information. Verification Check that the human-readable parts of the certificate match your requirements, for example: Additional resources certtool(1) man page on your system 2.9. Using a private CA to issue certificates for CSRs with GnuTLS To enable systems to establish a TLS-encrypted communication channel, a certificate authority (CA) must provide valid certificates to them. If you have a private CA, you can create the requested certificates by signing certificate signing requests (CSRs) from the systems. Prerequisites You have already configured a private CA. See Section 2.6, "Creating a private CA using GnuTLS" for more information. You have a file containing a CSR. You can find an example of creating the CSR in Section 2.7, "Creating a private key and a CSR for a TLS server certificate using GnuTLS" . Procedure Optional: Use a text editor of your choice to prepare an GnuTLS configuration file for adding extensions to certificates, for example: Use the certtool utility to create a certificate based on a CSR, for example: Additional resources certtool(1) man page on your system

Commands:
openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <ca.key>
openssl req -key <ca.key> -new -x509 -days 3650 -addext keyUsage=critical,keyCertSign,cRLSign -subj "/CN= <Example CA> " -out <ca.crt>
chown <root> : <root> <ca.key> chmod 600 <ca.key>
trust anchor <ca.crt>
openssl x509 -req -in <client-cert.csr> -CA <ca.crt> -CAkey <ca.key> -CAcreateserial -days 365 -extfile <openssl.cnf> -extensions <client-cert> -out <client-cert.crt> Signature ok subject=C = US, O = Example Organization, CN = server.example.com Getting CA Private Key
openssl x509 -in <ca.crt> -text -noout Certificate: ... X509v3 extensions: ... X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign ...
openssl pkey -check -in <ca.key> Key is valid -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgcagSaTEBn74xZAwO 18wRpXoCVC9vcPki7WlT+gnmCI+hRANCAARb9NxIvkaVjFhOoZbGp/HtIQxbM78E lwbDP0BI624xBJ8gK68ogSaq2x4SdezFdV1gNeKScDcU+Pj2pELldmdF -----END PRIVATE KEY-----
openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <server-private.key>
vim <example_server.cnf> [server-cert] keyUsage = critical, digitalSignature, keyEncipherment, keyAgreement extendedKeyUsage = serverAuth subjectAltName = @alt_name [req] distinguished_name = dn prompt = no [dn] C = <US> O = <Example Organization> CN = <server.example.com> [alt_name] DNS.1 = <example.com> DNS.2 = <server.example.com> IP.1 = <192.168.0.1> IP.2 = <::1> IP.3 = <127.0.0.1>
openssl req -key <server-private.key> -config <example_server.cnf> -new -out <server-cert.csr>
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]: <US> State or Province Name (full name) []: <Washington> Locality Name (eg, city) [Default City]: <Seattle> Organization Name (eg, company) [Default Company Ltd]: <Example Organization> Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []: <server.example.com> Email Address []: <server@example.com>
openssl x509 -text -noout -in <server-cert.crt> Certificate: ... Issuer: CN = Example CA Validity Not Before: Feb 2 20:27:29 2023 GMT Not After : Feb 2 20:27:29 2024 GMT Subject: C = US, O = Example Organization, CN = server.example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) ... X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: DNS:example.com, DNS:server.example.com, IP Address:192.168.0.1, IP ...
openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <client-private.key>
vim <example_client.cnf> [client-cert] keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth subjectAltName = @alt_name [req] distinguished_name = dn prompt = no [dn] CN = <client.example.com> [clnt_alt_name] email= <client@example.com>
openssl req -key <client-private.key> -config <example_client.cnf> -new -out <client-cert.csr>
You are about to be asked to enter information that will be incorporated into your certificate request. ... Common Name (eg, your name or your server's hostname) []: <client.example.com> Email Address []: <client@example.com>
openssl x509 -text -noout -in <client-cert.crt> Certificate: ... X509v3 Extended Key Usage: TLS Web Client Authentication X509v3 Subject Alternative Name: email:client@example.com ...
vim <openssl.cnf> [server-cert] extendedKeyUsage = serverAuth [client-cert] extendedKeyUsage = clientAuth
openssl x509 -req -in <server-cert.csr> -CA <ca.crt> -CAkey <ca.key> -days 365 -extfile <openssl.cnf> -extensions <server-cert> -out <server-cert.crt> Signature ok subject=C = US, O = Example Organization, CN = server.example.com Getting CA Private Key
dnf install gnutls-utils
certtool --generate-privkey --sec-param High --key-type=ecdsa --outfile <ca.key>
vi <ca.cfg>
organization = "Example Inc." state = "Example" country = EX cn = "Example CA" serial = 007 expiration_days = 365 ca cert_signing_key crl_signing_key
certtool --generate-self-signed --load-privkey <ca.key> --template <ca.cfg> --outfile <ca.crt >
chown <root> : <root> <ca.key> chmod 600 <ca.key>
trust anchor <ca.crt>
certtool --certificate-info --infile <ca.crt> Certificate: ... X509v3 extensions: ... X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign
certtool --generate-privkey --outfile <example-server.key>
vi <example-server.cfg>
signing_key encryption_key key_agreement tls_www_server country = "US" organization = "Example Organization" cn = "server.example.com" dns_name = "example.com" dns_name = "server.example.com" ip_address = "192.168.0.1" ip_address = "::1" ip_address = "127.0.0.1"
certtool --generate-request --load-privkey <example-server.key> --template <example-server.cfg> --outfile <example-server.crq>
certtool --generate-certificate --load-request <example-server.crq> --load-ca-certificate <ca.crt> --load-ca-privkey <ca.key> --outfile <example-server.crt>
certtool --generate-privkey --sec-param High --outfile <example-server.key>
vim <example_server.cnf> signing_key encryption_key key_agreement tls_www_server country = "US" organization = "Example Organization" cn = "server.example.com" dns_name = "example.com" dns_name = "server.example.com" ip_address = "192.168.0.1" ip_address = "::1" ip_address = "127.0.0.1"
certtool --generate-request --template <example-server.cfg> --load-privkey <example-server.key> --outfile <example-server.crq>
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Generating a PKCS #10 certificate request Country name (2 chars): <US> State or province name: <Washington> Locality name: <Seattle> Organization name: <Example Organization> Organizational unit name: Common name: <server.example.com>
certtool --certificate-info --infile <example-server.crt> Certificate: ... Issuer: CN = Example CA Validity Not Before: Feb 2 20:27:29 2023 GMT Not After : Feb 2 20:27:29 2024 GMT Subject: C = US, O = Example Organization, CN = server.example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) ... X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: DNS:example.com, DNS:server.example.com, IP Address:192.168.0.1, IP ...
certtool --generate-privkey --sec-param High --outfile <example-client.key>
vim <example_client.cnf> signing_key encryption_key tls_www_client cn = "client.example.com" email = "client@example.com"
certtool --generate-request --template <example-client.cfg> --load-privkey <example-client.key> --outfile <example-client.crq>
Generating a PKCS #10 certificate request Country name (2 chars): <US> State or province name: <Washington> Locality name: <Seattle> Organization name: <Example Organization> Organizational unit name: Common name: <server.example.com>
certtool --certificate-info --infile <example-client.crt> Certificate: ... X509v3 Extended Key Usage: TLS Web Client Authentication X509v3 Subject Alternative Name: email:client@example.com ...
vi <server-extensions.cfg> honor_crq_extensions ocsp_uri = "http://ocsp.example.com"
certtool --generate-certificate --load-request <example-server.crq> --load-ca-privkey <ca.key> --load-ca-certificate <ca.crt> --template <server-extensions.cfg> --outfile <example-server.crt>