SSL Certificates Explained

You almost certainly need a certificate. Any site with a login, a form or a payment page needs one, browsers flag sites without one, and search engines prefer sites that have one. The only decision is which kind, and for most sites the answer is the cheapest and quickest option.

The product pages that sell certificates make this look harder than it is. They list a dozen types with different names, padlock graphics and warranty figures. Underneath, there are really three questions: how much does the authority check about you, how many names does the certificate cover, and how long does it last.

This guide answers those three in turn, then covers how to get one installed, how to test it, and what changes when you run on shared hosting, a VPS or a managed platform.

What a certificate does

A certificate ties a public key to one or more names and is signed by an authority that browsers trust. When a visitor connects, the server presents it; the browser checks the signature, the names and the dates, and then sets up an encrypted session. That is all. It does not make your site secure in other senses, and it does not vouch for your intentions.

That last point catches people out. Criminals get certificates too, because the most basic type only proves control of a domain name. A padlock means the connection is private and goes to the name in the address bar. It says nothing about whether the site behind that name deserves trust, or whether its software is up to date.

Validation levels

For DV, the authority checks that you control the name, by asking you to place a file at a known URL, add a DNS record, or answer an email to an address tied to the domain. It involves no human looking at your paperwork, which is why it takes minutes and can be automated.

OV and EV add a check on the organisation. The result is that the company name appears inside the certificate, where a curious visitor can find it by clicking the padlock. Years ago EV certificates triggered a green address bar with the company name; browsers dropped that treatment, so the practical benefit is now small. Choose OV or EV because a contract, a regulator or a customer asks for it, not because you expect visitors to notice.

Coverage: how many names

A single-name certificate covers one hostname, often with its www twin. A multi-domain (SAN) certificate lists several names. A wildcard certificate covers every first-level subdomain of one domain, such as *.example.com. Wildcards are convenient, but a compromised key affects all subdomains, and issuing them usually requires DNS-based validation.

Know what a wildcard does not do. *.example.com matches shop.example.com and mail.example.com, but not example.com itself (it is usually added as a second name on the same certificate) and not a.b.example.com, which is two levels down.

Free or paid?

Free certificates, such as those from Let's Encrypt, use the same cryptography as paid ones. The differences are in lifetime, validation level, support and warranty. If you only need encryption, free and automated is hard to beat. Pay if you need OV or EV, a support contract, or a vendor-specific management tool.

Warranty figures on paid certificates look impressive and are almost never relevant. They pay out under narrow conditions, typically if the authority itself made a mistake that cost an end user money. They are not insurance against your site being hacked.

One real reason to pay is device compatibility in unusual environments: old embedded hardware, point-of-sale terminals or industrial gear with a fixed list of roots may not trust newer authorities. If you know such devices connect to your service, test them before choosing.

Lifetimes are shrinking

Certificates once lasted several years. The maximum was reduced to one year, and the industry has agreed to keep reducing it. Short lifetimes limit the damage from a stolen key, and they make automation essentially compulsory. If you still renew by hand, make this the year you stop.

Most hosting panels now renew automatically through ACME. If you run your own server, tools such as certbot or acme.sh install a timer that checks daily and renews when fewer than around thirty days remain. After renewal, the web server must reload to pick up the new files; the tool's deploy hook usually handles that.

certbot certificates
certbot renew --dry-run
systemctl list-timers | grep -i certbot

The dry run tells you whether the next renewal would succeed. Failure is usually a firewall blocking the validation request, a redirect rule that intercepts it, or DNS that no longer points at the server. Put a reminder on the expiry checker for each name, so a silent failure turns into an email rather than an outage.

Key types and a few controls worth knowing

The certificate holds a public key, and that key comes in two common families. RSA is the long-standing default, usually at 2048 bits. ECDSA uses elliptic curves, gives equivalent strength with much smaller keys, and makes the handshake slightly lighter. Both are accepted everywhere that matters today, so take whatever your panel or client defaults to unless you have a reason to choose.

Two controls cost nothing and catch real problems. A CAA record in DNS lists which authorities may issue for your domain, so a mistaken or malicious request to another one is refused:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 iodef "mailto:[email protected]"

Use the authority you actually use, of course; the line above is an example. The second control is Certificate Transparency: every publicly trusted certificate is recorded in public logs, and you can search them for your domain to spot certificates you did not request. If you find one, contact the issuing authority and look at who has access to your DNS and validation emails.

Installing and testing

Most hosts provide a one-click install. If you do it manually, generate a key and CSR, submit the CSR, complete validation, then install the certificate with its chain.

1. Generate a private key and CSR on the server: openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com".
2. Submit the CSR to the authority and choose the validation method.
3. Complete validation: publish the file, add the DNS record, or approve the email.
4. Download the certificate and the intermediates, and build a chain file with your certificate first.
5. Install the files in your server or panel, then reload.
6. Test with an online checker and look at both the bare domain and www.

See the file formats guide if you get stuck with extensions. If you are moving an existing site over from HTTP, the HTTPS migration guide covers the redirects and the settings around the certificate.

Worked examples: choosing for three real situations

A two-person consultancy runs a WordPress brochure site and a contact form. Domain validation, a single-name certificate covering the bare domain and www, issued and renewed by the hosting panel. Total effort: a few clicks, then a check a month later that renewal still works.

A small online shop has a main site, a separate shop.example.com and a help.example.com on a hosted support tool. Domain validation again, but now a choice: three single-name certificates, one SAN certificate listing all three, or a wildcard. If the support tool brings its own certificate (most hosted tools do when you point a name at them), then the shop only needs the first two, and a SAN certificate is plenty.

A regional charity takes donations and its board wants the organisation's name inside the certificate. That is a fair reason for OV. The validation takes a few days because someone checks registration records and phones a listed number, so start before the old certificate runs out, not after. Even here, the cryptography is unchanged; only the vetting differs.

Common problems and what they mean

Most certificate trouble falls into a few families, and the browser message usually points at the right one.

• Name mismatch: the certificate does not list the hostname used. Add the name and reissue, or fix the link that uses the wrong one.
• Expired: renewal failed or the web server never reloaded. Fix the renewal path, then reload.
• Untrusted issuer or incomplete chain: the intermediate is not being sent. Install the full chain file.
• Self-signed: the certificate was made by the server itself, which is fine for private testing and unacceptable for the public internet.
• Weak or removed algorithm: very old certificates and servers still offer outdated settings that current browsers refuse. Update the server software and its TLS configuration.

The troubleshooting guide works through the symptoms from the visitor's side, and the glossary explains the terms if a message includes words you have not met.

What changes by hosting type

Look at your own configuration

1. Click the padlock in the browser and read the issuer, the names and the expiry date.
2. From a terminal, run openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName to see the names and dates.
3. Repeat for the www name and for any subdomains in use.
4. On a server you run, confirm the renewal job exists and the dry run passes.
5. Check the HTTP address redirects to HTTPS with curl -I http://example.com/.