opensslInspect certificates, test TLS and create keys and CSRs
openssl is the Swiss army knife of TLS. DevOps engineers use a handful of its subcommands daily: x509 to read a certificate's subject, SANs and expiry, s_client to test a live TLS endpoint and its chain, req to create keys and CSRs, and a few checks to match keys with certificates.
openssl x509 -in CERT -noout [-subject -issuer -dates -ext subjectAltName] | openssl s_client -connect HOST:PORT [-servername NAME] | openssl req -new ...A cert file was handed to you for an nginx vhost and you want to check it before installing it.
opensslOne binary with many subcommands; the first argument picks the tool.
openssl is the command-line front end to the OpenSSL library (version 3 on Ubuntu 24.04 and Amazon Linux 2023). Certificates are X.509 structures encoded in DER and usually stored as base64 PEM between BEGIN/END lines; x509 decodes them and prints fields such as the subject, issuer, validity dates and extensions like subjectAltName, which is what browsers and clients actually match against the hostname (the CN is ignored for that). s_client opens a TCP connection and runs a real TLS handshake: it sends a ClientHello with the SNI name, receives the server's certificate chain, verifies each signature up to a trusted root in the system CA store (/etc/ssl/certs) or -CAfile, checks dates, and prints the result as 'Verify return code'. Hostname checking only happens if you add -verify_hostname. req creates a private key and a certificate signing request (CSR) that a CA turns into a certificate; -x509 makes a self-signed certificate instead. A key and a certificate belong together when their public keys match.
openssl s_client runs a real TLS 1.3 handshake and verifies the server's chain against trusted roots, printing every step.
s_client opens TCP to port 443 and sends a ClientHello: supported TLS versions and ciphers, a key share, and the SNI name from -servername.
x509 -noout -subject -issuer -datesWho the cert is for, who signed it, valid from/tox509 -noout -ext subjectAltNameThe DNS names and IPs the cert is valid forx509 -checkend SECONDSExit 1 if the cert expires within SECONDS (monitoring)x509 -text -nooutDecode every field of a certificates_client -connect H:P -servername HTest a TLS endpoint with SNIs_client -showcerts / -CAfile FPrint the full chain / verify against a private CAreq -new -newkey rsa:2048 -nodesNew key plus CSR (-nodes = don't encrypt the key)req -x509 -days NSelf-signed certificate instead of a CSRpkey -pubout / x509 -pubkeyExtract public keys, e.g. to check a key matches a certverify -CAfile CA CERTCheck a certificate chains to a CArand -hex 32 / -base64 32Random secrets and tokensdgst -sha256 FILEHash a file or inputopenssl s_client -connect host:443 without -servername on a server with many vhostsOpenSSL 3 sends SNI from -connect when it's a hostname, but when you connect to an IP (or a load balancer name) no correct SNI is sent and you inspect the default certificate.
Always add -servername the.real.hostnameTrusting 'Verify return code: 0' to mean the hostname is rights_client verifies the chain, not that the certificate matches the name you connected to.
Add -verify_hostname NAME, or check the SAN list with x509 -ext subjectAltNameInstalling only the leaf certificate in nginx or a load balancerClients without the intermediate cached fail with 'unable to verify the first certificate'; it often works in a browser and fails in curl, Java or mobile apps.
Serve leaf + intermediates (fullchain.pem), verify with s_client -showcertsChecking only the CN when a cert 'doesn't match the host'Modern clients ignore the CN and use subjectAltName exclusively.
openssl x509 -noout -ext subjectAltName -in cert.pemTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a self-signed certificate and key for lab.local valid for 30 days, with a SAN, in ~/app.
Print the subject, the expiry date and the SAN of that certificate, then check whether it expires within 60 days.
Prove that lab.key belongs to lab.crt.
Generate a random 32-byte secret, printed as hex, for an API token.
opensslInspect certificates, test TLS and create keys and CSRs
openssl is the Swiss army knife of TLS. DevOps engineers use a handful of its subcommands daily: x509 to read a certificate's subject, SANs and expiry, s_client to test a live TLS endpoint and its chain, req to create keys and CSRs, and a few checks to match keys with certificates.
openssl x509 -in CERT -noout [-subject -issuer -dates -ext subjectAltName] | openssl s_client -connect HOST:PORT [-servername NAME] | openssl req -new ...A cert file was handed to you for an nginx vhost and you want to check it before installing it.
opensslOne binary with many subcommands; the first argument picks the tool.
openssl is the command-line front end to the OpenSSL library (version 3 on Ubuntu 24.04 and Amazon Linux 2023). Certificates are X.509 structures encoded in DER and usually stored as base64 PEM between BEGIN/END lines; x509 decodes them and prints fields such as the subject, issuer, validity dates and extensions like subjectAltName, which is what browsers and clients actually match against the hostname (the CN is ignored for that). s_client opens a TCP connection and runs a real TLS handshake: it sends a ClientHello with the SNI name, receives the server's certificate chain, verifies each signature up to a trusted root in the system CA store (/etc/ssl/certs) or -CAfile, checks dates, and prints the result as 'Verify return code'. Hostname checking only happens if you add -verify_hostname. req creates a private key and a certificate signing request (CSR) that a CA turns into a certificate; -x509 makes a self-signed certificate instead. A key and a certificate belong together when their public keys match.
openssl s_client runs a real TLS 1.3 handshake and verifies the server's chain against trusted roots, printing every step.
s_client opens TCP to port 443 and sends a ClientHello: supported TLS versions and ciphers, a key share, and the SNI name from -servername.
x509 -noout -subject -issuer -datesWho the cert is for, who signed it, valid from/tox509 -noout -ext subjectAltNameThe DNS names and IPs the cert is valid forx509 -checkend SECONDSExit 1 if the cert expires within SECONDS (monitoring)x509 -text -nooutDecode every field of a certificates_client -connect H:P -servername HTest a TLS endpoint with SNIs_client -showcerts / -CAfile FPrint the full chain / verify against a private CAreq -new -newkey rsa:2048 -nodesNew key plus CSR (-nodes = don't encrypt the key)req -x509 -days NSelf-signed certificate instead of a CSRpkey -pubout / x509 -pubkeyExtract public keys, e.g. to check a key matches a certverify -CAfile CA CERTCheck a certificate chains to a CArand -hex 32 / -base64 32Random secrets and tokensdgst -sha256 FILEHash a file or inputopenssl s_client -connect host:443 without -servername on a server with many vhostsOpenSSL 3 sends SNI from -connect when it's a hostname, but when you connect to an IP (or a load balancer name) no correct SNI is sent and you inspect the default certificate.
Always add -servername the.real.hostnameTrusting 'Verify return code: 0' to mean the hostname is rights_client verifies the chain, not that the certificate matches the name you connected to.
Add -verify_hostname NAME, or check the SAN list with x509 -ext subjectAltNameInstalling only the leaf certificate in nginx or a load balancerClients without the intermediate cached fail with 'unable to verify the first certificate'; it often works in a browser and fails in curl, Java or mobile apps.
Serve leaf + intermediates (fullchain.pem), verify with s_client -showcertsChecking only the CN when a cert 'doesn't match the host'Modern clients ignore the CN and use subjectAltName exclusively.
openssl x509 -noout -ext subjectAltName -in cert.pemTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a self-signed certificate and key for lab.local valid for 30 days, with a SAN, in ~/app.
Print the subject, the expiry date and the SAN of that certificate, then check whether it expires within 60 days.
Prove that lab.key belongs to lab.crt.
Generate a random 32-byte secret, printed as hex, for an API token.