# OpenSSL Certificate Inspection and s_client Cheatsheet

This is a plain-text copy of a cheatsheet published by Ellington Technologies, made for pasting into an AI assistant. It's generated from the same source file as the web page. If the two ever differ, the web page is correct: https://jeremiahellington.com/resources/cheatsheets/openssl-certificate-inspection

- Source (authoritative web version): https://jeremiahellington.com/resources/cheatsheets/openssl-certificate-inspection
- Author: Jeremiah Ellington
- Published: 2026-10-28
- Last updated: 2026-10-29
- Last reviewed: 2026-10-28
- Next scheduled review: 2027-04-30
- Applies to: OpenSSL 3.5 LTS on Linux or macOS. Checked against the OpenSSL 3.5 manual pages (docs.openssl.org/3.5) on 2026-10-27, not run against a live server; other 3.x releases may differ in detail

OpenSSL commands for reading certificates, requests, CRLs and PFX files, checking a chain, matching a key to its certificate, and testing a live TLS server with s_client, organised around four everyday jobs.

---

Every example uses made-up people, names and addresses: `www.example.com`, `mail.example.com`, `dc01.corp.example.com` and the documentation address `192.0.2.10`. Use files from your own test system, never someone else's server or key. Everything here was **checked against the OpenSSL 3.5 manual pages, not lab-tested** (October 27, 2026).

## OpenSSL: four everyday jobs

The next four sections each walk through one common job: renewing a certificate with a new key and request, finding out why a site shows the wrong certificate or an incomplete chain, packing a certificate into a PFX for a Windows server, and checking an LDAPS or mail server's certificate against the CA's CRL. Each one starts with a short situation, finds out what's going on with read-only commands, makes the change (each step labelled), confirms it worked, and lists what to try if it didn't. A quick-reference table closes each section.

> **Important:**
> These four sections were checked against the OpenSSL 3.5 manual pages, not lab-tested. The people and names are made up, and the sample output is illustrative, not captured from a real system. No real certificate, key or serial number appears on this page.

Nearly every command only reads. The steps marked **Writes files** create a private key, a PFX or a certificate file; keep key and PFX files secret.

## Renew a certificate: new key, new request

### The situation: www.example.com expires next month

Ravi Shah runs the website for example.com. The certificate on `www.example.com` expires in four weeks, and the current one is saved as `server.pem`. The new one has to cover `www.example.com` and `example.com`.

### Find out what's going on (read-only)

*Read-only*

```bash
openssl x509 -in server.pem -noout -text                  # everything, in readable form
openssl x509 -in server.pem -noout -subject -issuer
openssl x509 -in server.pem -noout -dates                 # notBefore and notAfter
openssl x509 -in server.pem -noout -ext subjectAltName    # the names the certificate covers
openssl x509 -in server.pem -noout -ext extendedKeyUsage,keyUsage,basicConstraints
openssl x509 -in server.pem -noout -serial
openssl x509 -in server.pem -noout -fingerprint -sha256   # without -sha256, x509 uses SHA-1
openssl x509 -in server.cer -inform DER -noout -text      # a binary (DER) file
openssl x509 -in server.pem -noout -checkend 2592000 && echo "Still valid in 30 days"
```

`-checkend` takes seconds and exits nonzero if the certificate expires within that time, so it works in a monitoring script.

*Sample output (illustrative)*

```text
$ openssl x509 -in server.pem -noout -dates -ext subjectAltName
notBefore=Nov 25 00:00:00 2025 GMT
notAfter=Nov 24 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:www.example.com, DNS:example.com
```

Look for: the `notAfter` date, and every name the site answers to in the Subject Alternative Name.

### Make the change

**Writes files: creates a private key.** Keep the output files out of shared folders, tickets and version control.

*Writes files: private keys*

```bash
# New 2048-bit RSA key and a CSR with a SAN. The key is encrypted; you'll be asked for a passphrase.
openssl req -new -newkey rsa:2048 -keyout www.example.com.key -out www.example.com.csr \
  -subj "/CN=www.example.com" \
  -addext "subjectAltName = DNS:www.example.com,DNS:example.com"
```

