TLS/SSL Fundamentals¶

Intermediate40 minsecurity tls ssl certificates pki

Learning outcomes

Explain symmetric and asymmetric encryption and how TLS uses both during a handshake
Describe PKI trust chains from root CAs through intermediates to end-entity certificates
Use OpenSSL to inspect certificates, verify chains, and debug TLS connections

Understanding Transport Layer Security (TLS) is critical for any systems administrator. TLS encrypts communication between clients and servers, preventing eavesdropping, tampering, and impersonation. Every HTTPS connection, email relay, database connection, and API call you secure depends on these fundamentals.

SSL (Secure Sockets Layer) is the predecessor to TLS. The protocol was renamed to TLS starting with version 1.0, but "SSL" persists in common usage, tool names (openssl), and certificate product names. In practice, when someone says "SSL certificate," they mean a certificate used with TLS.

Cryptographic Foundations¶

TLS relies on two types of cryptography working together.

Symmetric Encryption¶

Both sides share the same secret key. Fast, efficient, and used for the actual data transfer once a connection is established. Common algorithms include AES-128 and AES-256 (Advanced Encryption Standard with 128-bit or 256-bit keys).

The problem: how do two parties agree on a shared secret over an untrusted network?

Asymmetric Encryption¶

Uses a mathematically linked key pair: a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key, and vice versa. Common algorithms include RSA (2048+ bit keys) and ECDSA (256+ bit keys, faster and smaller).

Asymmetric encryption is slower than symmetric, so TLS uses it only during the handshake to securely exchange a symmetric key. After that, all data flows using the faster symmetric cipher.

Public Key Infrastructure (PKI)¶

PKI is the trust framework that makes TLS work at scale. Without it, you would have to manually verify every server's public key before connecting - impractical for billions of websites.

How Trust Works¶

A Certificate Authority (CA) is an organization trusted by browsers and operating systems to vouch for the identity of certificate holders. When a CA signs a certificate, it's saying "we verified that this entity controls this domain."

Trust flows through a chain:

graph TD
    A[Root CA] -->|signs| B[Intermediate CA]
    B -->|signs| C[End-Entity Certificate]
    C -->|installed on| D[Your Server]

Root CA: The anchor of trust. Root certificates are pre-installed in browsers and operating systems. Root CAs sign intermediate CA certificates but rarely sign end-entity certificates directly - keeping the root key offline and secure.
Intermediate CA: Signed by the root, used to sign end-entity certificates. If an intermediate CA is compromised, the root can revoke it without replacing every certificate it ever issued.
End-Entity Certificate: The certificate installed on your server, containing your public key and domain name.

Why intermediate certificates matter

Your server must send both its end-entity certificate and the intermediate certificate(s) that chain back to the root. If you only send the end-entity certificate, clients cannot build the trust chain and will show a "connection not trusted" error. This is the single most common TLS misconfiguration.

The TLS Handshake¶

Every TLS connection begins with a handshake that authenticates the server, negotiates encryption parameters, and establishes a shared secret. TLS 1.3 simplified this from a two-round-trip process (TLS 1.2) to a single round trip.

TLS 1.3 Handshake¶

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: ClientHello (supported ciphers, key share)
    Server->>Client: ServerHello (chosen cipher, key share, certificate, finished)
    Note over Client,Server: Both sides derive the session key
    Client->>Server: Finished (encrypted)
    Note over Client,Server: Application data flows encrypted

ClientHello: The client sends its supported TLS versions, cipher suites, and a key share (Diffie-Hellman parameters).
ServerHello: The server chooses a cipher suite, sends its own key share, its certificate, and a "finished" message - all in one flight.
Key Derivation: Both sides independently compute the same session key from the exchanged key shares.
Encrypted Communication: All subsequent data is encrypted with the symmetric session key.

TLS 1.2 vs 1.3¶

Feature	TLS 1.2	TLS 1.3
Handshake round trips	2	1
Cipher suites	Many (including weak ones)	5 strong suites only
Forward secrecy	Optional	Mandatory
RSA key exchange	Supported	Removed
0-RTT resumption	No	Yes (with caveats)

Forward secrecy means that even if the server's private key is compromised in the future, past recorded traffic cannot be decrypted. TLS 1.3 enforces this by removing RSA key exchange (where the session key is encrypted with the server's long-term key) and requiring ephemeral Diffie-Hellman key exchange.

Cipher Suites¶

