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)
, andcerttool(1)
man pages on your system
2.2. Creating a private CA by 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 withsudo
. 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:
$ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <ca.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 previous command:
$ openssl req -key <ca.key> -new -x509 -days 3650 -addext keyUsage=critical,keyCertSign,cRLSign -subj "/CN=<Example CA>" -out <ca.crt>
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:
# chown <root>:<root> <ca.key> # chmod 600 <ca.key>
Next 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
:# trust anchor <ca.crt>
See the Using shared system certificates chapter 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:
$ 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
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:
$ openssl x509 -in <ca.crt> -text -noout Certificate: … X509v3 extensions: … X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign …
Verify the consistency of the private key:
$ openssl pkey -check -in <ca.key> Key is valid -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgcagSaTEBn74xZAwO 18wRpXoCVC9vcPki7WlT+gnmCI+hRANCAARb9NxIvkaVjFhOoZbGp/HtIQxbM78E lwbDP0BI624xBJ8gK68ogSaq2x4SdezFdV1gNeKScDcU+Pj2pELldmdF -----END PRIVATE KEY-----
Additional resources
-
openssl(1)
,ca(1)
,genpkey(1)
,x509(1)
, andreq(1)
man pages on your system
2.3. Creating a private key and a CSR for a TLS server certificate by 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:
$ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <server-private.key>
Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example:
$ 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>
The
extendedKeyUsage = serverAuth
option limits the use of a certificate.Create a CSR using the private key you created previously:
$ openssl req -key <server-private.key> -config <example_server.cnf> -new -out <server-cert.csr>
If you omit the
-config
option, thereq
utility prompts you for additional information, for example: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>
Next 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:
$ 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 …
Additional resources
-
openssl(1)
,x509(1)
,genpkey(1)
,req(1)
, andconfig(5)
man pages on your system
2.4. Creating a private key and a CSR for a TLS client certificate by 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:
$ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <client-private.key>
Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example:
$ 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>
The
extendedKeyUsage = clientAuth
option limits the use of a certificate.Create a CSR using the private key you created previously:
$ openssl req -key <client-private.key> -config <example_client.cnf> -new -out <client-cert.csr>
If you omit the
-config
option, thereq
utility prompts you for additional information, for example: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>
Next 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:
$ 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 …
Additional resources
-
openssl(1)
,x509(1)
,genpkey(1)
,req(1)
, andconfig(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 by 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 by using OpenSSL” .
Procedure
Optional: Use a text editor of your choice to prepare an OpenSSL configuration file for adding extensions to certificates, for example:
$ vim <openssl.cnf> [server-cert] extendedKeyUsage = serverAuth [client-cert] extendedKeyUsage = clientAuth
Use the
x509
utility to create a certificate based on a CSR, for example:$ 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
To increase security, delete the serial-number file before you create another certificate from a CSR. This way, you ensure that the serial number is always random. If you omit the
CAserial
option for specifying a custom file name, the serial-number file name is the same as the file name of the certificate, but its extension is replaced with the.srl
extension (server-cert.srl
in the previous example).
Additional resources
-
openssl(1)
,ca(1)
, andx509(1)
man pages on your system
2.6. Creating a private CA by 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 withsudo
. 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:
$ dnf install gnutls-utils
Procedure
Generate a private key for your CA. For example, the following command creates a 256-bit ECDSA (Elliptic Curve Digital Signature Algorithm) key:
$ certtool --generate-privkey --sec-param High --key-type=ecdsa --outfile <ca.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:
$ vi <ca.cfg>
Edit the file to include the necessary certification details:
organization = "Example Inc." state = "Example" country = EX cn = "Example CA" serial = 007 expiration_days = 365 ca cert_signing_key crl_signing_key
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.
$ certtool --generate-self-signed --load-privkey <ca.key> --template <ca.cfg> --outfile <ca.crt>
Set secure permissions on the private key of your CA, for example:
# chown <root>:<root> <ca.key> # chmod 600 <ca.key>
Next 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
:# trust anchor <ca.crt>
See the Using shared system certificates chapter for more information.
Verification
Display the basic information about your self-signed CA:
$ certtool --certificate-info --infile <ca.crt> Certificate: … X509v3 extensions: … X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign
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:
$ certtool --generate-privkey --outfile <example-server.key>
Open a new configuration file in a text editor of your choice, for example:
$ vi <example-server.cfg>
Edit the file to include the necessary certification details:
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"
Generate a request with the previously created private key:
$ certtool --generate-request --load-privkey <example-server.key> --template <example-server.cfg> --outfile <example-server.crq>
Generate the certificate and sign it with the private key of the CA:
$ certtool --generate-certificate --load-request <example-server.crq> --load-ca-certificate <ca.crt> --load-ca-privkey <ca.key> --outfile <example-server.crt>
Additional resources
-
certtool(1)
andtrust(1)
man pages on your system
-
2.7. Creating a private key and a CSR for a TLS server certificate by 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:
$ certtool --generate-privkey --sec-param High --outfile <example-server.key>
Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example:
$ 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"
Create a CSR using the private key you created previously:
$ certtool --generate-request --template <example-server.cfg> --load-privkey <example-server.key> --outfile <example-server.crq>
If you omit the
--template
option, thecertool
utility prompts you for additional information, for example: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>
Next 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:
$ 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 …
Additional resources
-
certtool(1)
man page on your system
2.8. Creating a private key and a CSR for a TLS client certificate by 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:
$ certtool --generate-privkey --sec-param High --outfile <example-client.key>
Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example:
$ vim <example_client.cnf> signing_key encryption_key tls_www_client cn = "client.example.com" email = "client@example.com"
Create a CSR using the private key you created previously:
$ certtool --generate-request --template <example-client.cfg> --load-privkey <example-client.key> --outfile <example-client.crq>
If you omit the
--template
option, thecerttool
utility prompts you for additional information, for example: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>
Next 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:
$ certtool --certificate-info --infile <example-client.crt> Certificate: … X509v3 Extended Key Usage: TLS Web Client Authentication X509v3 Subject Alternative Name: email:client@example.com …
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 by 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 by using GnuTLS” .
Procedure
Optional: Use a text editor of your choice to prepare an GnuTLS configuration file for adding extensions to certificates, for example:
$ vi <server-extensions.cfg> honor_crq_extensions ocsp_uri = "http://ocsp.example.com"
Use the
certtool
utility to create a certificate based on a CSR, for example:$ 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>
Additional resources
-
certtool(1)
man page on your system