> **Tip:**
> `-noenc` (formerly `-nodes`, deprecated since OpenSSL 3.0) writes the key without a passphrase, which a web server often needs. If you use it, the file permissions are the only protection the key has.

### Confirm it worked

Check the request before you send it to the CA, then check the issued certificate matches the key.

*Read-only*

```bash
openssl req -in www.example.com.csr -noout -text -verify   # check the CSR's signature, then show it
```

Read-only, but these commands read the private key. Compare the hashes: if all three match, the key, the certificate and the request belong together.

*Read-only (reads the private key, prints only public parts)*

```bash
openssl x509 -in www.example.com.pem -noout -pubkey | openssl sha256
openssl pkey -in www.example.com.key -pubout | openssl sha256
openssl req -in www.example.com.csr -noout -pubkey | openssl sha256
```

### If it didn't work

- **The hashes don't match.** The certificate was issued for a different request, or you're holding an old key. Find the key that made this CSR, or request again with the key you have.
- **You want to see inside the key.** `openssl pkey -in server.key -text` prints the private key's components. Don't run it where the output could be logged or pasted into a ticket. `-pubout` limits the output to the public half.

### Quick reference: renew a certificate

| Command | What it does | Read-only or changes something |
| --- | --- | --- |
| `openssl x509 -in server.pem -noout -text` | Shows the whole certificate | Read-only |
| `openssl x509 -in server.pem -noout -dates` | Shows notBefore and notAfter | Read-only |
| `openssl x509 -in server.pem -noout -ext subjectAltName` | Shows the names the certificate covers | Read-only |
| `openssl x509 -in server.pem -noout -fingerprint -sha256` | SHA-256 fingerprint (SHA-1 without `-sha256`) | Read-only |
| `openssl x509 -in server.pem -noout -checkend 2592000` | Exits nonzero if it expires within 30 days | Read-only |
| `openssl req -new -newkey rsa:2048 -keyout ... -out ...` | Creates a private key and a CSR | Writes files (private key) |
| `openssl req -in request.csr -noout -text -verify` | Checks the CSR's signature, then shows it | Read-only |
| `openssl pkey -in server.key -pubout \| openssl sha256` | Hashes the key's public half, to match it | Read-only (reads the private key) |

## Find out why a site shows the wrong certificate

### The situation: one server of two is wrong

Ravi's new certificate is live, but some visitors to `www.example.com` still get a certificate warning. The site runs on two servers behind DNS, and one of them is at `192.0.2.10`. Ravi needs to know which server is wrong, and how.

### Find out what's going on (read-only)

Read-only, but it connects over the network. Only test servers you run or are allowed to test.

*Read-only (connects over the network)*

```bash
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null
openssl s_client -connect www.example.com:443 -servername www.example.com -brief </dev/null
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null
openssl s_client -connect 192.0.2.10:443 -servername www.example.com </dev/null   # one server by IP, correct SNI
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates -ext subjectAltName
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_2 </dev/null    # force TLS 1.2
```

*Sample output (illustrative, trimmed)*

```text
$ openssl s_client -connect 192.0.2.10:443 -servername www.example.com -showcerts </dev/null
CONNECTED(00000003)
---
Certificate chain
 0 s:CN=www.example.com
   i:CN=Example Intermediate CA
---
...
Verify return code: 20 (unable to get local issuer certificate)
```

Look for: whether the subject and dates are the new certificate's, and how many certificates the server sends under `Certificate chain`. A server certificate with no intermediate after it usually means the server isn't sending its chain. Check the `Verify return code` line.

**What to know about s_client**

- **SNI.** s_client sends the name from `-connect` as the SNI if it looks like a DNS name. Connect by IP address and it sends no name, so a server hosting several sites may hand back the wrong certificate. Add `-servername` whenever you connect by IP, or just always.
- **`-showcerts` isn't a verified chain.** The manual says it "only consists of certificates the server has sent" and is "**not** a verified chain". It's how you spot a missing intermediate, not proof that the chain is good.
- **Verification failures don't stop the connection** unless you add `-verify_return_error`. Without it, look for the `Verify return code` line in the output.
- **Check the name too.** Add `-verify_hostname` with the name you expect, so a valid certificate for the wrong name doesn't pass.
- **`</dev/null`** closes the connection once the handshake is done. The manual warns that it "may close the connection prematurely, especially with TLS 1.3". That's fine for looking at the certificate. To test the application, run s_client interactively and type `Q` to quit.

