/guides · /guides/ssl-and-https-explained
SSL and HTTPS explained
A certificate proves you control a name and encrypts the connection. It says nothing about whether the site is honest, which is the single most common misreading of the padlock.
What the certificate proves
A TLS certificate binds a public key to a domain name, signed by a certificate authority your browser already trusts. That gives you two things: the traffic is encrypted, and you are talking to whoever controls that name rather than someone in the middle.
That is the whole claim. A phishing site can hold a perfectly valid certificate for its own lookalike domain, and it will show the same padlock as your bank. The padlock is a statement about the connection, not about the people on the other end — if that is the question, who registered the domain, and when tells you more than the certificate ever will.
Validation levels
Browsers no longer display the company name for EV certificates, so the visual difference has effectively disappeared. For most sites, a free automatically issued DV certificate provides exactly the same encryption as a paid one.
Why they expire so quickly
Certificate lifetimes have been shortened deliberately, and are continuing to shorten. A short life limits how long a stolen key is useful and forces the renewal path to be automated rather than a yearly manual chore.
The practical consequence is that renewal must not be a task a human remembers. Automatic issuance and renewal — whether your host does it for you or you run a client yourself — is the only arrangement that survives a busy month. The certificate is the easy half: domain renewal and expiry still depends on a working card and a date nobody has moved.
What usually breaks
An expired certificate, a certificate that does not cover the name being requested (typically www missing from a certificate issued for the apex, which is why it pays to settle whether the apex or www is canonical when you first point the domain at the host), a missing intermediate that works in browsers but fails for API clients, or a redirect chain that drops into plain HTTP somewhere in the middle.
Our own SSL certificate checker reports the issuer, the expiry and the chain, which covers the first three.
HTTPS everywhere, including the redirect
Serve everything over HTTPS and redirect HTTP to it permanently. Two endings make this non-optional: .dev and .app are preloaded as HTTPS-only, so browsers will not load them over plain HTTP at all — a constraint worth knowing before you choose between .com, .net and a newer ending, not after.
The one check worth putting on a schedule: our SSL certificate checker reports days remaining, every name the certificate covers, and whether the chain served is complete — the three things that fail quietly.