How to Check a Certificate With OpenSSL

If you manage a website or server, checking your SSL/TLS certificate regularly is one of those tasks you can’t afford to skip. An expired or misconfigured certificate means browser warnings, broken trust, and potential downtime.

OpenSSL — the open-source command-line toolkit used on virtually every Linux distribution, macOS system, and available on Windows — gives you direct, unfiltered access to certificate details. No browser needed. No third-party tools. Just a terminal and a few short commands.

This guide covers the OpenSSL commands you’ll use most often: viewing certificate details, checking expiration dates, inspecting remote servers, validating certificate chains, and confirming that your private key matches your certificate. Each command is copy-paste ready with a clear breakdown of what it does.

---

Table of Contents

1. Prerequisites: Check Your OpenSSL Version
2. View Full Certificate Details With openssl x509
3. Check a Remote Server’s Certificate With openssl s_client
4. Verify Certificate Expiration Dates
5. Validate the Certificate Chain With openssl verify
6. Confirm Your Private Key Matches Your Certificate
7. Convert Between Certificate Formats
8. Troubleshooting Common Certificate Errors
9. Keep Your Certificates Under Control

---

---

Prerequisites: Check Your OpenSSL Version

Before running any commands, confirm that OpenSSL is installed and check which version you’re running. Your version determines which protocols and algorithms are available.

openssl version –a

This outputs the version number, release date, and the default certificate directory (OPENSSLDIR). Most Linux systems come with OpenSSL pre-installed. On macOS, it ships with LibreSSL (an OpenSSL fork), which handles the same commands.

If you’re on Windows, you can access OpenSSL through WSL (Windows Subsystem for Linux), Git Bash, or a standalone Windows build.

Tip: Make sure you’re running at least OpenSSL 1.1.1 or later. Older versions lack support for TLS 1.2 and TLS 1.3, which are required by modern servers and browsers.

---

View Full Certificate Details With openssl x509

The openssl x509 command is the workhorse for certificate inspection. It reads X.509 certificates, the standard format used by all SSL/TLS certificates, and outputs the details in a human-readable form.

To view the full details of a locally stored certificate file:

openssl x509 -in certificate.crt -text -noout

Here’s what each flag does:

• -in certificate.crt — Specifies the input certificate file. Replace with your actual filename (e.g., yourdomain.crt or server.pem).
• -text — Outputs the certificate in readable text format instead of raw encoded data.
• -noout — Prevents OpenSSL from printing the Base64-encoded PEM block alongside the text output.

This command reveals everything about the certificate:

• Extensions — Including Subject Alternative Names (SANs), Key Usage, and Authority Information Access.
• Issuer — The Certificate Authority (CA) that signed it (e.g., DigiCert, Let’s Encrypt, Sectigo).
• Subject — The domain or organization the certificate was issued to.
• Validity period — The “Not Before” and “Not After” dates showing when the certificate is active.
• Public key algorithm and size — Typically RSA 2048-bit or ECDSA P-256.
• Signature algorithm — Usually sha256WithRSAEncryption for modern certificates.

Check Only the Issuer or Subject

If you don’t need the full output, you can pull specific fields:

openssl x509 -in certificate.crt -noout -issuer
openssl x509 -in certificate.crt -noout -subject

These one-liners are especially useful when you’re scripting or just need a quick confirmation.

Note: OpenSSL expects PEM format by default — these are text files that start with —–BEGIN CERTIFICATE—–. If your certificate is in DER format (binary), add the -inform der flag:

openssl x509 -in certificate.der -inform der -text -noout

---

Check a Remote Server’s Certificate With openssl s_client

You don’t always have the certificate file sitting on your local machine. Often, you need to inspect the certificate installed on a live server. That’s where openssl s_client comes in.

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

This command opens a TLS connection to the server on port 443 (the default HTTPS port) and displays the certificate chain, protocol version, cipher suite, and session details.

The -servername flag enables Server Name Indication (SNI), which is essential when the server hosts multiple domains on the same IP address. Without it, you might receive the wrong certificate.

Press CTRL+C to close the connection after viewing the output.

Pipe It for Cleaner Output

The raw s_client output is verbose. To extract just the certificate details, pipe it into openssl x509:

echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -text

The echo | at the beginning sends an empty input so the connection closes automatically. The 2>/dev/null suppresses error messages, giving you clean output.

You can also narrow it down to specific fields:

echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

This one-liner is a practical favorite for sysadmins. It shows the issuer, subject, and validity dates in a single pass.

Save the Certificate Locally

If you want to save the remote certificate to a file for further analysis:

echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 > yourdomain.pem

Now you can run any openssl x509 command against the saved file.

---

Verify Certificate Expiration Dates

Expired certificates are one of the most common causes of SSL errors. OpenSSL gives you several ways to check expiration.

Quick Date Check

openssl x509 -in certificate.crt -noout -dates

This outputs both the “Not Before” (start date) and “Not After” (end date). If you only need the expiration:

openssl x509 -in certificate.crt -noout -enddate

For Remote Servers

Combine s_client and x509 to check a live server’s certificate expiration:

echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -enddate

Automate Expiration Alerts With -checkend

The -checkend flag is something most guides overlook, but it’s incredibly useful for automation. It checks whether the certificate will expire within a specified number of seconds and returns an exit code:

openssl x509 -in certificate.crt -noout -checkend 2592000

