Learn Rocky Linux - TLS, Certificates & PKI

#Introduction

In the previous episode 15, you secured the front door with SSH. Now we discuss how web services and APIs prove their identity: TLS and certificates. Every time a browser shows the green padlock, a chain of cryptography is at work — keys, certificates, and a chain of certificate authorities (CAs) that trust one another.

This episode takes you from zero: creating keys and certificates with OpenSSL, understanding the difference between self-signed certificates and those issued by Let's Encrypt, managing the CAs trusted by the system, and the concept of revocation with CRL and OCSP. Everything builds on the foundation you already have — including the correct hostname from episode 9, because certificates are tied to names.

#TLS Fundamentals with OpenSSL

#Keys and Certificates

TLS secures communication with encryption and authentication. Its two core artifacts:

• Private key — secret, must never leak; used to decrypt and sign.
• Certificate — contains the public key, host identity, and the issuer's signature; distributed publicly.

#Creating Keys, CSRs, and Certificates

The standard flow: create a key, create a CSR (Certificate Signing Request), then ask a CA to sign it into a certificate.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=web01.example.com"

openssl req -in server.csr -noout -text

-subj sets the Common Name (CN) — the hostname the certificate will be used with. For production, you must use a trusted CA to sign the CSR.

#Creating a Self-Signed Certificate

For internal testing, self-signed — a certificate that signs itself — is sufficient:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout server.key -out server.crt -days 365 \
  -subj "/CN=web01.example.com"

openssl x509 -in server.crt -noout -text
openssl x509 -in server.crt -noout -dates

Self-signed certificates are not trusted by browsers, but they are very useful in a lab environment — and they are the foundation for understanding the chain of trust.

#Trusted CAs and Trust Stores

#Updating the Trust Store

Every system keeps a list of trusted CAs — the trust store. Adding an internal CA to the trust store makes system applications trust the certificates it issues:

cp my-ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract

trust list | grep -i my-ca

update-ca-trust extract rebuilds the trust store from all anchors. After this, applications that use the system trust store trust certificates signed by that CA.

#Checking the Chain of Trust

Full verification involves a chain: leaf certificate → intermediate → root CA:

openssl verify -CAfile ca-bundle.crt server.crt

openssl x509 -in server.crt -noout -issuer

An OK output means the certificate is valid against the given CA. This is a quick way to confirm the web server configuration is correct.

#Certificates for Servers

#Let's Encrypt with Certbot

For public servers, Let's Encrypt provides free certificates trusted by all browsers. Certbot automates the entire process:

dnf5 install certbot python3-certbot-apache

certbot --apache -d web01.example.com

certbot renew --dry-run

Certbot renews certificates automatically before they expire — Let's Encrypt certificates are only valid for 90 days, so automatic renewal is not optional.

#Installing into a Web Server

A certificate is installed into a web server through three files: the certificate, the key, and the CA chain:

SSLCertificateFile      /etc/letsencrypt/live/web01.example.com/fullchain.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/web01.example.com/privkey.pem

curl -v https://web01.example.com

The curl -v output shows the certificate chain and TLS status — a quick way to confirm the installation succeeded.

#Revocation and PKI Basics

#The Concept of Revocation

A certificate can become invalid before it expires — a key leaks, a domain moves, an employee leaves. That's where revocation comes in. There are two mechanisms:

• CRL (Certificate Revocation List) — a periodic list of revoked certificates.
• OCSP (Online Certificate Status Protocol) — real-time per-certificate status checking.

openssl x509 -in server.crt -noout -text | grep -A2 "CRL Distribution"

openssl ocsp -issuer ca.crt -cert server.crt -url http://ocsp.example.com

An OCSP response of revoked or good tells you the certificate's status directly — the basis of real-time trust.

#Becoming a Simple CA

For internal environments, you can become your own CA with openssl ca:

mkdir -p /etc/pki/myca/{newcerts,private}
touch /etc/pki/myca/index.txt
echo 1000 > /etc/pki/myca/serial

openssl ca -config /etc/pki/myca/openssl.cnf \
  -in server.csr -out server.crt -days 365

Once your internal CA is up, you issue and revoke certificates as needed — and add its root CA to the trust store with the update-ca-trust you already learned.

#Closing

In this episode 16, you understood TLS and PKI on Rocky Linux: creating keys, CSRs, and certificates with OpenSSL, managing the trust store with update-ca-trust, the difference between self-signed and Let's Encrypt through certbot, installing into a web server, and the revocation concepts of CRL and OCSP as well as the basics of becoming an internal CA.

Key takeaways:

• TLS requires a private key (secret) and a certificate (public) tied to the hostname.
• Self-signed for labs; Let's Encrypt with certbot for public services.
• Add internal CAs to the trust store with update-ca-trust extract.
• Verify the chain with openssl verify and from the client side with curl -v.
• Revocation through CRL and OCSP maintains trust when a certificate is no longer valid.

In the next episode 17, we will discuss performance tuning and resource control — tuning profiles with tuned-adm, kernel parameters, systemd resource control with cgroups v2, and boot analysis with systemd-analyze. The padlock is installed; now it's time to make sure the machine runs at full speed!