### Make the change

The fix is on the web server: install the intermediate alongside the certificate, in the way your web server software expects. If the CA gave you the intermediate as a binary (DER) file, convert it first, then check the chain from files before you install it.

*Writes files: certificates only*

```bash
openssl x509 -in example-intermediate.cer -inform DER -out example-intermediate.pem   # DER to PEM
```

`-CAfile` is the trust anchor (the root). `-untrusted` holds intermediates that help build the chain but aren't trusted on their own.

*Read-only*

```bash
openssl verify -CAfile example-root.pem -untrusted example-intermediate.pem server.pem
openssl verify -CAfile example-root.pem -untrusted example-intermediate.pem \
  -purpose sslserver -verify_hostname www.example.com -show_chain server.pem
```

> **Note:**
> OpenSSL itself ships no trusted roots. Many Linux distributions supply a system store and configure OpenSSL to use it, so `openssl verify server.pem` with no `-CAfile` uses whatever your distribution provides.

### Confirm it worked

*Read-only (connects over the network)*

```bash
openssl s_client -connect 192.0.2.10:443 -servername www.example.com \
  -verify_return_error -verify_hostname www.example.com </dev/null
```

With `-verify_return_error`, a bad chain or a wrong name stops the handshake. Run the same check against the other server by its IP address too.

### If it didn't work

- **The IP address gives a different certificate from the name.** You probably left off `-servername`, so the server picked its default certificate. Add it and run the check again.
- **`-showcerts` now lists the intermediate, but verification still fails.** `-showcerts` only shows what the server sent. Check the chain from files with `openssl verify ... -show_chain` to see which link is missing or out of order.

### Quick reference: s_client and chains

| Command | What it does | Read-only or changes something |
| --- | --- | --- |
| `openssl s_client -connect host:443 -servername host </dev/null` | Connects with SNI and shows the handshake | Read-only (connects over the network) |
| `... -brief` | Shorter summary of the connection | Read-only (connects over the network) |
| `... -showcerts` | Shows every certificate the server sent (not a verified chain) | Read-only (connects over the network) |
| `... -verify_return_error -verify_hostname host` | Fails on a bad chain or a wrong name | Read-only (connects over the network) |
| `... -tls1_2` | Forces TLS 1.2 | Read-only (connects over the network) |
| `s_client ... \| openssl x509 -noout -subject -issuer -dates` | Reads the first certificate from s_client's output | Read-only (connects over the network) |
| `openssl verify -CAfile root.pem -untrusted inter.pem server.pem` | Checks a chain from files | Read-only |
| `openssl x509 -in file.cer -inform DER -out file.pem` | Converts DER to PEM | Writes files (certificate only) |

## Pack a certificate into a PFX for Windows

### The situation: the same certificate on IIS

Example.com is adding a Windows server running IIS behind `www.example.com`. Jo Martin, who looks after it, asks Ravi for the certificate as a PFX. Jo also has an old PFX from a previous project and wants to know what's in it.

### Find out what's going on (read-only)

`pkcs12 -info -noout` checks and describes the file without writing out any key.

*Read-only*

```bash
openssl pkcs12 -in old-server.pfx -info -noout         # structure and algorithms; outputs no keys
openssl x509 -in www.example.com.pem -noout -pubkey | openssl sha256
openssl pkey -in www.example.com.key -pubout | openssl sha256
```

Look for: matching hashes from the last two lines (the key belongs to the certificate), and the algorithms `-info` reports for the old file.

### Make the change

**Writes files: the PFX holds the private key.** Keep it out of shared folders, tickets and version control, and send its password by a different route from the file.

*Writes files: private keys*

```bash
# Bundle key, certificate and chain into a PFX (for Windows or IIS). The PFX holds the private key.
openssl pkcs12 -export -inkey www.example.com.key -in www.example.com.pem \
  -certfile example-chain.pem -out www.example.com.pfx
```

If someone only needs the certificates from a PFX, take them out without the key:

