208.2 Apache configuration for HTTPS

Introduction

HTTPS combines identity, encryption, and integrity. A working certificate is not enough: host names, chain order, private-key protection, protocol versions, and virtual-host selection must all be correct.

What you should be able to do after this lesson:

• Generate a private key and certificate signing request.
• Create a self-signed certificate for testing.
• Install a certificate and intermediate chain.
• Configure an Apache TLS virtual host.
• Explain SNI and harden protocols and ciphers.

Big Idea: Identity Must Survive the Whole TLS Path

An HTTPS client validates several connected facts:

requested host -> SNI virtual host -> presented certificate name
-> intermediate chain -> trusted root -> validity and policy

The server can successfully negotiate encryption and still fail identity validation because one link is wrong.

Private Keys and CSRs

openssl genpkey -algorithm RSA -out example.test.key -pkeyopt rsa_keygen_bits:3072
openssl req -new -key example.test.key -out example.test.csr

The private key must remain secret. The CSR contains the public key and requested identity information. Modern certificates identify hosts through Subject Alternative Name entries.

Inspect files:

openssl req -in example.test.csr -noout -text
openssl x509 -in example.test.crt -noout -text

Self-Signed Certificates

openssl req -x509 -new -key example.test.key -days 30 -out example.test.crt

A self-signed certificate can encrypt traffic but is not trusted automatically by clients. Use it for controlled testing or distribute an appropriate trust anchor.

Certificate and CA files commonly live below /etc/ssl/ or /etc/pki/, depending on the distribution. CA.pl is a historical OpenSSL helper worth recognizing; production certificate lifecycle normally uses controlled CA tooling and automation.

Apache TLS Virtual Host

<VirtualHost *:443>
    ServerName example.test
    DocumentRoot /srv/www/example

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.test-fullchain.pem
    SSLCertificateKeyFile /etc/ssl/private/example.test.key
</VirtualHost>

Certificate-chain directives vary by Apache version and packaging. Ensure the server presents required intermediates but not an unnecessary root certificate.

Directives such as SSLCACertificateFile and SSLCACertificatePath configure trusted CA material for features such as client-certificate validation. They are not substitutes for the server certificate chain sent to ordinary clients.

SNI

Server Name Indication lets the client send the requested host name during the TLS handshake, allowing several HTTPS virtual hosts to share one address. Very old clients without SNI may receive the default certificate.

Check virtual-host mapping and the presented certificate:

apachectl -S
openssl s_client -connect 192.0.2.80:443 -servername example.test -showcerts

Protocol and Cipher Hardening

Disable obsolete SSL and TLS versions and use a current distribution security policy. Relevant directives include SSLProtocol and SSLCipherSuite.

Reduce information exposure with settings such as:

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Do not paste a cipher list without testing it against required clients and the installed OpenSSL version.

Deployment Checklist

1. Match every required DNS name in the certificate.
2. Protect the private key and back it up securely.
3. Install the complete chain.
4. Validate Apache configuration.
5. Reload and test with SNI.
6. Monitor expiry and automate renewal where possible.

Guided Practice: Inspect a TLS Service

Use a lab endpoint or a public service you are authorized to test:

openssl s_client -connect example.test:443 -servername example.test -showcerts

Record:

• negotiated TLS version and cipher
• leaf certificate Subject Alternative Names
• issuer and validity period
• intermediate certificates sent by the server
• final verification result

Then test the Apache mapping with apachectl -S and compare the certificate returned with and without the intended SNI name. Generate a private key and CSR in a protected lab directory, inspect the CSR, and delete the lab key securely when finished.

Troubleshooting Scenario

Browsers trust the certificate on desktop systems but fail on a clean mobile client. The server sends only its leaf certificate; desktops happen to have the missing intermediate cached.

Install and serve the correct intermediate chain, validate configuration, reload, and test from a clean client. Reissuing the leaf certificate is unnecessary when the certificate itself is valid and the chain delivery is incomplete.

Exam Focus

• Distinguish private keys, CSRs, leaf certificates, intermediate CAs, and trust roots.
• Know SNI's role in selecting a certificate on shared addresses.
• Recognize SSLEngine, certificate and CA directives, SSLProtocol, and SSLCipherSuite.
• Know why ServerTokens, ServerSignature, and TraceEnable reduce unnecessary exposure.

Recap

• A CSR is signed; the private key stays on the server.
• Self-signed certificates are not publicly trusted by default.
• SNI enables name-based HTTPS virtual hosting.
• TLS configuration needs regular review as protocols and client requirements change.