Learning AlmaLinux - TLS, Certificates & PKI

#Introduction

In the previous episode, Episode 14, we secured remote access with SSH. Now we secure data in transit with TLS: the protocol protecting all HTTPS traffic on the internet. For modern servers, TLS certificates are no longer optional — without HTTPS, browsers mark sites as unsafe and many APIs refuse connections.

This episode takes you from OpenSSL basics, distinguishing certificate types, managing the system trust store, automating Let's Encrypt certificates, to understanding PKI concepts.

#OpenSSL and Certificates

OpenSSL is the Linux standard cryptography toolkit. Digital certificates work with asymmetric cryptography: a private key (secret, stored on the server) and a public key (shared). A certificate is a document binding a public key to an identity, signed by a trusted authority.

#Generating Keys and CSRs

The first step in creating a certificate: generate a private key, then create a CSR (Certificate Signing Request) — the formal request to a CA:

openssl ecparam -name prime256v1 -genkey -out domain.key
openssl req -new -key domain.key -out domain.csr

The example above uses the prime256v1 EC curve — modern and fast. During openssl req, you'll be asked for the organization name, Common Name (= the domain), and other details. To automate all the answers, use a configuration file:

[req]
distinguished_name = dn
prompt = no
 
[dn]
CN = example.com
 
[req_ext]
subjectAltName = DNS:example.com, DNS:www.example.com

subjectAltName (SAN) is the modern field that determines which domains a certificate protects — modern browsers ignore the Common Name and only read the SAN.

#Self-Signed Certificates

Self-signed means the certificate is signed by itself, not by a trusted CA:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes

Suitable for labs and testing. Browsers will show a warning, since no CA can verify it — never use self-signed certificates for public production.

#Self-Signed vs CA-Signed

CA-signed certificates come from a CSR sent to a CA — Let's Encrypt, or a commercial CA — which then returns a signed certificate.

#The Trust Store: update-ca-trust

Every system stores a list of trusted CAs. On AlmaLinux, this list is managed through the CA bundle in /etc/pki/ca-trust/ — and modified with update-ca-trust.

#Adding an Internal CA

For a lab with its own CA (for example a company internal CA), add the CA certificate to the trust store:

sudo cp internal-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

After that, all system tools — curl, wget, Python, Java — automatically trust certificates signed by that CA.

#Verifying Certificates

openssl x509 -in cert.pem -text -noout
openssl verify cert.pem

openssl verify checks the trust chain against the system trust store. If the output shows OK, the certificate chain is valid.

#Let's Encrypt and Certbot

Let's Encrypt is a free CA that issues certificates with a 90-day validity, automated via certbot.

sudo dnf5 install -y certbot python3-certbot-nginx

For the Nginx web server:

sudo certbot --nginx -d example.com -d www.example.com

Certbot detects the Nginx configuration, issues the certificate, and configures HTTPS automatically. For servers without a web server installed, use certonly mode:

sudo certbot certonly --standalone -d example.com

#Auto-Renewal

Since Let's Encrypt certificates last only 90 days, automatic renewal is a must. Certbot provides a systemd timer:

sudo systemctl list-timers | grep certbot
sudo certbot renew --dry-run

certbot renew --dry-run tests the renewal process without actually renewing — a mandatory ritual to schedule periodically so renewal failures don't surprise you on day 90.

#PKI Basics: OCSP and CRL

PKI (Public Key Infrastructure) is the complete ecosystem of CAs, certificates, and revocation mechanisms. Two revocation mechanisms worth knowing:

When a certificate's private key leaks, it must be revoked. Verify a certificate's OCSP status:

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

Understanding PKI lets you manage an internal CA — useful for labs, VPNs, and enterprise environments that need certificates for many internal services.

#Common Pitfalls

1. Using self-signed certificates in production. Use Let's Encrypt or a commercial CA for public services.
2. Forgetting SAN. Certificates that only list the Common Name are rejected by modern browsers — always include subjectAltName.
3. Disabling TLS verification to "go faster". Never disable certificate validation on production clients.
4. Ignoring renewal. Expired certificates cause downtime — install the timer and test --dry-run.
5. Forgetting update-ca-trust after adding a CA. Copying the file alone isn't enough; the new bundle only applies after that command.

#Conclusion

In this episode 15 you've built the encryption foundation: generating keys and CSRs with OpenSSL, the self-signed vs CA-signed difference, trust store management with update-ca-trust, Let's Encrypt certificate automation with certbot, and a PKI introduction with OCSP and CRL.

Key takeaways:

• OpenSSL generates keys, CSRs, and certificates; include subjectAltName in every request.
• Self-signed for labs, CA-signed for production — use Let's Encrypt for free.
• The system trust store is managed with update-ca-trust after adding a CA to /etc/pki/ca-trust/source/anchors/.
• Certbot automates issuance and renewal — verify the timer and --dry-run.
• OCSP and CRL are certificate revocation mechanisms in PKI.

With encryption in place, you're ready to build comprehensive defense. In the next episode, Episode 16, we'll cover Security Compliance & Hardening — OpenSCAP and SCAP profiles, the CIS Benchmarks and STIG baselines, the lynis audit tool, AIDE integrity monitoring, and the ClamAV antivirus. See you there!