OpenSSL is an open-source toolkit used to work with TLS/SSL, certificates, keys, and cryptographic operations.
If you work in DevOps or platform engineering, you don’t need to be a full-time PKI specialist to benefit from it. You just need a reliable set of commands you can use when the usual certificate tasks show up.
In real environments, this comes up more often than people expect:
- checking if a certificate is valid or expired
- inspecting certificate details during incident response
- converting certificate formats between teams and tools
- extracting certs and keys from
.pfxfiles for load balancers, ingress, or app configs
Knowing a few practical OpenSSL commands helps you troubleshoot faster, automate safely, and avoid guesswork when security-related changes are on the critical path.
This guide keeps it hands-on: copy/paste-ready commands, plain-English explanations, and no crypto gatekeeping.
OpenSSL Installation
First up, let’s install OpenSSL and make sure your terminal can find it straight away.
| |
| |
OpenSSL Commands
The examples below use a local cert-lab folder so you can test safely before touching real certificates.
IMPORTANT
These examples are for local testing and learning only. Don’t use self-signed certs in production.
Generate a local test certificate
| |
| |
Generate a local test certificate pfx
This is useful when an app, gateway, or platform expects a .pfx/.p12 bundle.
| |
| |
Inspect certificate details
| |
| |
Check expiry and validity window quickly
| |
| |
Check and validate a CSR
Use this before submitting a request to your CA so you can catch mistakes early.
| |
| |
Decrypt an encrypted private key (remove passphrase)
Use this when automation or a service account needs a non-interactive key file.
IMPORTANT
A decrypted private key is sensitive. Lock down file permissions and only use where required.
| |
| |
Split a .pfx into leaf cert, chain certs, and private key
This is one of the most common DevOps tasks when moving certs between systems.
| |
| |
Verify that certificate / CSR / private key match
The safest way is to compare a hash of each public key.
If the hashes are the same, they belong together.
| |
| |
Troubleshooting and Issues
Even when your commands are correct, certificate tasks can fail for non-obvious reasons. Here are the issues that come up most often.
“Key values mismatch” or cert won’t bind to service
Cause: The certificate and private key are from different keypairs.
Fix: Compare public key fingerprints from cert and key. They must match.
| |
| |
Browser/app says hostname is invalid
Cause: The certificate SAN does not include the hostname you’re using.
Fix: Reissue cert with the correct subjectAltName values (DNS/IP).
Quick check:
| |
| |
Certificate chain errors (incomplete chain / unknown CA)
Cause: Only leaf cert is deployed, missing intermediate(s).
Fix: Deploy full chain in the order your platform expects (usually leaf + intermediate).
Quick check:
| |
| |
“bad decrypt” / “mac verify failure” when opening .pfx
Cause: Wrong password, corrupted file, or incompatible encoding/transfer.
Fix:
- Re-check password source (watch hidden whitespace)
- Re-export PFX from original source if possible
- Re-transfer file in binary-safe mode
Quick check:
| |
| |
“unable to load private key”
Cause: Wrong file format, encrypted key without passphrase provided, or key file damage.
Fix:
- Try reading with
openssl pkey -in ... - Convert to PKCS#8 if needed
- Confirm the file begins with a valid PEM header (for PEM files)
Quick check:
| |
| |
CSR looks fine but issued cert is still wrong
Cause: CA template/profile overrides CSR fields (common in enterprise PKI).
Fix: Validate both sides:
- inspect CSR before submission
- inspect issued cert after issuance
- compare SAN/subject/key usage/extended key usage
Wrap Up
OpenSSL covers a lot of ground, but most day-to-day certificate work comes down to a small set of commands you’ll reach for repeatedly — inspecting certs, checking expiry, exporting to .pfx, splitting bundles, and verifying key pairs.
The cert-lab setup at the start of this guide gives you a safe place to practice all of it without touching production certificates. Run through the commands, break things intentionally, and get comfortable reading the output before you need it under pressure.
A few things worth keeping in mind:
- Always verify a cert/key pair matches before deploying
- Check SANs match the hostname your service is actually using
- When in doubt about a chain error,
openssl verifyis your first stop - Decrypted private keys need tight file permissions — treat them like passwords
If you hit an error not covered here, the output from openssl ... -text -noout usually gives you enough to work with.