Read a certificate

A certificate binds names or identities to a public key under an issuer signature. Everything a client checks during verification — who this certificate is for, who vouched for it, when it stops being valid — lives in fields you can decode and read yourself.

Save a lab certificate as server.crt, then inspect it:

openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName

-noout suppresses the encoded certificate itself, so you only get the decoded fields you asked for:

subject=CN = app.lab.test
issuer=CN = Practical TLS Lab CA
notBefore=Aug  1 09:12:00 2026 GMT
notAfter=Aug 15 09:12:00 2026 GMT
X509v3 Subject Alternative Name:
    DNS:app.lab.test, DNS:localhost

Read them in order. subject is the identity the certificate claims. issuer is the authority that signed it. notBefore and notAfter bound the validity window, always in GMT. The last block lists the names this certificate covers.

Check the Subject Alternative Name extension for hostnames. Modern clients validate names there rather than relying on the common name alone. If the hostname you connect to is not in the SAN list, verification fails no matter what the subject line says.

When you need the complete picture, dump the full decode:

openssl x509 -in server.crt -noout -text

That adds the public key type and size, the signature algorithm, and extensions like Key Usage and Basic Constraints. It is more than you usually need, but it is the view that settles arguments about what a certificate does or does not contain.

A mistake I see often: inspecting the wrong file. Servers ship with leaf certificates, intermediates, and bundles that all look identical from the outside. If the subject shows a CA name instead of your hostname, you decoded a CA certificate, not the leaf. Check the file name and the SAN before drawing conclusions.

A certificate is public. You can commit it, mail it, or paste it anywhere. The matching private key is secret. Keep the two files and their permissions distinct.