OpenSSL Command Cheat Sheet: Keys, Certificates, TLS & PKCS#12

openssl is not one fixed operation — it is a front door to dozens of cryptography subcommands. On Linux servers you reach for it whenever TLS identity, file crypto, or certificate debugging is involved.

Common subcommands admins name in interviews:

Check what your build supports:

openssl version
openssl help

Sample output (trimmed):

OpenSSL 3.4.1 11 Feb 2025 (Library: OpenSSL 3.4.1 11 Feb 2025)
Standard commands
genrsa            genpkey           req               x509
verify            pkcs12            s_client          enc
dgst              rand              version           ...

OpenSSL also ships libraries (libssl, libcrypto) that nginx, OpenSSH, Python, and many other programs link against — but the CLI is what operators use to create and troubleshoot certificate material before it lands in a web server or keystore.

A strong answer is:

OpenSSL is the standard CLI toolkit for TLS operations — I use genpkey/req for keys and CSRs, x509 and verify for inspection and chain checks, pkcs12 for Windows/Java bundles, and s_client to see what a live HTTPS server actually presents.

Think of the flow in three pieces:

1. Private key — stays on your server; never sent to the CA.
2. CSR — a signed request that contains your public key plus the names you want (CN, SAN). You upload this to a CA or internal signer.
3. Certificate — the CA's signed reply. Clients trust it during TLS because they already trust the CA's root (or intermediate chain).

Create a CSR:

openssl req -new -key server.key -out server.csr \
  -subj "/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com"

Inspect it — note it says "Certificate Request", not "Certificate":

openssl req -in server.csr -noout -subject -text | head -8

Sample output:

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption

After a CA signs it, you get a certificate file. Decode with openssl x509, not openssl req:

openssl x509 -in server.crt -noout -subject -dates

For lab work you can skip an external CA:

• openssl req -x509 ... — self-signed cert in one step
• openssl x509 -req -signkey server.key ... — sign your own CSR locally

A strong answer is:

The CSR carries my public key and requested hostnames to the CA; the certificate is the CA's signed result. The private key never leaves my host — only the CSR goes out, and clients validate the signed certificate in TLS.

These solve different problems. Mixing them up is a common interview trap.

Chain verification — success looks like:

openssl verify -CAfile root.crt -untrusted intermediate.crt leaf.crt

leaf.crt: OK

A typical failure when the intermediate is missing:

error 20 at 0 depth lookup: unable to get local issuer certificate
error leaf.crt: verification failed

Key pairing — matching RSA modulus hashes:

openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa  -noout -modulus -in key.pem  | openssl md5

MD5(stdin)= 124dea7270e82a189385da8328c0b8ad
MD5(stdin)= 124dea7270e82a189385da8328c0b8ad

openssl verify does not perform that second check. nginx can fail with key values mismatch even when verify would return OK — always compare modulus or public-key hashes before reload.

For EC or Ed25519, modulus comparison fails with Modulus=No modulus for this public key type; use openssl x509 -pubkey -noout piped to openssl md5 against openssl pkey -pubout on the key instead.

A strong answer is:

verify proves chain of trust to a root CA; modulus or pubkey hashing proves the certificate and private key are a cryptographic pair. I run both before deploying — verify for PKI trust, hash match so nginx won't reject the key path.

For years, clients matched the hostname against the certificate Common Name (CN) only. RFC 2818 and later TLS practice moved that check to Subject Alternative Name (SAN) — a list of DNS names, IP addresses, and sometimes emails the cert is valid for.

A cert can have CN=www.example.com in the subject yet fail hostname verification if SAN does not list that name. Public CAs now put every live name in SAN; CN alone is not enough for modern stacks.

Generate with SAN on OpenSSL 1.1.1+:

openssl req -x509 -newkey rsa:2048 -noenc -keyout key.pem -out cert.pem -days 365 \
  -subj "/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com,IP:192.168.1.10"

Confirm the extension is present:

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

Sample output:

X509v3 Subject Alternative Name: 
    DNS:www.example.com, DNS:example.com, IP Address:192.168.1.10

openssl x509 -noout -checkhost www.example.com is a quick local test — exit message does match certificate means CN or SAN covers that host.

Wildcard certs use SAN too (DNS:*.example.com). Every name the browser or API client will use must appear in SAN (or match a wildcard pattern that covers it).

A strong answer is:

Hostname verification uses SAN, not CN alone — since RFC 2818 clients ignore CN for HTTPS matching. I always add subjectAltName for every DNS name and IP the service presents, including www and apex, or the chain can be valid and the browser still errors.

PKCS#12 (also called PFX on Windows) packs private key, leaf certificate, and optional intermediate chain into one password-protected file. Formats like PEM keep key and cert as separate text files — fine for nginx, awkward for IIS, Java keystores, or Azure App Service imports.

Typical workflow on Linux before hand-off:

openssl pkcs12 -export -in cert.pem -inkey key.pem -out bundle.p12 \
  -passout pass:ExportPassword -name myserver

Inspect without extracting:

openssl pkcs12 -in bundle.p12 -passin pass:ExportPassword -info -noout

Sample output:

MAC: sha256, Iteration 2048
Certificate bag
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048

On the Linux side you often split a PFX back to PEM for nginx:

openssl pkcs12 -in bundle.p12 -passin pass:ExportPassword -nocerts -nodes -out key.pem
openssl pkcs12 -in bundle.p12 -passin pass:ExportPassword -clcerts -nokeys -out cert.pem

OpenSSL 3.x defaults to strong PKCS#12 encryption; older Windows Server versions may need -legacy or explicit TripleDES flags on export — see Create PFX from CRT and KEY.

A strong answer is:

PKCS#12 is the password-protected bundle Windows and Java expect — cert, key, and chain in one file. I export with openssl pkcs12 -export for IIS or keytool, and extract back to PEM on Linux when nginx needs separate .crt and .key paths.

Both answer: has this certificate been revoked before its expiry date? They differ in how clients learn that.

OpenSSL can check a CRL when you have the files:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl server.crt

OCSP from the CLI needs a live responder URL (example only — your CA publishes the real endpoint):

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

In production, browsers and TLS libraries handle revocation automatically; operators revoke through the CA portal or an internal openssl ca -revoke workflow, then publish an updated CRL or rely on OCSP stapling on the web server.

A strong answer is:

CRL is a downloaded revocation list; OCSP is a per-certificate live status query. Both invalidate certs before notAfter — CRL batches serials, OCSP answers good or revoked for one cert at handshake time.