The essentials
Quick reference
One focused task per row. Jump to the related section for complete, working examples.
| Use | Syntax | Examples |
|---|---|---|
| Show OpenSSL build details | openssl version -a | View examples |
| Summarize a PEM certificate | openssl x509 -in server.crt -noout -subject -issuer \
-serial -dates | View examples |
| Inspect critical extensions | openssl x509 -in server.crt -noout -ext \
subjectAltName,keyUsage,extendedKeyUsage,basicConstraints | View examples |
| Compute a SHA-256 fingerprint | openssl x509 -in server.crt -noout -fingerprint -sha256 | View examples |
| Test the renewal window | openssl x509 -in server.crt -noout -checkend 2592000 | View examples |
| Check a DNS identity | openssl x509 -in server.crt -noout -checkhost \
www.example.com | View examples |
| Verify a server chain | openssl verify -purpose sslserver -CAfile roots.pem \
-untrusted intermediates.pem server.crt | View examples |
| Verify chain and hostname | openssl verify -purpose sslserver -verify_hostname \
www.example.com -CAfile roots.pem -untrusted \
intermediates.pem server.crt | View examples |
| Verify a live TLS endpoint | openssl s_client -connect www.example.com:443 \
-servername www.example.com -verify_hostname \
www.example.com -verify_return_error </dev/null | View examples |
| Show certificates sent by a server | openssl s_client -connect www.example.com:443 \
-servername www.example.com -showcerts </dev/null | View examples |
| Require TLS 1.3 | openssl s_client -connect www.example.com:443 \
-servername www.example.com -tls1_3 -brief </dev/null | View examples |
| Inspect SMTP STARTTLS | openssl s_client -starttls smtp -connect \
mail.example.com:25 -servername mail.example.com \
-verify_hostname mail.example.com </dev/null | View examples |
| Request stapled OCSP | openssl s_client -connect www.example.com:443 \
-servername www.example.com -status </dev/null | View examples |
| Inspect and verify a CSR | openssl req -in request.csr -noout -text -verify | View examples |
| Check a private key | openssl pkey -in server.key -check -noout | View examples |
| Extract a public key | openssl pkey -in server.key -pubout -out \
server-public.pem | View examples |
| Inspect PKCS#12 metadata | openssl pkcs12 -in identity.p12 -info -noout | View examples |
| Extract certificates only | openssl pkcs12 -in identity.p12 -nokeys -out \
certificates.pem | View examples |
| Convert DER certificate to PEM | openssl x509 -inform DER -in server.der -outform PEM \
-out server.pem | View examples |
| Extract certificate public key | openssl x509 -in server.crt -pubkey -noout -out \
certificate-public.pem | View examples |
OpenSSL can answer precise questions about X.509 files and TLS handshakes, but display, hostname checking, chain building, and live endpoint testing are different operations. Keep private keys and passphrases out of command lines and captured output, preserve file permissions, and use explicit trust and hostname inputs when verification matters. OpenSSL 3 provider behavior and option availability differ from older distribution builds, so check the installed version before copying a production procedure.
Step by step
Detailed examples
Confirm the OpenSSL generation and input encoding
OpenSSL 3 uses providers, deprecates some engine-era options, and may reject legacy algorithms that older releases accepted. Distribution builds also backport fixes and choose different trust directories. Record openssl version -a before troubleshooting. PEM is base64 text with BEGIN and END labels; DER is binary ASN.1. The conversion command changes encoding only, not the certificate identity, signature, extensions, or trust. Never guess that an arbitrary PEM file is a certificate: PEM can also hold private keys, CSRs, and other sensitive objects.
openssl version -a
openssl x509 -inform DER -in server.der -outform PEM -out server.pem OpenSSL 3.6.0 1 October 2025
built on: Tue Aug 12 00:00:00 2026 UTC
OPENSSLDIR: "/etc/ssl"Inspect identity, validity, purpose, and fingerprint
A certificate summary should cover subject, issuer, serial, validity, Subject Alternative Name, key usage, extended key usage, and basic constraints. Modern TLS clients validate DNS identities primarily against Subject Alternative Name, not a display-friendly common name. A SHA-256 fingerprint identifies the exact certificate bytes and is useful only when compared through an authenticated independent channel. Certificate text and serial numbers are normally public, but internal names and organizational metadata can still be operationally sensitive; sanitize diagnostic output before sharing it.
openssl x509 -in server.crt -noout -subject -issuer -serial -dates
openssl x509 -in server.crt -noout -ext subjectAltName,keyUsage,extendedKeyUsage,basicConstraints
openssl x509 -in server.crt -noout -fingerprint -sha256 subject=CN=www.example.com
issuer=CN=Example Issuing CA
serial=01A4C2
notBefore=Aug 1 00:00:00 2026 GMT
notAfter=Oct 30 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com
sha256 Fingerprint=8A:51:42:70:9C:12:74:6BTurn renewal and hostname checks into exit statuses
x509 -checkend accepts a number of seconds and exits nonzero when the certificate will expire within that interval, making it more robust than parsing localized date text. x509 -checkhost checks the certificate's identity rules for one hostname, including applicable wildcards, but it does not establish issuer trust, revocation state, current validity, or possession of the private key. Use both tests as focused gates and perform chain verification separately. Time checks depend on the local clock, so investigate clock synchronization when validity results are surprising.
openssl x509 -in server.crt -noout -checkend 2592000
openssl x509 -in server.crt -noout -checkhost www.example.com Certificate will not expire
Hostname www.example.com does match certificateBuild a chain from explicit trust and intermediate inputs
openssl verify treats -CAfile certificates as trust anchors and -untrusted certificates as candidates for building the path; do not put an intermediate in the trust-anchor file merely to make a test pass. -purpose sslserver applies server-authentication constraints, while -verify_hostname adds DNS identity verification. Order all options before the target certificate because later positional arguments are interpreted as more certificates. A successful offline verification says nothing about which chain a live server sends, and default trust paths vary by distribution and container image, so use explicit files for reproducible diagnostics.
openssl verify -purpose sslserver -CAfile roots.pem -untrusted intermediates.pem server.crt
openssl verify -purpose sslserver -verify_hostname www.example.com -CAfile roots.pem -untrusted intermediates.pem server.crt server.crt: OK
server.crt: OKVerify the live handshake, not just the displayed leaf
s_client is a diagnostic client and opens a real network connection. Supply -servername for SNI and -verify_hostname for identity verification; these solve different problems. -verify_return_error is important because s_client otherwise commonly reports verification errors while continuing the session. Redirecting standard input from /dev/null makes the check noninteractive on widely deployed releases. -showcerts prints certificates exactly as sent by the peer, which may omit a needed intermediate or include an unnecessary root, but does not prove the displayed list validates. Protocol pinning is diagnostic only and can fail because of the local build, server policy, load balancer, or interception device.
openssl s_client -connect www.example.com:443 -servername www.example.com -verify_hostname www.example.com -verify_return_error </dev/null
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_3 -brief </dev/null Verification: OK
Verified peername: www.example.com
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Verification: OKUse the application upgrade protocol and interpret revocation cautiously
Protocols such as SMTP begin in plaintext and upgrade with STARTTLS, so connecting as generic TLS to port 25 tests the wrong exchange. Use the matching -starttls mode and still provide SNI and a verification hostname. The -status option asks a TLS server for a stapled OCSP response; a missing staple may be permitted unless the certificate or client policy requires one. A displayed OCSP response also needs signature, freshness, issuer, and status interpretation. Active OCSP or CRL fetching introduces privacy, availability, and outbound-network dependencies and should follow organizational policy rather than being improvised during an incident.
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com </dev/null
openssl s_client -connect www.example.com:443 -servername www.example.com -status </dev/null Verification: OK
Verified peername: mail.example.com
OCSP response:
======================================
OCSP Response Status: successfulInspect requests and keys without exposing private material
A CSR contains a public key and requested subject or extensions; req -verify checks its self-signature but does not approve the request or prove control of a DNS name. pkey -check validates a private key's internal consistency. Both operations can read secrets, and an unencrypted key is immediately usable by anyone who can read it. Run them in a private directory, restrict permissions, avoid shell tracing and shared terminals, and never paste key contents or passphrases into tickets. Let OpenSSL prompt for encrypted-key passphrases or use an approved protected input mechanism; command-line password arguments can leak through history and process inspection. Comparing exported public keys avoids exposing the private key itself.
openssl req -in request.csr -noout -text -verify
openssl pkey -in server.key -check -noout
openssl pkey -in server.key -pubout -out server-public.pem
openssl x509 -in server.crt -pubkey -noout -out certificate-public.pem Certificate request self-signature verify OK
Key is validHandle PKCS#12 bundles as secret containers
A PKCS#12 file can contain a private key, the matching certificate, intermediate certificates, friendly names, and integrity metadata. Treat the entire bundle as a secret even when a command requests metadata only. -info -noout verifies the MAC by default and reports algorithms without extracting contents. -nokeys extracts certificates only. Avoid -noenc and the deprecated -nodes option for routine workflows because they write an unencrypted private key; if an exceptional migration requires that, use a locked-down temporary directory, restrictive umask, secure deletion policy, and immediate re-encryption. OpenSSL 3 may require -legacy to read old RC2-based bundles, which is a compatibility signal to migrate the bundle rather than a preferred creation setting.
openssl pkcs12 -in identity.p12 -info -noout
openssl pkcs12 -in identity.p12 -nokeys -out certificates.pem MAC: sha256, Iteration 2048
MAC length: 32, salt length: 8
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBCSources and further reading
References
Authoritative documentation used to verify and expand this cheat sheet.
- OpenSSL Projectopenssl-s_client — TLS Client Programdocs.openssl.org
- OpenSSL Projectopenssl-x509 — Certificate Display and Signingdocs.openssl.org
- OpenSSL Projectopenssl-verify — Certificate Verificationdocs.openssl.org
- OpenSSL Projectopenssl-req — Certificate Request Utilitydocs.openssl.org
- OpenSSL Projectopenssl-pkey — Public and Private Key Processingdocs.openssl.org
- OpenSSL Projectopenssl-pkcs12 — PKCS#12 File Utilitydocs.openssl.org
- OpenSSL ProjectOpenSSL Verification Optionsdocs.openssl.org
Help us improve
Found a typo or missing example?
Tell us what would make this cheat sheet clearer, more complete, or more useful.