The value 2592000 equals 30 days in seconds. If the certificate expires within 30 days, the command returns a non-zero exit code and prints a warning. If the certificate is still valid beyond that window, it returns zero.

This makes it easy to integrate into cron jobs, monitoring scripts, or CI/CD pipelines:

if ! openssl x509 -in certificate.crt -noout -checkend 2592000 > /dev/null 2>&1; then
    echo "WARNING: Certificate expires within 30 days!"
fi

Why this matters: With the CA/Browser Forum moving toward 47-day certificate lifetimes by 2029, automated expiration monitoring isn’t optional anymore, it’s a necessity. Building these checks into your infrastructure now will save you from outages later.

---

Validate the Certificate Chain With openssl verify

A certificate doesn’t work in isolation. Browsers and clients validate the entire certificate chain, a sequence that starts with your server certificate, passes through one or more intermediate CA certificates, and ends at a trusted root CA certificate.

If the chain is broken or incomplete, visitors see a “not trusted” error even though the certificate itself is valid.

To validate a certificate against the system’s trusted CA store:

openssl verify certificate.crt

If it outputs certificate.crt: OK, the chain is complete and valid.

When Intermediate Certificates Are Separate

If your intermediate CA certificate is in a separate file (common with many CA providers, including DigiCert), use the -untrusted flag:

openssl verify -untrusted intermediate.crt certificate.crt

The -untrusted flag tells OpenSSL to use the provided intermediate certificate during chain building without adding it to the trust store permanently.

View the Full Chain From a Remote Server

To see every certificate in the chain from a live server:

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

The -showcerts flag outputs each certificate in the chain in PEM format. This is the go-to command for diagnosing chain issues, like missing intermediate certificates or incorrect ordering.

---

Confirm Your Private Key Matches Your Certificate

After installing a certificate, one of the most common errors is a private key mismatch. The web server won’t start (or will serve a broken connection) if the private key doesn’t correspond to the certificate’s public key.

Here’s how to verify the match. Both commands extract the modulus, a shared mathematical value, and hash it:

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privatekey.key | openssl md5

If the MD5 hashes are identical, the private key and certificate are a valid pair. If they differ, something is wrong. You may have the wrong key, or the certificate was re-issued with a new key pair.

You can extend this check to include your CSR (Certificate Signing Request) too:

openssl req -noout -modulus -in request.csr | openssl md5

All three: certificate, private key, and CSR should return the same hash.

---

Convert Between Certificate Formats

Different servers and platforms require different certificate formats. Apache and Nginx use PEM, while Windows IIS and Tomcat typically need PKCS#12 (.pfx). Here are the most common conversions:

DER to PEM:

openssl x509 -inform der -in certificate.der -out certificate.pem

PEM to DER:

openssl x509 -outform der -in certificate.pem -out certificate.der

PEM to PKCS#12 (.pfx):

openssl pkcs12 -export -out certificate.pfx -inkey privatekey.key -in certificate.crt -certfile ca-bundle.crt

PKCS#12 to PEM:

openssl pkcs12 -in certificate.pfx -out certificate.pem -nodes

The -nodes flag exports the private key without password encryption. Remove it if you want a passphrase-protected output.

Good to know: Certificate files with .crt, .cer, and .pem extensions can all be PEM format. The extension alone doesn’t tell you the encoding, check the file contents. If it starts with —–BEGIN, it’s PEM. If it’s binary gibberish, it’s DER.

---

Troubleshooting Common Certificate Error

When something goes wrong, OpenSSL’s output usually tells you where the problem is. Here’s a quick reference for the most frequent issues:

“unable to get local issuer certificate”. The certificate chain is incomplete. The intermediate certificate is missing from your server configuration. Obtain the correct CA bundle from your certificate provider and configure it alongside your server certificate.

“certificate has expired”. Exactly what it sounds like. The certificate’s “Not After” date has passed. Renew and replace it immediately.

“certificate signature failure”. The certificate was modified or corrupted after signing. Re-download it from your CA provider or re-issue it.

“key values mismatch”. The private key and certificate don’t correspond. Run the modulus comparison from the section above to confirm, then locate the correct key or generate a new CSR.

“self-signed certificate”. OpenSSL can’t trace the certificate back to a trusted root CA. This is expected for self-signed certificates used in development. For production, ensure you have a certificate issued by a publicly trusted Certificate Authority.

“hostname mismatch”. The domain you’re connecting to doesn’t match the Common Name (CN) or Subject Alternative Name (SAN) listed in the certificate. Check the SANs with:

openssl x509 -in certificate.crt -noout -ext subjectAltName

---

Keep Your Certificates Under Control

Checking certificates with OpenSSL is something you’ll do repeatedly throughout the certificate lifecycle, during installation, after renewal, and whenever something breaks. These commands are the fastest way to diagnose problems and verify that everything is configured correctly.

But manual checks only scale so far. If you’re managing multiple certificates across different servers, you need a reliable certificate management process in place, especially as certificate lifetimes continue to shrink and the margin for error gets smaller.

Need trusted SSL certificates? SSL Dragon offers a wide selection of SSL/TLS certificates from top Certificate Authorities like DigiCert, Sectigo, and Thawte, with competitive pricing, fast issuance, and dedicated support. Whether you need a single-domain certificate or an enterprise-level multi-domain solution, you’ll find the right fit.