OpenSSL Certificate Commands Cheat Sheet for Decoding, Inspecting, and Verifying Certificates

Overview

This page is a working reference for openssl certificate commands. It is written for readers who already touch certificates in real environments and want a clear place to return when they need to inspect or verify something quickly.

OpenSSL is a broad toolkit, but certificate work usually falls into a few repeatable jobs:

• Decode a PEM or DER certificate into readable text
• Inspect subject names, issuer, SANs, dates, fingerprints, and extensions
• Check a live TLS service to see what certificate it presents
• Verify whether a certificate chains to a trusted root
• Troubleshoot hostname mismatch, expired certificates, missing intermediates, and trust-store issues

That is why this article is organized less like a tutorial and more like a durable command reference. You can scan it when you need a quick answer, then come back later when your environment changes.

Before running commands, it helps to keep a few file-format basics in mind:

• PEM is Base64 text with headers like -----BEGIN CERTIFICATE-----
• DER is binary ASN.1 encoding
• X.509 is the certificate standard you are usually inspecting
• CA bundle means one or more trusted root or intermediate certificates used for validation

Many OpenSSL commands look similar, but the difference between -CAfile, -untrusted, and a direct server connection can completely change the result. The command may succeed syntactically while still not telling you what you think it tells you. The sections below focus on those distinctions.

Core concepts

The quickest way to use OpenSSL well is to separate inspection from verification. Inspection answers, “What is inside this certificate?” Verification answers, “Should I trust it for this purpose?” Those are related, but not the same.

Decode a certificate into readable form

Use this when you have a PEM file and want to read the fields:

openssl x509 -in cert.pem -text -noout

Use this for a DER file:

openssl x509 -in cert.der -inform DER -text -noout

This is the standard answer to decode x509 certificate openssl. It prints the subject, issuer, serial number, validity dates, public key details, extensions, SANs, and signature algorithm. In most troubleshooting sessions, this is the first command to run.

Print specific fields only

When full output is too noisy, narrow the view:

openssl x509 -in cert.pem -noout -subject -issuer -dates -serial -fingerprint

This is useful for quick comparison across files, especially when checking whether two certificates are actually different versions of the same endpoint certificate.

Check Subject Alternative Names

Hostname issues are often caused by missing or wrong SAN entries:

openssl x509 -in cert.pem -noout -text | grep -A1 "Subject Alternative Name"

If you are diagnosing browser or client trust failures, SANs matter more than the common name in many modern workflows.

Extract a certificate from a live TLS service

To see what a server presents on port 443:

openssl s_client -connect example.com:443 -servername example.com

The -servername flag is important for SNI-aware hosts. Without it, you may get the default certificate for the IP address rather than the certificate intended for that hostname.

To save the presented certificate:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -outform PEM > server-cert.pem

This is one of the most useful commands for openssl check ssl certificate tasks because it lets you inspect the exact leaf certificate returned by the remote service.

Check certificate expiration

To print the validity window:

openssl x509 -in cert.pem -noout -dates

To get only the end date:

openssl x509 -in cert.pem -noout -enddate

For fast operational checks, many teams script around this output to catch expiring internal certificates before they break services.

Verify a certificate against a CA file

To perform a direct chain validation:

openssl verify -CAfile root-or-bundle.pem cert.pem

This is the baseline form of openssl verify certificate. If the certificate chains correctly to a trusted issuer in the CA file, OpenSSL returns OK.

But there is a common nuance: if the certificate depends on an intermediate CA that is not included in the leaf file, you may need to provide it separately:

openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pem

Use -CAfile for trusted roots or trust anchors. Use -untrusted for intermediate certificates that help build the chain but are not themselves trust anchors.

Inspect the full chain from a server

To see more detail from a live endpoint:

openssl s_client -showcerts -connect example.com:443 -servername example.com

This helps identify missing intermediate certificates, wrong chain order, or a server sending an outdated chain.

Match a certificate to a private key

When you need to confirm a key pair belongs together, compare public-key material rather than file names. One common approach is to compare moduli for RSA keys:

openssl x509 -in cert.pem -noout -modulus | openssl md5

openssl rsa -in private.key -noout -modulus | openssl md5

If the hashes match, the certificate and private key likely belong together. For newer key types, comparing public key output directly is often a better pattern.

Convert between PEM and DER

openssl x509 -in cert.pem -outform DER -out cert.der

openssl x509 -in cert.der -inform DER -outform PEM -out cert.pem

These conversions are routine when moving between appliances, application frameworks, and certificate validation tooling.

Generate a fingerprint for comparison

openssl x509 -in cert.pem -noout -fingerprint -sha256

Fingerprints are useful for inventory work, out-of-band confirmation, or confirming whether a newly deployed certificate is actually the one you expected.

Certificate verification versus hostname verification

This distinction causes many false assumptions. A certificate may chain correctly to a trusted CA and still be wrong for the hostname you are visiting. Chain validation checks issuer trust. Hostname validation checks whether the certificate identifies the domain or service name being used. Treat them as separate checks.

For broader TLS policy context, especially around naming and browser expectations, see TLS Certificate Requirements by Browser: Current Rules for Validity Periods, SANs, and Trust.

Related terms

A cheat sheet is more useful when the surrounding terms are clear. These are the concepts most often confused during certificate debugging.

X.509 certificate

An X.509 certificate binds an identity or subject to a public key and includes metadata such as issuer, validity period, usage constraints, and signature information.

Leaf certificate

This is the end-entity certificate presented by a website, API, mail server, user, or device. It is not normally a trust anchor.