A cipher suite is a combination of algorithms used during a TLS connection. The name encodes each algorithm's role:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│    │     │        │    │   │    │
│    │     │        │    │   │    └─ Hash for PRF
│    │     │        │    │   └────── Mode (authenticated)
│    │     │        │    └────────── Key size
│    │     │        └─────────────── Symmetric cipher
│    │     └──────────────────────── Authentication
│    └────────────────────────────── Key exchange
└─────────────────────────────────── Protocol

TLS 1.3 simplified this naming. Instead of encoding every algorithm, suites are named like TLS_AES_256_GCM_SHA384 because key exchange is always ephemeral Diffie-Hellman and authentication is determined by the certificate type.

Recommended Configuration¶

Use the Mozilla SSL Configuration Generator to generate cipher suite configurations for your server software. The "Intermediate" profile balances security with compatibility:

# TLS 1.2 + 1.3 (Mozilla Intermediate)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

Working with OpenSSL¶

OpenSSL is the industry-standard command-line toolkit for managing certificates and keys.

Generating a Private Key¶

# RSA key (2048-bit minimum, 4096-bit for higher security)
openssl genrsa -out server.key 4096

# ECDSA key (faster, smaller - preferred for new deployments)
openssl ecparam -genkey -name prime256v1 -out server.key

Creating a Certificate Signing Request (CSR)¶

A CSR contains your public key and identity information. You send it to a CA to get a signed certificate.

# Interactive (prompts for country, organization, common name, etc.)
openssl req -new -key server.key -out server.csr

# Non-interactive with Subject Alternative Names (modern standard)
openssl req -new -key server.key -out server.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Always use Subject Alternative Names

The Common Name (CN) field is deprecated for domain validation. Modern browsers require the domain to appear in the Subject Alternative Name (SAN) extension. A certificate with only a CN and no SANs will trigger browser warnings.

Inspecting Certificates¶

# View full certificate details
openssl x509 -in cert.pem -text -noout

# Check expiration date
openssl x509 -in cert.pem -enddate -noout

# Verify a certificate against a CA bundle
openssl verify -CAfile ca-bundle.pem cert.pem

# Check if a certificate matches a private key (modulus hash must match)
openssl x509 -noout -modulus -in cert.pem | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5

Testing a Remote Server¶

# Connect to a server and display its certificate chain
openssl s_client -connect example.com:443 -servername example.com

# Check specific TLS version support
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

# Show only the certificate dates
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Common Certificate Formats¶

Format	Extensions	Encoding	Common Use
PEM	`.pem`, `.crt`, `.key`	Base64 ASCII	Linux, Nginx, Apache
DER	`.der`, `.cer`	Binary	Java, Windows
PKCS#12	`.p12`, `.pfx`	Binary container	Windows, Java keystores

# Convert PEM to DER
openssl x509 -in cert.pem -outform DER -out cert.der

# Convert PEM to PKCS#12 (bundles cert + key into one file)
openssl pkcs12 -export -in cert.pem -inkey server.key -out cert.p12

# Extract from PKCS#12 back to PEM
openssl pkcs12 -in cert.p12 -out cert.pem -nodes

Server Name Indication (SNI)¶

SNI is a TLS extension that allows a client to specify which hostname it's connecting to during the handshake. Without SNI, a server with multiple TLS certificates on one IP address wouldn't know which certificate to present.

SNI is supported by all modern clients. The only environments where it causes issues are very old systems (Android 2.x, IE on Windows XP) and certain IoT devices.

Certificate Transparency¶

Certificate Transparency (CT) is a public logging system that records every certificate issued by participating CAs. It allows domain owners to detect misissued certificates - for example, if a compromised CA issues a certificate for your domain to an attacker.

All major CAs now submit certificates to CT logs as a requirement for browser trust. You can search CT logs for certificates issued for your domain using tools like crt.sh.

Historical Vulnerabilities¶

Understanding past TLS vulnerabilities explains why modern configurations disable older protocols:

Vulnerability	Year	Affected	Impact
BEAST	2011	TLS 1.0 CBC ciphers	Could decrypt HTTPS cookies
CRIME	2012	TLS compression	Could recover secret tokens
Heartbleed	2014	OpenSSL 1.0.1-1.0.1f	Leaked server memory (keys, passwords)
POODLE	2014	SSLv3	Could decrypt SSLv3 traffic
DROWN	2016	SSLv2 (even if only enabled alongside TLS)	Could decrypt TLS sessions

The response to each vulnerability was to disable the affected protocol version or feature. This is why modern configurations use only TLS 1.2 and 1.3 with no compression and no CBC-mode ciphers.