*Writes files: certificates only*

```bash
openssl pkcs12 -in server.pfx -nokeys -out server-certs.pem   # certificates out of a PFX, no key
```

### Confirm it worked

*Read-only*

```bash
openssl pkcs12 -in www.example.com.pfx -info -noout
```

You'll be asked for the PFX password. Then Jo imports it on the Windows server (see [Move a certificate to a new server](https://jeremiahellington.com/resources/cheatsheets/windows-certificate-commands#move-a-certificate-to-a-new-server) on the Windows sheet).

### If it didn't work

- **The old PFX won't open.** In OpenSSL 3.5 the default PFX encryption is AES-256-CBC with PBKDF2. An old PFX that uses older algorithms such as RC2-40 needs `-legacy` to open.
- **A Windows server rejects a PFX password you know is right.** Verify on your system: the OpenSSL manual doesn't say which Windows releases read its AES-256 default, so try the import on the target server before the change window. If it fails, export again with `-legacy` added to the `pkcs12 -export` command; the manual says that in legacy mode "the default algorithm for private key encryption is 3DES_CBC".
- **`-info` lists only one certificate.** The intermediate wasn't in `example-chain.pem`. Rebuild the PFX with the full chain in `-certfile`.

### Quick reference: PFX files

| Command | What it does | Read-only or changes something |
| --- | --- | --- |
| `openssl pkcs12 -in server.pfx -info -noout` | Describes the PFX; outputs no keys | Read-only |
| `openssl pkcs12 -export -inkey key -in cert -certfile chain -out file.pfx` | Bundles key, certificate and chain | Writes files (private key) |
| `openssl pkcs12 -in server.pfx -nokeys -out certs.pem` | Takes the certificates out, no key | Writes files (certificates only) |
| `openssl pkcs12 -in old.pfx -info -noout -legacy` | Opens a PFX that uses older algorithms | Read-only |

## Check an LDAPS or mail certificate against the CRL

### The situation: was dc01's certificate revoked?

The CA team at corp.example.com revoked some certificates after a server was decommissioned. Sam Okafor, who runs the Linux LDAP clients, needs to confirm that the certificate `dc01.corp.example.com` serves for LDAPS isn't on the revocation list, and that the mail server's certificate is fine too.

### Find out what's going on

**Writes files: certificate only.** First, save the certificate the server sends, so the checks below have a file to read. A certificate is public, so this file needs no special protection.

*Writes files: certificate only*

```bash
openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com </dev/null 2>/dev/null |
  openssl x509 -out dc01.pem
```

Everything else in this step only reads.

*Read-only (connects over the network)*

```bash
openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com </dev/null   # LDAPS (3269 for the global catalog)
openssl s_client -connect mail.example.com:25 -starttls smtp -servername mail.example.com </dev/null
openssl s_client -connect www.example.com:443 -servername www.example.com -status </dev/null    # ask for a stapled OCSP response
```

`-starttls` supports `smtp`, `pop3`, `imap`, `ftp`, `xmpp`, `xmpp-server`, `irc`, `postgres`, `mysql`, `lmtp`, `nntp`, `sieve` and `ldap`.

*Read-only*

```bash
openssl x509 -in dc01.pem -noout -serial
openssl x509 -in dc01.pem -noout -ext crlDistributionPoints,authorityInfoAccess
openssl x509 -in dc01.pem -noout -ocsp_uri              # empty if the certificate has no OCSP address
openssl crl -in example-ca.crl -inform DER -noout -issuer -lastupdate -nextupdate
openssl crl -in example-ca.crl -inform DER -noout -text
```

*Sample output (illustrative, invented serial)*

```text
$ openssl x509 -in dc01.pem -noout -serial
serial=0123456789ABCDEF
```

Look for: where the certificate says its CRL lives (download that file as `example-ca.crl`), whether the CRL's `nextUpdate` is still in the future, and whether the certificate's serial appears in the CRL's revoked list.

### Make the change

It depends on what the CRL says.

