SSL/HTTPS

Understanding SSL/TLS and HTTPS

Secure web servers rely on TLS (often still called SSL) to encrypt HTTP traffic, provide integrity, and optionally authenticate clients. In practice:

• HTTPS = HTTP over TLS
• TLS adds:
• Confidentiality (encryption)
• Integrity (protection against tampering)
• Authentication (typically server identity)

Modern deployments use TLS (SSL is obsolete), but tools, configs, and docs still say “SSL” in many places.

TLS Handshake (High-Level)

When a client connects to an HTTPS site:

1. ClientHello
   Client proposes:
• TLS versions it supports
• Cipher suites
• Extensions (e.g., SNI for virtual hosts)
2. ServerHello + Certificate
   Server chooses:
• TLS version
• Cipher suite
  And sends:
• Its certificate chain
• Optional additional parameters (e.g., key share for TLS 1.3)
3. Key Exchange
   Client and server:
• Agree on a shared secret (e.g., via ECDHE)
• Derive symmetric keys for encryption and MAC
4. Finished Messages
   Both sides:
• Switch to encrypted communication
• Verify handshake integrity

From this point, application data (HTTP) is encrypted.

Certificates and Certificate Authorities

Certificate Structure (Server-Side View)

A typical server certificate contains:

• Subject (the identity):
• CN (Common Name, often legacy)
• Subject Alternative Name (SAN) with one or more DNS names
• Issuer (the CA that signed it)
• Public key
• Validity period (NotBefore, NotAfter)
• Extensions (key usage, extended key usage, etc.)
• Digital signature (created with issuer’s private key)

For an HTTPS site, browsers expect:

• Extended Key Usage includes serverAuth
• Hostname in SAN matches the URL being accessed
• Certificate not expired
• Signature chain leads to a trusted root CA

Chain of Trust

On Linux web servers you usually deploy:

• Server certificate (for your domain)
• Intermediate CA certificate(s)
• Not the root CA (clients already have it)

The client validates:

1. Server cert ← signed by intermediate CA
2. Intermediate CA ← signed by root CA
3. Root CA is trusted by system/browser

If the chain is incomplete, clients may show “insecure” or “untrusted” warnings.

Types of Certificates (from an Admin Perspective)

• Single-domain
  One FQDN, e.g. www.example.com.
• Wildcard
  *.example.com covers www.example.com, api.example.com, etc.
  Does not cover example.com itself (no leading label).
• Multi-domain (SAN)
  Multiple specific names in SAN, e.g. www.example.com, api.example.com, example.org.
• Validation level (affects issuance, not cryptographic strength):
• DV (Domain Validation) – validates domain control (typical for Let’s Encrypt).
• OV/EV (Org / Extended Validation) – includes organization identity; requires more vetting.

From a Linux server configuration standpoint, DV is sufficient for encryption and browser padlock.

Getting and Managing Certificates

ACME and Let’s Encrypt

Let’s Encrypt + ACME is the dominant free, automated TLS solution.

Key ideas:

• ACME client on your server (e.g., certbot, acme.sh, lego) requests certs from the CA.
• You prove domain control using challenges:
• HTTP-01: Serve a token over HTTP at http://example.com/.well-known/acme-challenge/...
• DNS-01: Place a token in a specific DNS TXT record
• TLS-ALPN-01: Present a token in a special TLS handshake on port 443

The ACME client:

1. Generates a private key and CSR
2. Completes challenge(s)
3. Receives certificate + intermediate(s)
4. Installs them and (often) reloads/restarts the web server
5. Renews certificates automatically before expiration (typically every 60–80 days for 90-day certs)

As an admin, you must ensure:

• Port 80/443 or correct DNS access is available for challenges.
• The web server is configured to use the updated certificate paths.
• Renewal hooks/reloads are functioning.

Self-Signed Certificates

Self-signed certs are useful for:

• Internal testing
• Lab/homelab environments
• Encrypted connections where you control all clients

Limitations:

• Not trusted by default; clients will warn.
• You must explicitly import/trust the self-signed CA or cert on clients.

On Linux, you can generate one with openssl (basic idea, not full command set):

• Create a private key
• Create a certificate with -x509 (self-signed)
• Install on server and distribute trust to clients as needed

Use self-signed CA + server certs signed by that CA if you have multiple internal services.

Certificate Lifecycle

As a server admin, track:

• Expiration: monitor cert expiry dates; use tools or cron to check.
• Renewal: via ACME automation or manual re-issuance.
• Revocation:
• CRL (Certificate Revocation List)
• OCSP (Online Certificate Status Protocol)
  Browsers mainly rely on OCSP/CRL from CAs, not from your server, except for OCSP stapling.

Key management practices:

• Keep private keys readable only by privileged users (e.g., root + web server group).
• Use strong key sizes:
• RSA: at least 2048 bits
• ECDSA: modern curves (e.g., prime256v1, secp384r1)

TLS Configuration on Linux Web Servers

Core Concepts

Across Apache and Nginx, the basic pieces are similar:

• Key file: server private key, e.g. example.com.key
• Certificate file: server certificate, e.g. example.com.crt
• Chain file: intermediate CA(s), e.g. chain.crt
• Combined file: sometimes cert + chain together

You bind these to a virtual host or server block listening on port 443.

Always:

• Enable only modern protocol versions (TLS 1.2 and 1.3, disable SSL 2/3 and TLS 1.0/1.1).
• Restrict to secure cipher suites.
• Test configuration with openssl s_client and online scanners (e.g., SSL Labs).

Protocol Versions

Modern baseline:

