OpenSSL Demystified

Ten Minutes of OpenSSL

OpenSSL is a widely used open-source cryptographic toolkit and SSL/TLS implementation.

It provides:

• A cryptographic library used by applications
• A CLI tool called openssl for working with:
  • Certificates
  • Keys
  • TLS connections
  • Hashes
  • SAN^⬧
  • Encryption and decryption
  • CSRs and CAs

If you have ever generated a TLS certificate, built a private CA, debugged a TLS handshake, created a CSR, or inspected an X.509 certificate — you were using OpenSSL directly or indirectly.

This article builds a layered mental model so you can hold the TLS and PKI stack together in memory.

Core mental model — what TLS actually does

TLS performs two separate cryptographic jobs:

Identity proof  = certificates and signatures
Traffic secrecy = symmetric session encryption

Certificates prove identity. Session keys encrypt traffic.

OpenSSL gives you the tools to build, inspect, verify, and debug both layers.

Layer 1 — Keys: root of identity

Everything starts with a key pair:

private key = secret
public key  = shareable

Generate a private key:

openssl genrsa -out server.key.pem 2048

Private keys are used to:

• prove identity
• sign handshakes
• sign CSRs
• sign certificates (if acting as a CA)

If the private key leaks, identity is compromised.

Layer 2 — X.509 certificates

An X.509 certificate binds identity to a public key and a CA signature:

identity + public key + CA signature = certificate

Certificates contain:

• Subject identity fields
• Public key
• Validity window
• Extensions (SAN, key usage, EKU)
• Issuer
• Signature

Inspect a certificate:

openssl x509 -in cert.pem -text -noout

X.509 defines structure, not encoding.

Layer 3 — DN fields vs SAN

Distinguished Name (DN) fields come from directory systems (X.500 / X.509 heritage):

CN = Common Name
O  = Organization
OU = Organizational Unit
C  = Country
ST = State
L  = Locality

These fields are mostly descriptive.

Operational identity lives in SAN (Subject Alternative Name). Example SAN values:

DNS:api.example.com
IP:10.0.0.5
URI:spiffe://prod/payment

Modern TLS hostname validation checks SAN, not CN.

Practical check:

openssl x509 -in cert.pem -noout -ext subjectAltName

Layer 4 — CSR: certificate signing requests

A CSR is a certificate application form (standard: PKCS#10). It contains:

• your public key
• requested identity fields
• requested SAN entries
• your signature proving key ownership

Create a CSR:

openssl req -new -key server.key.pem -out server.csr.pem

Flow:

key -> CSR -> CA signs -> certificate

Layer 5 — Certificate Authorities (CA) and trust chains

A Certificate Authority is simply a key that signs certificates.

Create a lab Root CA:

openssl genrsa -out ca.key.pem 4096

openssl req -x509 -new -key ca.key.pem -out ca.crt.pem -days 3650 -subj "/C=DK/O=Lab PKI/CN=Lab Root CA"

Clients trust CA certificates via a trust store. Verification builds a chain:

leaf (server) -> intermediate(s) -> root (trusted)

Verify a server cert against a CA file:

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

Layer 6 — File formats and containers (PEM, DER, PFX)

X.509 is the data structure. PEM and DER are encodings.

PEM is text (Base64 with headers), for example:

-----BEGIN CERTIFICATE-----
(base64)
-----END CERTIFICATE-----

DER is binary ASN.1 encoding.

PFX (PKCS#12) is an encrypted bundle containing:

• private key
• certificate
• chain (optional)

Convert PEM to PFX:

openssl pkcs12 -export   -inkey server.key.pem   -in server.crt.pem   -certfile ca.crt.pem   -out server.pfx

Inspect a PFX:

openssl pkcs12 -in server.pfx -info -noout

Layer 7 — TLS handshake: how encryption actually starts

Simplified TLS handshake:

1. client hello
2. server sends certificate (and chain)
3. client verifies chain
4. client verifies SAN hostname match
5. key agreement (usually ECDHE)
6. session keys derived
7. encrypted channel begins

Modern TLS typically uses:

• ECDHE for key agreement (forward secrecy)
• AES-GCM or ChaCha20-Poly1305 for traffic encryption (symmetric)

The server private key is used to sign handshake data to prove identity (possession of the private key). Traffic is not encrypted with the server private key.

Layer 8 — How certificates are asserted true

Client validation checks commonly include:

• CA signature chain validation
• Validity window (Not Before / Not After)
• SAN hostname match
• Extended Key Usage (serverAuth / clientAuth)
• Revocation status (CRL / OCSP, where used)
• Policy constraints (in strict environments)

Three proofs to remember:

CA signature  -> issuer authenticity
private key   -> possession proof (live handshake signing)
SAN match     -> name binding to the endpoint you contacted

Layer 9 — TLS debugging with OpenSSL

Most useful diagnostic command:

openssl s_client -connect host:port -servername hostname

It shows:

• certificate chain presented by server
• negotiated TLS version and cipher
• verification results and errors

Force hostname verification (useful for catching SAN mistakes):

openssl s_client -connect host:port -servername hostname   -verify_hostname hostname -verify_return_error

Layer 10 — Service identity: SPIFFE and SPIRE

In zero-trust and service-mesh environments, identities are often expressed as URIs in SAN:

URI:spiffe://domain/workload

• SPIFFE defines the identity format (SPIFFE ID).
• SPIRE automates issuance and rotation of short-lived X.509 certificates containing that URI SAN.

This is still X.509 and TLS; it is just modernized identity and automation on top.

Appendix

Terminology, Abbreviations & Acronyms