Search
SupportConsoleDevelopersStart a trialContact

Chapter 3. Creating and managing TLS keys and certificates

download PDF

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.

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

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

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

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

  3. 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 Chapter 4, Using shared system certificates for more information.

Verification

  1. 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 3.5, “Using a private CA to issue certificates for CSRs with OpenSSL” for more information.

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

  3. 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), and req(1) man pages

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

  1. Generate a private key on your server system, for example: 

    $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <server-private.key>

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

  3. 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, the req 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

Verification

  1. 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), and config(5) man pages

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

  1. Generate a private key on your client system, for example: 

    $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <client-private.key>

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

  3. 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, the req 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

Verification

  1. 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), and config(5) man pages

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

Procedure

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

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

Additional resources

  • openssl(1), ca(1), and x509(1) man pages

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

    $ dnf install gnutls-utils

Procedure

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

  2. Create a template file for a certificate.

    1. Create a file with a text editor of your choice, for example: 

      $ vi <ca.cfg>

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

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

  4. 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 Chapter 4, Using shared system certificates for more information.

Verification

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

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

    1. Generate a private key for your CA: 

      $ certtool --generate-privkey --outfile <example-server.key>

    2. Open a new configuration file in a text editor of your choice, for example: 

      $ vi <example-server.cfg>

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

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

    5. 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) and trust(1) man pages

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

  1. Generate a private key on your server system, for example: 

    $ certtool --generate-privkey --sec-param High --outfile <example-server.key>

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

  3. 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, the certool 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

Verification

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

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

  1. Generate a private key on your client system, for example: 

    $ certtool --generate-privkey --sec-param High --outfile <example-client.key>

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

  3. 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, the certtool 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

Verification

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

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

Procedure

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

  2. 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
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.