HTTPS and SSL Certificates
HTTPS is HTTP over a TLS connection. The padlock means the browser verified a certificate for the name in the address bar and then encrypted the traffic to that server. It does not mean the shop is honest or the page is safe to click. This guide explains what a certificate proves, domain / organization / extended validation, free certificates and auto-renewal, how issuance validation works, mixed content, forcing HTTPS, and checking expiry. Examples use example.com.
What a certificate actually proves
A public certificate binds a public key to one or more names (example.com, www.example.com). A certificate authority (CA) signs that binding after some check. Your browser trusts a list of CAs. During TLS, the server presents the certificate, the browser checks the signature, dates, revocation information it is willing to use, and whether the name matches.
Encryption then uses keys derived from that handshake so a cafe Wi-Fi operator cannot read the form in transit. They can still see that you connected to the server. HTTPS does not hide the domain name from the network in the way people sometimes hope.
A certificate does not prove that the business is licensed in Dubai, that the content is true, or that the WordPress site is patched. Those are separate jobs.
DV, OV, and EV
Domain Validation (DV) checks control of the domain (HTTP file, DNS TXT, or email to a role address). Almost all everyday certificates, including the free ones, are DV. The browser shows a padlock and the name.
Organization Validation (OV) adds checks on the legal organization. Extended Validation (EV) is a stricter organizational check. Browsers used to highlight EV in the bar; that highlight has largely gone away. For a small site, DV is what you will use. Extra validation does not make TLS stronger cryptographically. It may still matter for some procurement checklists. It is not a ranking trick.
Wildcard certificates cover a single label, such as *.example.com, which matches www.example.com and shop.example.com but not the apex example.com (you usually include the apex as a separate name on the same cert) and not a.b.example.com. Do not put a wildcard on a shared server you do not control.
Free certificates and auto-renewal
Let’s Encrypt and similar CAs issue short-lived DV certificates at no charge. Hosts and reverse proxies often request them automatically and renew before expiry. Short life is a feature: a stolen key ages out. The operational requirement is that renewal must keep working.
Auto-renewal fails when:
- The HTTP or DNS validation path broke (a new firewall, a wrong A record, a rate-limited API).
- The machine’s clock is wrong.
- The certificate job was tied to a control panel you migrated away from.
Put expiry on a calendar even if renewal is automatic. A 90-day cert that nobody watches is how a shop goes “Not secure” on a Thursday. Commercial CAs still exist for longer life or organization validation; the TLS on the wire can be the same quality either way.
How issuance validation works
The CA must see proof you control the name. Typical methods:
- HTTP-01: the CA fetches
http://example.com/.well-known/acme-challenge/…and expects a token. The A/AAAA record must point at the machine that answers that path. A redirect to HTTPS is usually allowed if the token still appears. A redirect to another domain can fail. - DNS-01: the CA looks for a TXT record on
_acme-challenge.example.com. This is how wildcards are issued. You need API access to DNS or a manual TXT you remove later. - Email to a listed contact, used more by traditional CAs than by ACME automation.
If DNS still points at the old host, the new host cannot complete HTTP-01. Fix DNS records first. If several names are on one certificate, every name must validate.
Mixed content
A page served on HTTPS that then loads a script, stylesheet, or (in strict cases) an iframe over plain HTTP is mixed content. Browsers block mixed scripts. Images may still warn. The page can look “half broken”: no menu, no analytics, no payment widget.
Fix by using https:// URLs or root-relative paths, and by enabling HTTPS on whatever host serves those assets. Search the database and theme for http://example.com. A content delivery network should offer HTTPS on its hostname. After a domain move, leftover absolute HTTP links are a common cause. Redirects from HTTP to HTTPS on your own site do not rewrite URLs inside HTML you already sent; you still need the source to say HTTPS.
<!-- mixed: blocked as active content -->
<script src="http://example.com/menu.js"></script>
<!-- ok -->
<script src="https://example.com/menu.js"></script>Forcing HTTPS
Once the certificate works for the names you use, send visitors to HTTPS on purpose. That is usually:
- A 301 redirect from http://example.com to https://example.com (and the www / non-www pair you chose).
- HSTS (Strict-Transport-Security) only after you are sure HTTPS works for every subdomain you include. HSTS is cached by browsers; a mistake is sticky. Start with a short max-age if you use it at all.
- Application settings (WordPress “Site URL”, reverse proxy
X-Forwarded-Proto) so the app does not generate HTTP links behind a TLS terminator.
Redirect loops happen when the app redirects to HTTPS and the proxy also redirects, or when the app thinks it is still on HTTP. Fix forwarding headers rather than stacking more redirects.
Checking expiry and names
In the browser, open the certificate viewer and read: names (SAN list), issuer, not-before, not-after. On a server you control, you can inspect the file or use the host’s panel. Confirm:
- Every public name you use is on the certificate (apex and www are different).
- Dates include today with margin for renewal.
- The chain is complete (browsers need intermediates, not only the leaf).
Set a reminder a few weeks before expiry. After renewal, check the live site, not only the panel. A panel can show a new cert while the load balancer still presents the old one. If you use a CDN, know which layer holds the cert visitors see.
Site speed still matters on HTTPS; TLS is cheap next to huge images. See website speed settings rather than turning TLS off “for performance,” which is not a modern tradeoff you should make.
Checklist
- Certificate names match the URLs you publish, including www vs apex.
- Renewal is automatic and you still watch expiry.
- Validation method still works after DNS or firewall changes.
- No mixed http:// scripts or stylesheets on https:// pages.
- One clean HTTP → HTTPS redirect, no loop, app URLs generated as HTTPS.
Get HTTPS working on a staging hostname first if you can. Then copy the same process to example.com, and only then turn on a long HSTS max-age.
Related guides
General technical information; test changes carefully and keep backups of your settings.