A TLS certificate binds a public key to a name, such as a domain, and carries a signature from the authority that vouched for it. It proves the server holds the matching private key and that a trusted issuer approved the name. It does not prove the site is honest, safe or free of bugs.
What is actually inside a certificate?
Certificates used on the web follow the X.509 version 3 profile in RFC 5280. The fields that matter day to day are few:
- The subject and the subject public key.
- The issuer, meaning who signed it.
- A validity period, with a not-before and a not-after time.
- Extensions, including the subject alternative name (SAN), basic constraints, key usage and extended key usage.
The extended key usage value for server authentication is what marks a certificate as fit for a TLS server. Basic constraints tell a verifier whether a certificate may itself sign other certificates, which separates a leaf from a certificate authority.
How does a client decide to trust it?
The client does three separate checks, and a failure in any of them should stop the connection.
First, it builds a chain from the server's certificate through intermediates to a root that the client already trusts. RFC 5280 calls this certification path validation. Second, it checks every certificate in that chain for validity dates, signature and permitted use. Third, it checks that the name it meant to reach appears in the certificate.
That last step has a specific rule. RFC 9525 says services are identified through the subjectAltName extension, and that the Common Name must not be used to identify a service. Old tutorials that tell you to put the hostname in the CN field are out of date.
What does a certificate not prove?
It proves control of a name at the time of issuance, and nothing more. A phishing site can hold a perfectly valid certificate for its own look-alike domain. The padlock tells you the channel is encrypted and that you reached the name in the address bar. It says nothing about who runs that name.
It also does not prove the server software is patched, or that the private key is stored well. If the key leaks, the certificate is as good as an open door until it is revoked or expires.
What does a broken certificate look like in practice?
Here is a constructed example. A team runs an internal API at api.corp.example. Their certificate was issued for www.corp.example only, because it was copied from the marketing site. Browsers on the laptop show a name mismatch warning. Someone clicks through, and the habit spreads. A month later a real interception attempt looks identical to the warning everyone has learned to ignore.
The other three failures are older and just as common: a certificate past its not-after date, a server that sends only the leaf and omits the intermediate, and a certificate issued by a private CA that some clients do not trust.
What about protocol versions?
The certificate is only half of the picture. NIST SP 800-52 Rev. 2 requires that government TLS servers and clients support TLS 1.2 with FIPS-based cipher suites and TLS 1.3 from 1 January 2024. NIST also lists a review of that publication as under way, so check the current status before you cite it in an audit.
How to check or apply this
- Inspect what the server really sends. With openssl 1.1.1 or later:
openssl s_client -connect api.corp.example:443 -servername api.corp.example. - Print the fields you care about: pipe the certificate into
openssl x509 -noout -subject -issuer -dates -ext subjectAltName. - Confirm every hostname clients use appears in the SAN list, including any alias or load balancer name.
- Confirm the chain is complete and the server sends intermediates.
- Record the not-after date of each certificate in an inventory and alert well before it. Expiry is the most avoidable outage in this field.
- Never train users to click through a name or trust warning.
Quick check
Does a valid certificate mean a website is safe?
No. It means the connection is encrypted and the certificate matches the name you reached. Attackers can obtain valid certificates for their own domains.
Should I put the hostname in the Common Name?
Put it in the subject alternative name. RFC 9525 says the Common Name must not be used to identify a service, and modern clients rely on the SAN.
What is the most common reason certificates cause outages?
Missed expiry is the usual culprit, followed by names missing from the SAN and incomplete chains. All three are caught by an inventory plus a scheduled check.
Sources
- RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- RFC 9525, Service Identity in TLS
- NIST SP 800-52 Rev. 2, Guidelines for TLS Implementations
Last reviewed: 18 October 2026.