• Enable: TLS 1.2, TLS 1.3
• Disable: SSLv2, SSLv3, TLS 1.0, TLS 1.1

In config formats you will see things like:

• TLSv1.2 TLSv1.3 (allowed)
• !SSLv2 !SSLv3 !TLSv1 !TLSv1.1 (explicitly disabled)

Older clients (e.g., legacy OSes/browsers) may break when you drop TLS 1.0/1.1; you must weigh security vs compatibility.

Cipher Suites

A cipher suite defines:

• Key exchange algorithm (e.g., ECDHE)
• Authentication algorithm (e.g., RSA/ECDSA)
• Symmetric cipher (e.g., AES-GCM, CHACHA20-POLY1305)
• MAC / AEAD mode

As an admin, typical goals:

• Prefer forward secrecy: use ECDHE or DHE.
• Prefer AEAD ciphers: AES-GCM, CHACHA20-POLY1305.
• Avoid:
• NULL ciphers
• EXPORT ciphers
• RC4, 3DES, CBC where possible
• Obsolete key exchange (RSA-only key exchange) in new setups

Instead of handcrafting suites, many admins use recommended sets from:

• Mozilla SSL Configuration Generator
• Distribution-provided defaults (modern profiles)

Hardening HTTPS

HTTP to HTTPS Redirection

Prefer all traffic over HTTPS. Implement:

• Redirect from http:// to https://:
• 301 (permanent) or 302/307 (temporary) based on your migration status.

Consider:

• Avoid infinite redirect loops (e.g., misconfigured reverse proxies).
• Make sure ACME HTTP-01 challenges still work (often exempted from redirect or handled correctly).

HSTS (HTTP Strict Transport Security)

HSTS instructs browsers to:

• Always use HTTPS for a given domain for a period of time.
• Optional: also include subdomains.

Typical header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Notes:

• Once used with a long max-age, rolling back to HTTP is hard; test with low values first.
• preload submits your domain to browser-maintained preload lists (must meet certain requirements).

OCSP Stapling

OCSP stapling lets the server provide an OCSP response from the CA during the TLS handshake:

• Reduces latency (client doesn’t need to contact CA directly).
• Improves privacy (CA doesn’t see which client IPs are visiting).
• Not required, but good practice.

You typically enable it in the web server configuration and ensure the server can reach the CA’s OCSP responder.

Perfect Forward Secrecy

Forward secrecy ensures that compromising the server’s long-term private key does not allow decryption of past sessions.

Achieved by:

• Using ephemeral key exchange (e.g., ECDHE).
• Ensuring cipher suites with ECDHE (or at least DHE) are preferred/required.

Most modern server configurations already favor ECDHE-based suites.

Performance and Optimization

Session Resumption

TLS handshakes are expensive. Two mechanisms help:

• Session IDs / session cache: server stores session state, client gets an ID.
• Session tickets: server encrypts session state and sends to client (client sends it back later).

Benefits:

• Fewer full handshakes.
• Reduced CPU overhead.

Cautions:

• Session tickets require secure ticket keys; rotate them periodically.

TLS 1.3 Advantages

TLS 1.3:

• Simplifies cipher suite negotiation.
• Reduces handshake round-trips (0-RTT and 1-RTT handshakes).
• Removes many legacy/weak options.

From an admin perspective, enabling TLS 1.3:

• Often improves performance.
• May require updated libraries (OpenSSL ≥ 1.1.1 or equivalent).

Hardware and Offloading

On high-traffic servers:

• Ensure server has sufficient CPU for crypto.
• Consider:
• Enabling hardware acceleration (AES-NI, etc.)
• Terminating TLS on a load balancer or reverse proxy
• Using CDN services that handle TLS at the edge

Operational Practices

Testing and Verification

Tools to validate HTTPS setup from a Linux server:

• openssl s_client -connect example.com:443
  Useful for viewing:
• Presented certificates and chain
• Protocol and cipher used
• OCSP stapling status
• curl -v https://example.com
  Shows TLS negotiation details and HTTP headers.

External tools:

• SSL Labs server test
• Hardenize, Censys, etc.

Verify:

• Correct certificate chain
• Hostname matches
• Only intended protocols/ciphers active
• HSTS, OCSP stapling, etc. if configured

Logging and Troubleshooting

In case of TLS problems:

• Check web server error logs for:
• Handshake failures
• Unsupported protocol errors
• Certificate file/permission issues
• Confirm certificate and key file paths are correct and readable by the web server user.
• Look for client-side errors (browser console / error pages).

For mixed content problems:

• Use browser developer tools (Network and Console tabs) to locate HTTP resources on HTTPS pages.

Mixed Content

When migrating to HTTPS:

• Mixed content occurs when an HTTPS page loads assets (scripts, images, CSS) over HTTP.
• Browsers may:
• Block active mixed content (JS, XHR, etc.)
• Warn or block passive mixed content (images, video)

Prevention:

• Update application URLs to https:// or use protocol-relative / scheme-agnostic paths where appropriate.
• Serve all assets over HTTPS.

Summary Checkpoints for an Admin

When configuring SSL/HTTPS on a Linux web server, ensure:

• Valid certificate for your hostname, with correct chain.
• Private key is secure and only readable by privileged users.
• TLS 1.2 and 1.3 enabled, legacy protocols disabled.
• Cipher suites provide forward secrecy and avoid obsolete algorithms.
• HTTP redirects to HTTPS correctly.
• Optional but recommended:
• HSTS (after careful testing)
• OCSP stapling
• Session resumption
• Automated certificate renewal in place (e.g., ACME/Let’s Encrypt) and validated.