What an SSL certificate is
An SSL certificate, more accurately called a TLS certificate, is a signed file that binds a public key to one or more domain names. A certificate authority (CA) that browsers trust checks that the applicant controls those names, then signs the certificate. Browsers verify that signature during the TLS handshake.
Certificates use the X.509 format defined in RFC 5280. These are the fields that matter in practice:
- Subject Alternative Name (SAN): the list of hostnames the certificate covers. Browsers match the address against this list and ignore the older Common Name field for that purpose.
- Public key: the server proves it holds the matching private key by signing each handshake with it.
- Issuer: the CA, usually an intermediate, that signed the certificate.
- Validity period: the notBefore and notAfter dates. Outside that window, browsers reject the certificate.
DV, OV and EV validation levels
The validation level describes what the CA checked before issuing. It has no effect on encryption: all three levels use the same algorithms and give the same protection in transit. Major browsers no longer show EV details in the address bar, so for most sites DV is the practical choice.
- Domain Validation (DV): the CA confirms that you control the domain, usually through a token served on your site or published in a DNS TXT record. Issuance can be fully automated.
- Organization Validation (OV): the CA also checks that the named organization exists, and lists its details in the certificate.
- Extended Validation (EV): stricter checks of the organization's legal identity, address and operating existence, under CA/Browser Forum guidelines.
The certificate chain and intermediates
Browsers and operating systems ship with a trust store of root CA certificates. Roots don't sign site certificates directly. They sign intermediate certificates, and an intermediate signs your leaf (end-entity) certificate.
Your server must send the leaf plus every intermediate needed to reach a root. It doesn't need to send the root, because clients already have it.
A missing intermediate causes a classic bug where the site works in one browser and fails elsewhere. Some desktop browsers can fetch or cache the missing certificate, while many mobile apps, command-line tools such as curl and server-to-server clients reject the connection.
Which hostnames a certificate covers
A certificate is valid only for the exact names in its SAN list. The apex example.com and www.example.com are different names, so a certificate for one doesn't cover the other unless both are listed.
A wildcard such as *.example.com covers one label in that position: www.example.com and api.example.com, but not example.com itself and not deeper names like a.b.example.com. You can list the apex and the wildcard in the same certificate.
Wildcards are convenient, but every server that uses one shares the same private key, so a compromise on one host exposes them all. Separate certificates per service limit that risk.
Short lifetimes and automated renewal
Publicly trusted certificates have a maximum lifetime, and CA/Browser Forum rules have cut it several times, with further reductions already scheduled. Free automated CAs issue certificates that last 90 days or less.
Manual renewal does not keep up with that pace, and an expired certificate blocks most visitors. Automate it with ACME (RFC 8555). An ACME client on your server or CDN proves domain control, then requests and installs the new certificate well before the old one expires. Many hosting platforms and CDNs run this for you.
Automation can fail without anyone noticing, for example after a DNS change breaks the validation step. Monitor expiry dates separately and alert weeks ahead.
Common certificate errors and how to fix them
Most certificate errors fall into three groups. The codes shown are Chrome's; other browsers word the same problems differently.
- Expired (NET::ERR_CERT_DATE_INVALID): renew and install the new certificate, then find out why automation failed. The same error appears when the visitor's device clock is wrong.
- Name mismatch (NET::ERR_CERT_COMMON_NAME_INVALID): the hostname isn't in the SAN list. Add it, often the www or apex variant, and reissue.
- Untrusted or incomplete chain (NET::ERR_CERT_AUTHORITY_INVALID): install the full chain your CA provides, or replace a self-signed certificate with one from a public CA.