
Table of Contents
By Khimananda Oli | Last reviewed: August 2026
Managing TLS certificates and cryptographic keys is a daily task for infrastructure engineers, yet syntax errors in openssl commands frequently cause outages or security gaps. This OpenSSL command cheat sheet for DevOps consolidates the exact, verified commands you need for generating keys, creating certificate signing requests (CSRs), verifying chains, and debugging handshake failures in production. Whether you are securing an Nginx reverse proxy or automating certificate renewal in a CI pipeline, these patterns provide a reliable reference that eliminates guesswork and reduces operational risk.
s_client. Always use configuration files over CLI flags for complex extensions to ensure reproducibility and audit compliance.How do you generate secure private keys and CSRs with OpenSSL?
In 2026, RSA 2048-bit keys remain the baseline compatibility standard, but ECDSA (P-256/P-384) and Ed25519 are now preferred for new deployments due to smaller signatures and faster handshakes. A common mistake is generating keys without proper protection or using deprecated algorithms like SHA-1. For any production workload, especially those requiring SOC 2 or ISO 27001 compliance, key generation must be deterministic and documented.
Generate modern private keys
# Recommended: Ed25519 (fastest, smallest, widely supported in 2026)
openssl genpkey -algorithm ed25519 -out server.key
# Alternative: ECDSA P-256 (broadest legacy compatibility)
openssl ecparam -genkey -name prime256v1 -noout -out server.key
# Legacy fallback: RSA 4096 (only if required by vendor)
openssl genrsa -aes256 -out server.key 4096 Create a reproducible CSR with SANs
Never rely on interactive prompts or -subj alone for production certificates. Subject Alternative Names (SANs) and extended key usage must be defined in a configuration file to ensure they survive the signing process. Many CAs silently drop extensions not explicitly requested in the CSR.
# openssl-san.cnf
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[dn]
C = NP
ST = Bagmati
L = Kathmandu
O = Your Company Pvt Ltd
OU = Platform Engineering
CN = api.example.com
[req_ext]
subjectAltName = @alt_names
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
[alt_names]
DNS.1 = api.example.com
DNS.2 = *.internal.example.com
IP.1 = 10.0.1.50 # Generate CSR using the config
openssl req -new -key server.key -out server.csr -config openssl-san.cnf
# Verify CSR contents before submission
openssl req -in server.csr -noout -text -verify This approach aligns with the principles of infrastructure as code discussed in our Infrastructure as Code with Terraform guide, ensuring cryptographic artifacts are version-controlled and auditable rather than manually typed.
How do you verify certificate chains and debug TLS handshakes?
Certificate chain validation failures account for nearly 40% of TLS-related incidents I encounter during audits. Browsers and clients often cache intermediate certificates, masking broken chains until a new user agent connects. Verifying the complete chain locally and testing against live endpoints prevents these silent failures.
Verify local certificate bundles
# Verify full chain including intermediates against system CA store
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
-untrusted intermediate.pem server.crt
# Check certificate dates and subject details
openssl x509 -in server.crt -noout -dates -subject -issuer
# Extract all SANs and extensions
openssl x509 -in server.crt -noout -ext subjectAltName,keyUsage,extendedKeyUsage Debug remote TLS connections
The s_client utility is indispensable for diagnosing handshake issues, protocol mismatches, and cipher negotiation problems in real time. It reveals exactly what the server presents, independent of browser caching.
# Full handshake inspection with SNI
openssl s_client -connect api.example.com:443 \
-servername api.example.com -showcerts
# Test specific TLS version support
openssl s_client -connect api.example.com:443 -tls1_3
openssl s_client -connect api.example.com:443 -tls1_2
# Check accepted ciphers and signature algorithms
openssl s_client -connect api.example.com:443 -brief -cipher ALL
# Simulate client certificate authentication
openssl s_client -connect api.example.com:443 \
-cert client.crt -key client.key -CAfile ca-bundle.crt For teams managing observability stacks, correlating TLS handshake logs with metrics from Prometheus and Grafana monitoring setups helps distinguish between certificate expiry events and transient network failures during incident response.
What are the essential OpenSSL format conversion commands?
Different platforms expect different certificate and key formats. Java keystores require PKCS12, Nginx and Apache expect PEM, while Windows services often need PFX. Incorrect conversions corrupt private keys or strip critical extensions. These commands handle the most frequent transformation scenarios encountered in multi-cloud environments.
| Conversion Task | Command | Notes |
|---|---|---|
| PEM → PKCS12 (.pfx) | openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem -certfile chain.pem | Always include full chain; set strong export password |
| PKCS12 → PEM | openssl pkcs12 -in cert.pfx -out cert.pem -nodes | -nodes removes encryption; omit for encrypted output |
| DER → PEM | openssl x509 -inform der -in cert.der -out cert.pem | Common for Windows-exported certificates |
| PEM → DER | openssl x509 -outform der -in cert.pem -out cert.der | Required for some Java and embedded systems |
| Extract key from PKCS12 | openssl pkcs12 -in cert.pfx -nocerts -nodes -out key.pem | Use -nocerts to exclude certificates |
| Combine cert + key → single PEM | cat cert.pem chain.pem key.pem > bundle.pem | Order matters: leaf → intermediate → key |
When deploying to Kubernetes, remember that secrets management requires careful handling of these converted artifacts. Our article on Kubernetes secrets management done right covers safe injection patterns that prevent accidental exposure during format transformations.
How do you automate certificate operations securely in CI/CD?
Manual certificate management does not scale and introduces human error. In regulated environments, every key generation and signing operation must leave an audit trail. Automation scripts should enforce minimum key lengths, reject weak algorithms, and validate outputs before deployment. Below are battle-tested patterns for integrating OpenSSL into pipelines without compromising security posture.
- Never store private keys in repository variables. Use HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault with short-lived access tokens.
- Validate every generated artifact. Run
openssl verifyandopenssl x509 -checkend 86400immediately after generation to catch malformed certs before deployment. - Enforce algorithm policy. Add pre-commit hooks or pipeline gates that reject RSA < 2048, SHA-1 signatures, or missing SANs.
- Rotate keys proactively. Automate renewal 30 days before expiry; never wait for monitoring alerts as your primary renewal trigger.
- Log operations without logging secrets. Record command invocations, certificate serial numbers, and timestamps—but never private key material or passphrases.
# CI-safe certificate validation gate
#!/bin/bash
set -euo pipefail
CERT_FILE="${1:?Certificate path required}"
DAYS_THRESHOLD=30
if ! openssl x509 -in "$CERT_FILE" -noout -checkend $((DAYS_THRESHOLD * 86400)); then
echo "ERROR: Certificate expires within ${DAYS_THRESHOLD} days"
exit 1
fi
if ! openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt "$CERT_FILE"; then
echo "ERROR: Certificate chain validation failed"
exit 1
fi
echo "Certificate valid and chain verified" Which OpenSSL commands should every DevOps engineer memorize?
Beyond certificates, OpenSSL handles hashing, encoding, and random number generation tasks that appear constantly in scripting and debugging. These utilities replace ad-hoc tools and maintain consistency across environments. Keep this subset accessible in your shell history or team runbooks.
# Generate cryptographically secure random bytes (for tokens, salts)
openssl rand -hex 32
openssl rand -base64 24
# Compute file hashes (integrity verification)
openssl dgst -sha256 release.tar.gz
openssl dgst -sha256 -sign private.key -out signature.bin release.tar.gz
# Verify digital signatures
openssl dgst -sha256 -verify public.key -signature signature.bin release.tar.gz
# Base64 encode/decode (safe for config files)
openssl base64 -in binary.dat -out encoded.txt
openssl base64 -d -in encoded.txt -out decoded.dat
# Benchmark cryptographic performance on current hardware
openssl speed aes-256-gcm chacha20-poly1305 ecdsap256 ed25519 Understanding these primitives supports broader security practices. When configuring database replication over TLS, for example, verifying binary integrity with dgst complements the transport encryption covered in our PostgreSQL replication and high availability guide.
Apply This OpenSSL Command Cheat Sheet for DevOps Today
This OpenSSL command cheat sheet for DevOps gives you the exact commands needed to manage certificates, keys, and TLS operations safely in 2026. Bookmark this page, integrate the validation scripts into your pipelines, and replace manual certificate handling with reproducible, auditable automation. If your team needs help hardening TLS configurations, automating certificate lifecycles, or preparing for a security audit, reach out to discuss your infrastructure needs.