An SSL certificate does two things. It encrypts the connection between a visitor's browser and your server, so nobody in between can read what passes. And it proves the server answering is genuinely the one for that domain, so a visitor typing your address does not silently end up somewhere else.
The encryption is what people think of. The identity proof is what makes it work at all, encryption to an impostor protects nothing.
What happens without one
Every request travels in readable form. On a shared network (a café, an airport, an office) anyone positioned between the visitor and your server can read it.
That includes passwords typed into a login form, contact form messages, and the session cookie a logged-in user's browser sends with every single request. That last one matters more than people realise: whoever copies that cookie is that user, without ever needing the password.
Browsers also now mark plain HTTP pages as Not Secure in the address bar, which visitors read as a warning about you rather than a statement about the protocol.
What it does not prove
A certificate says the connection is private and the domain is what it claims. It says nothing about whether the people running the site are honest.
A fraudulent site can hold a perfectly valid certificate, because getting one requires controlling the domain and nothing more. The padlock means your data reaches that site safely. Whether that site deserves your data is a separate question, and this is worth knowing because a great deal of security advice implies otherwise.
Why every site needs one, not just shops
The old rule was that certificates were for sites taking payments. That has not been true for years, for four reasons.
Login sessions. Any site where somebody signs in has session cookies to protect: including your own WordPress admin.
Browser warnings. Not Secure appears on plain HTTP pages regardless of what the site does, and visitors do not distinguish between a technical detail and a warning about the business.
Search ranking. HTTPS is a ranking signal. Small, but free.
Modern browser features. Service workers, geolocation and several others simply do not function without HTTPS.
The cost argument disappeared too. Ahosting includes a free SSL certificate on every plan, so the question is only whether it is switched on.
How it works, briefly
A certificate authority verifies you control the domain, then issues a certificate. Browsers already trust a set of authorities, so a certificate signed by one is trusted without the visitor doing anything.
When a browser connects, the server presents the certificate. The browser checks it covers this domain, has not expired, and traces back to an authority it trusts. If all three hold, an encrypted connection is negotiated and the padlock appears.
Fail any one and the browser shows a warning instead, which is why an expired certificate is as bad as none at all.
Which type you need
Almost certainly the free one. Domain Validation certificates prove domain control and provide exactly the same encryption as the most expensive option available. The differences between validation levels are about vetting, not security. Types of SSL certificates walks through when a paid one is worth it.
Free certificates renew automatically and expire more frequently, which is a feature: automated short-lived certificates fail less often than annual ones somebody has to remember.
Having one is not the same as using it
This is where most sites stop half-finished. A certificate can be perfectly valid while the site still serves plain HTTP, or serves HTTPS pages that pull images and scripts over HTTP.
Three things complete the job:
- The certificate is issued and active for the domain.
- HTTP redirects to HTTPS, so old links and indexed URLs move across: forcing HTTPS.
- No mixed content, so the padlock is not broken by an image loaded insecurely: fixing mixed content warnings.
Partial HTTPS is genuinely worse than it looks. Securing the login page while leaving the rest on HTTP leaks the session cookie on every plain page, which defeats the point entirely.
Getting one active
On Ahosting it is normally issued automatically once the domain points at the server. Check the SSL status page in cPanel, and run it manually for any domain not covered. Installing an SSL certificate in cPanel picks it up from there.
If issuance fails, the cause is nearly always DNS: the domain is not yet pointing here, so the authority cannot verify you control it. Fix the DNS first, retrying alone will not help.
It is equally worth knowing what the padlock does not establish, which is why phishing sites display one. What an SSL Certificate Does Not Protect explains the edges.
Check the certificate is doing its job on every page
A certificate installed correctly still leaves pages that fail, and those are the pages nobody tests. Request a deep page, an image and any address the site uses for forms or interfaces, rather than only the home page. A page loading anything over an insecure connection produces a warning or a blocked request depending on what it is, and the second fails silently. Testing three or four addresses rather than one is the difference between a site that is secure and one whose home page is.