Blog

This guide is tested and works on RHEL 9.5. It should work on CentOS Stream 9.x, AlmaLinux 9.x and Rocky Linux 9.x as well.

Creating your own TLS certificate on RHEL 9 involves generating a self-signed certificate or setting up a local Certificate Authority (CA). Here’s how you can create a self-signed certificate:

Step 1: Install Required Tools.

Ensure openssl is installed. Run:

sudo dnf install -y openssl

Step 2: Create a Directory for the Certificate.

Organise your files in a dedicated directory:

mkdir ~/tls-certs

cd ~/tls-certs

Step 3: Generate a Private Key.

Use the following command to create a private key:

openssl genrsa -out private.key 2048

This generates a 2048-bit RSA private key named private.key.

Step 4: Create a Certificate Signing Request (CSR).

Generate a CSR, where you’ll specify the certificate details:

openssl req -new -key private.key -out request.csr

During this step, you’ll be prompted to provide information:

Country Name (2 letter code): Enter your country code (e.g., UK).

State or Province Name: Your state/province.

Locality Name (e.g., city): Your city.

Organisation Name: Your organisation name.

Organisational Unit Name: Department or unit.

Common Name: The domain name (e.g., example.com).

Email Address: Your email.

A challenge password []: read below.

A challenge password.

When creating a Certificate Signing Request (CSR) using OpenSSL, one of the prompts might ask for a challenge password. Here’s what it is:

What is a Challenge Password?

A challenge password is an optional field that can be used to add an extra layer of security when the CSR is submitted to a Certificate Authority (CA). This password serves two purposes:

1. It ensures that only someone who knows the password can modify or revoke the certificate.
2. It acts as a form of authentication during the certificate issuance or revocation process.

Should You Use a Challenge Password?

In most cases, you can leave this field blank by pressing Enter when prompted. Modern practices rarely use challenge passwords because they can add unnecessary complexity without significant benefits. Additionally:

• Many Certificate Authorities do not require or support this field.
• If you set a password, you must remember it and provide it whenever interacting with the CA regarding the certificate.

Example Prompt.

During the CSR generation process, you’ll see:

A challenge password []:

If you want to skip it, just press Enter.

When Might It Be Useful?

A challenge password could be useful in highly secure environments where additional authentication for certificate management is necessary. However, in most modern TLS setups (especially self-signed certificates), it’s typically unnecessary.

Step 5: Generate the Self-Signed Certificate.

Run this command to create a self-signed certificate valid for 365 days:

openssl x509 -req -days 365 -in request.csr -signkey private.key -out certificate.crt

This generates the certificate.crt file, which is the self-signed TLS certificate.

Step 6: Configure Your Web Server.

If you’re using Apache, update its configuration:

Copy the files:

sudo cp private.key certificate.crt /etc/pki/tls/private/

Edit your Apache virtual host file (e.g., /etc/httpd/conf.d/ssl.conf):

SSLCertificateFile /etc/pki/tls/private/certificate.crt

SSLCertificateKeyFile /etc/pki/tls/private/private.key

Restart Apache:

sudo systemctl restart httpd

For Nginx, add these lines to your server block:

ssl_certificate /path/to/certificate.crt;

ssl_certificate_key /path/to/private.key;

Then restart Nginx:

sudo systemctl restart nginx

Notes

Self-signed certificates are not trusted by browsers by default. You can add the certificate to your trusted store for testing. For production use, obtain a certificate from a trusted CA like Let’s Encrypt.