Intermediate certificate

An intermediate CA certificate sits between the root and the leaf. It signs end-entity certificates and is usually sent by the server as part of the chain.

Root CA

The root is the top-level trust anchor in a PKI hierarchy. In normal validation, roots are already trusted by the operating system, browser, application, or custom trust store.

Trust store

A trust store is the set of trusted roots and sometimes additional policy inputs used by a system or application. OpenSSL commands may use a CA file you provide, but your runtime environment may use a different trust store entirely.

PEM bundle

A PEM bundle is one file containing multiple certificates. This is common for root bundles and chain files.

Self-signed certificate

A self-signed certificate is signed by its own private key rather than by an external CA. It can be valid in closed environments if explicitly trusted, but public clients will not usually trust it by default. For a practical comparison, see Self-Signed vs CA-Signed Certificates: When Each Makes Sense and How Validation Differs.

Digital signature verification

Certificate validation and document signature validation are related but not identical. A certificate helps establish trust in a public key. A digital signature uses a key to prove integrity and signer control. If your work crosses into signed PDFs or files, see Digital Signature Verification: How to Check if a Signed PDF or Document Is Valid and Document Tamper Detection: What Digital Signatures Can Prove and What They Cannot.

Hash verification

Hashes confirm file integrity, not issuer identity on their own. They are useful alongside certificate workflows but should not be treated as a full substitute for trust validation. Related reading: Hash Verification Guide: How Checksums Prove File Integrity and When They Are Not Enough.

Practical use cases

The commands above become more useful when tied to real debugging patterns. The cases below reflect the most common day-to-day certificate verification tasks.

1. A site loads, but clients say the certificate is invalid

Start by checking the live endpoint:

openssl s_client -showcerts -connect example.com:443 -servername example.com

Then ask four questions:

1. Is the leaf certificate for the right hostname?
2. Is it expired or not yet valid?
3. Is the server sending the required intermediate certificates?
4. Does the chain build correctly against the trust source your client uses?

If the chain looks wrong, extract the certificates and test them with openssl verify. This often reveals a missing intermediate or a private CA that was never added to the client trust store.

2. You need a fast certificate authenticity check on a file someone sent

Inspect the certificate contents:

openssl x509 -in cert.pem -text -noout

Then verify it against the expected CA or root bundle:

openssl verify -CAfile expected-root.pem -untrusted intermediate.pem cert.pem

This is a basic certificate authenticity check for internal PKI or vendor-delivered certificates. The result is only as meaningful as the trust anchor you choose. If you trust the wrong root, verification can still return OK.

3. You need to confirm whether a renewed certificate was actually deployed

Pull the live certificate and compare the fingerprint or serial number:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -serial -fingerprint -sha256

Compare that output with the certificate you intended to deploy. This is faster than relying on dashboards, caches, or assumptions about a load balancer rollout.

4. A private service works internally but fails from one client type

This usually points to a trust-store mismatch rather than a broken certificate. OpenSSL may validate the chain when you pass a custom -CAfile, but the failing client may rely on a different root set or a stricter policy engine. In other words, command-line success does not automatically equal runtime success.

When designing a broader validation flow for recipients, public verification pages can reduce friction far more effectively than asking users to inspect PEM files manually. See Public Verification Page Best Practices for Certificates, Badges, and Organization Credentials.

5. You are building tooling around certificate verification

OpenSSL works well for ad hoc debugging and scripting, but repeatable production workflows often need structured outputs, API responses, audit logs, and user-friendly verification paths. If your team is moving from command-line checks to a systemized validation process, see Certificate Verification API Checklist: Features, Security Controls, and Response Data to Expect and How to Build a Certificate Verification Workflow for Schools, Employers, and Associations.

6. You need a minimal daily command set

If you only bookmark a few commands, make it these:

openssl x509 -in cert.pem -text -noout
openssl x509 -in cert.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl s_client -showcerts -connect example.com:443 -servername example.com
openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pem
openssl x509 -in cert.der -inform DER -text -noout

That set covers most routine inspection, SSL certificate checker work, and PKI certificate validation tasks.

When to revisit

Return to this cheat sheet when any of the inputs around certificate verification change. OpenSSL syntax is fairly stable, but the environments around it are not. Your troubleshooting approach should be updated when:

• You start managing certificates across multiple reverse proxies, CDNs, or service meshes
• Your organization changes trust stores, internal CAs, or intermediate chain handling
• You begin validating not just TLS certificates, but signed documents or digital credentials
• You need to turn manual command-line checks into a supportable verification workflow
• Client expectations change around SANs, validity periods, or trust rules

A practical way to keep this useful is to maintain your own short internal appendix beside it:

1. List your standard root bundles and where they are stored
2. Record the exact s_client command pattern your team uses for SNI-based services
3. Document whether your applications rely on OpenSSL, Java trust stores, browser stores, or platform-native stores
4. Keep one known-good example chain for testing
5. Note the differences between certificate inspection, chain validation, and hostname validation in your runbooks

If you are expanding beyond classic X.509 files into organization-issued credentials, verification UX matters just as much as cryptographic validity. For that next step, compare machine-readable and human-readable verification models in Verifiable Credentials vs PDF Certificates: What Organizations Gain and What Verifiers Need.

The main takeaway is simple: OpenSSL is excellent for hands-on certificate work, but it gives the best results when you are precise about what you are testing. Decode to inspect. Verify to build trust. Check the hostname separately. And when a result looks confusing, assume the missing detail is usually the chain, the trust store, or the exact identity you intended to validate.