- **The serial is on the CRL.** The certificate `dc01` serves has been revoked, and the fix is on the server, not on Sam's clients: `dc01` needs a new certificate. On Windows, follow [Renew a server certificate](https://jeremiahellington.com/resources/cheatsheets/windows-certificate-commands#renew-a-server-certificate-before-it-expires), then save the new certificate as `dc01.pem` again, as in the first step.
- **The serial isn't on the CRL.** There's nothing to change on the client. Go on to the check below to confirm the chain and the CRL together.

### Confirm it worked

*Read-only*

```bash
openssl verify -CAfile example-root.pem -untrusted example-intermediate.pem \
  -crl_check -CRLfile example-ca.crl dc01.pem     # also check the CA's CRL
```

An `OK` means the chain is good and the CRL doesn't list the certificate. If the certificate was replaced, `OK` on the newly saved `dc01.pem` confirms the replacement.

### If it didn't work

- **`crl` can't read the file.** A binary (DER) CRL needs `-inform DER`, as above. Leave it off for a PEM file.
- **The check passes on port 636 but a client using the global catalog fails.** The global catalog listens on 3269. Run the same s_client check on that port.

### Quick reference: revocation, LDAPS and mail

| Command | What it does | Read-only or changes something |
| --- | --- | --- |
| `openssl s_client -connect dc01...:636 -servername dc01... </dev/null` | Connects to LDAPS (3269 for the global catalog) | Read-only (connects over the network) |
| `openssl s_client -connect mail...:25 -starttls smtp ... </dev/null` | Upgrades an SMTP connection to TLS and shows the certificate | Read-only (connects over the network) |
| `openssl s_client ... -status </dev/null` | Asks for a stapled OCSP response | Read-only (connects over the network) |
| `openssl x509 -in cert.pem -noout -serial` | Shows the serial number | Read-only |
| `openssl x509 -in cert.pem -noout -ocsp_uri` | Shows the OCSP address (empty if none) | Read-only |
| `openssl crl -in ca.crl -inform DER -noout -text` | Shows a CRL, including revoked serials | Read-only |
| `openssl verify ... -crl_check -CRLfile ca.crl cert.pem` | Checks the chain and the CA's CRL | Read-only |
| `s_client ... \| openssl x509 -out cert.pem` | Saves the certificate a server sends | Writes files (certificate only) |

## Related

- [Windows certificate commands](https://jeremiahellington.com/resources/cheatsheets/windows-certificate-commands): certutil, certreq and the PowerShell `Cert:` drive.
- [Certificates explained](https://jeremiahellington.com/resources/certificates-explained): what the subject, SAN, EKU, chain and CRL fields mean.

---

## Sources and official documentation

- [OpenSSL 3.5 manual: openssl-x509](https://docs.openssl.org/3.5/man1/openssl-x509/)
- [OpenSSL 3.5 manual: openssl-s_client](https://docs.openssl.org/3.5/man1/openssl-s_client/)
- [OpenSSL 3.5 manual: openssl-verify](https://docs.openssl.org/3.5/man1/openssl-verify/)
- [OpenSSL 3.5 manual: openssl-verification-options](https://docs.openssl.org/3.5/man1/openssl-verification-options/)
- [OpenSSL 3.5 manual: openssl-req](https://docs.openssl.org/3.5/man1/openssl-req/)
- [OpenSSL 3.5 manual: openssl-pkey](https://docs.openssl.org/3.5/man1/openssl-pkey/)
- [OpenSSL 3.5 manual: openssl-crl](https://docs.openssl.org/3.5/man1/openssl-crl/)
- [OpenSSL 3.5 manual: openssl-pkcs12](https://docs.openssl.org/3.5/man1/openssl-pkcs12/)
- [OpenSSL 3.5 manual: x509v3_config (extension names)](https://docs.openssl.org/3.5/man5/x509v3_config/)
- [OpenSSL: release strategy (supported versions)](https://openssl-library.org/policies/releasestrat/)
- [Microsoft Learn: Configure certificates for LDAP over SSL in AD DS (ports 636 and 3269)](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/configure-ldap-signing-certificates)
- [RFC 5737: IPv4 Address Blocks Reserved for Documentation](https://www.rfc-editor.org/rfc/rfc5737)

## Review history

- Technical review: Jeremiah Ellington, 2026-10-28
- Editorial review: Jeremiah Ellington, 2026-10-28