Certificates are one of those subjects where the advice you were given five or ten years ago is still circulating, long after the facts moved on. Encryption used to be a cost and a chore; it is now close to a default, handled by software on a schedule. Yet people still pay for things they do not need, put off things that matter, and believe the padlock promises more than it does.
Here are eight claims about SSL and HTTPS, each with a verdict and the reasoning. A word on terms first: SSL is the old name, and what is in use today is TLS. Everyone, including me, still says "SSL certificate" because that is what the product is called on the invoice.
Where it helps, I show the command you can run to see the facts for yourself. Everything needs only a terminal and a domain name you own or manage.
1. HTTPS makes your site slower
Myth
This was arguably true around 2010, when encryption added noticeable overhead and older servers struggled. Today the cost of encryption is negligible on any current hardware, and the protocols that require HTTPS, namely HTTP/2 and HTTP/3, can make pages load faster than plain HTTP ever did.
The remaining cost is the handshake at the start of a connection, which modern versions of TLS have shortened to a single round trip. Compared to a three megabyte image, it is noise.
The cost of encrypting data once a connection is established is small because processors have dedicated instructions for the common ciphers (AES-NI on x86, equivalent extensions on ARM). A budget phone can encrypt traffic faster than its mobile network can deliver it. The extra CPU on the server, spread over thousands of requests, is a fraction of what PHP spends generating one page.
The handshake is where the remaining time goes. With TLS 1.2, a new connection needed two extra round trips after the TCP connection opened before any request could be sent. TLS 1.3 reduced that to one, and a visitor who has been to the site recently can resume a session and send data in the first flight. If the visitor is 80 milliseconds from the server, that is the difference between about 160 and 80 milliseconds of waiting, once per connection, and connections are reused for many files.
Now the gain. Browsers only speak HTTP/2 and HTTP/3 over encryption. These protocols send many requests down a single connection at once, compress headers, and avoid the queueing that made old HTTP/1.1 pages crawl when they had forty small files. HTTP/3 additionally runs over QUIC, which copes much better with packet loss on mobile networks. For a typical page, the net result is faster loading with HTTPS than without it.
If an HTTPS site feels slow, look elsewhere: an uncached dynamic page, a distant server, or a large image. Our page weight tool is a useful first look.
2. Free SSL certificates are less secure
Myth
The encryption in a free certificate is exactly as strong as in a paid one. Both use the same algorithms and key sizes. What differs is validation and extras: paid certificates may include organisation details, warranty cover, a support line, or a longer lifetime.
For the large majority of sites, an automatically renewed free domain-validated certificate is the better choice, because the biggest real-world risk is forgetting to renew a manually purchased one.
A certificate does two jobs. It carries the public key that lets the browser set up an encrypted session, and it carries a statement from a certificate authority (CA) that the holder of that key controls the domain name. The encryption comes from the key and the TLS protocol; the CA only vouches for the name. Strength depends on the key type (a 2048-bit RSA key or an elliptic curve key such as P-256), and free and paid certificates use the same ones.
Free certificates from ACME-based authorities are issued by the same sort of audited, browser-trusted organisations that sell paid ones. They are domain-validated: software proves you control the domain by placing a file on your site or a record in your DNS, and the certificate is issued in seconds. Paid domain-validated certificates do exactly the same check. The difference is the invoice.
What a paid certificate may give you: a warranty (rarely claimed and with narrow conditions), phone support from the vendor, and validation of the organisation's name for OV and EV types. Some buyers need those for policy reasons, and that is a fair reason. The lifetime is also shorter for free ones, typically ninety days or less, which sounds like a drawback until you notice that automation renews them without anyone thinking about it.
The one thing that actually compromises security here is a private key that leaks, which is independent of price. And an expired certificate, which turns a secure site into a warning page, is the failure I meet most often. That is where the real difference lies: automatic versus manual.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates -subjectThis prints who issued the certificate, its dates and the name it is for. Try it on a few sites you use and see how many are on short, automatically renewed certificates.
3. You can wait until the last day to renew a certificate
Myth
Waiting until the final day leaves no room for anything to go wrong, and plenty can: a validation that fails, a payment that bounces, a DNS record that changed, a mail address that nobody reads.
Automated renewal typically starts a few weeks before expiry so that problems are caught while the old certificate still works. If you renew by hand, set the reminder for a month ahead.
Think about what renewal involves. The CA must validate the domain again, either by fetching a file from your server, by checking a DNS record, or by emailing an address such as [email protected]. Any of these can be broken by changes made since last time. A redirect added to the whole site may block the validation file. A firewall rule may refuse the CA's servers. A DNS provider change may have left the old validation record behind. The approver mailbox may have gone to a colleague who left two years ago.
With paid certificates there is also procurement: a purchase order to raise, a card that expired, a person on leave. These are the reasons I see certificates lapse on the very day, usually on a Friday, with the shop's checkout showing a full-page warning.
Automated tools aim to renew with plenty of time left. If a renewal attempt fails at 30 days out, you have a month to investigate, and the visitors never notice. That buffer is the entire point of starting early.
The same logic applies to manual renewals, and to anything with a deadline: pick a date that leaves room for the first attempt to fail. Add it to a calendar with an alert, and for important sites add a monitor that checks expiry from the outside. The SSL expiry tool shows the days remaining for any hostname.
4. HTTPS hides which sites you visit
Myth
HTTPS encrypts the content of the conversation: pages, forms, cookies. It does not hide the fact that you connected to a particular server. Your provider can generally see the address, and often the hostname, because DNS lookups and the start of the handshake reveal it.
Encrypted DNS and newer extensions reduce this exposure, but it is not the same as anonymity.
Consider what travels across the network when you open a page. First, a DNS query asking for the address of the site. By default this goes out unencrypted, so your provider, or anyone on the same wifi, sees the name you asked for. Second, a connection to an IP address, which is visible, and an address often identifies the site on its own. Third, the start of the TLS handshake, in which the browser states the hostname it wants (the Server Name Indication field) in readable form so that the server knows which certificate to offer.
After that, everything is encrypted: the path (/clinic/appointments), the page content, form data, and cookies. An observer can see that you visited example.com and roughly how much data moved, but not which page or what was in it.
Encrypted DNS (DNS over HTTPS or DNS over TLS) closes the first leak, and Encrypted Client Hello is an extension that closes the second, though it needs support from both browser and site and is not yet universal. Even with both, the destination IP address remains, and a busy shared address gives you some cover, while a dedicated one gives you none.
The padlock also says nothing about the site's honesty. A phishing page can have a perfectly valid certificate, since the certificate vouches only for the domain name and not for the intentions of the owner.
5. A wildcard certificate is always better
Myth
Wildcards are convenient: one certificate covers every subdomain. They also mean one private key protects everything, and a compromise of any server holding it affects all of them. Validation requires DNS control, which complicates automation.
If you have a few known names, individual or multi-name certificates are often safer and easier.
A wildcard for *.example.com covers www.example.com, shop.example.com, staging.example.com and any other name one level below. It does not cover example.com itself (that name is normally added as a second entry), nor names two levels down such as a.b.example.com.
The convenience is real if you create subdomains often, such as one per customer on a hosted platform. But look at the costs. The same private key and certificate typically need to be installed on every server that handles any of those names. If staging runs on a laptop and the key is copied there, a theft of that laptop exposes the key for the production site as well. A leaked wildcard key lets an attacker impersonate any name under the domain, including ones you create next year.
Issuance is stricter too. Free automated authorities require the DNS-01 method for wildcards: your software must create a TXT record at _acme-challenge.example.com. That means giving the renewal software an API credential for your DNS, and that credential is itself something to protect. If your DNS provider has no API, automation is hard and the certificate becomes a manual job, which brings back the forgotten-renewal risk.
Using separate certificates for separate names limits the damage from any one leak, can be renewed using simple HTTP validation, and shows in public transparency logs as exactly the names you use. Some people prefer wildcards for the reverse reason, that the logs do not reveal their internal hostnames. That is a legitimate reason, and worth weighing.
A rule of thumb: ten names or fewer that you know in advance, use individual or multi-name certificates. Hundreds of names created automatically, a wildcard with good key handling makes sense.
6. You can ignore the certificate warning on your own site
Myth
Visitors cannot tell a harmless expiry from an attack, and the browser is designed to make proceeding feel risky. Most people leave, and the ones who click through learn to ignore warnings elsewhere.
Fix it quickly. Meanwhile, check whether the real problem is expiry, a missing name or an incomplete chain.
From the visitor's side, a certificate error looks the same whether the cause is an owner who forgot to renew or someone intercepting the connection. The browser cannot distinguish them and says so. In current browsers the message is a full page with a red warning, and the button to continue is tucked behind an "advanced" link. That design is deliberate and it works: most people turn back.
The owner's habit of "I know it's fine, I'll click through" has a cost beyond the lost visit. It trains habits that serve attackers well. A staff member who clicks through the warning on the company site is more likely to click through one on a public network, where it might be a real interception.
There are four usual causes, and each has a different fix:
- Expired certificate: renew it and install it. The error in the browser says "expired" or shows a date.
- Name mismatch: the certificate covers example.com but the visitor used www.example.com, or the other way round. Reissue with both names.
- Incomplete chain: the server sends the site certificate but not the intermediate, so some devices (often older Android phones and command-line tools) cannot link it to a trusted root. Install the full chain file.
- Wrong certificate served: a shared IP with no SNI support, or a default virtual host answering instead of yours.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "s:|i:|Verify return"The output lists each certificate in the chain with its subject (s:) and issuer (i:), and ends with a verify code. "Verify return code: 0 (ok)" is what you want to see. Anything else names the problem.
Remember that a browser can cache a working view, so test from a private window and from a phone on mobile data, which has no stored state about your site.
7. EV certificates make a site more secure
Myth
An extended validation certificate involves more identity checking. The encryption is the same as a basic certificate. Browsers used to display the company name in a green bar and no longer do.
EV can still matter where policy demands it. For most websites, it adds cost and no practical protection.
Certificates come in three validation levels. Domain validation (DV) proves control of the domain. Organisation validation (OV) adds checks that the named organisation exists. Extended validation (EV) applies a stricter and more manual set of checks on the legal entity. All three use the same technology, with the same key types and the same ciphers. A DV certificate and an EV certificate encrypt traffic identically.
The idea behind EV was that users would look at the address bar, see the company name in green, and know they were on the real site. Research and experience showed that people rarely noticed or understood the indicator, and attackers could register lookalike company names. Around 2019, major browsers removed the special display, and now the details sit behind a click on the padlock, where hardly anyone looks.
So the main benefit, visible assurance for visitors, mostly vanished. What remains is the vetting itself, which some organisations need to meet an internal policy or a contract. A bank may require OV or EV for specific systems; a procurement rule may say so; an audit may ask. Those are valid reasons, and they are about paperwork rather than protection.
The practical downsides of EV are cost, a slower issuance process that involves documents and phone calls, and the risk that a lapse in one of those checks delays a renewal. Weigh that against a free DV certificate protecting the same traffic with the same strength.
If you want visitors to trust the site, put your name, address and contact details on it, use a domain that matches your brand, and set up email authentication so that nobody can easily send fakes in your name. Those do far more for trust than a bar.
8. SSL only matters for shops and login pages
Myth
Browsers mark plain HTTP pages as not secure, search engines prefer HTTPS, and modern protocols such as HTTP/2 need it. Without encryption, anyone between you and the visitor, including some internet providers and public wifi hotspots, can alter pages or inject adverts.
Even a brochure site benefits.
The old idea was that encryption protects secrets, and a brochure site has none. But encryption does a second job: it keeps the page intact. Over plain HTTP, any device between the server and the visitor can read and rewrite the traffic. Hotel wifi and some mobile networks have injected adverts, tracking code and banners into pages in the past. A hostile hotspot can swap the download link on your software page for a different file, or add a form that asks for a card number to your otherwise harmless contact page.
Then there are the practical points. Current browsers label HTTP pages "Not secure" in the address bar and, in some versions, warn before loading them or try HTTPS first. A visitor who sees that on a clinic's page or a local business website will think twice about phoning the number it lists. Contact forms and newsletter sign-ups collect names and email addresses, which are personal data even if no payment is involved, and sending them in clear text is hard to defend.
Features also depend on it. Geolocation, service workers, camera access, and many newer browser features work only on secure origins. And HTTP/2 and HTTP/3 are, in practice, HTTPS-only.
Moving a site to HTTPS takes a few steps. Install a certificate, redirect HTTP to HTTPS with a permanent redirect, update internal links and image URLs so they are not mixed content (HTTP resources on an HTTPS page, which browsers block or flag), and update the site address in WordPress or your CMS settings. Then check the redirect:
curl -sI http://example.com/ | head -5
HTTP/1.1 301 Moved Permanently
Location: https://example.com/The redirect generator produces the rules for common servers. Later, add an HSTS header once everything is stable, which tells browsers to always use HTTPS for your domain.
Try it on your own site
Run the openssl command from claim 2 against your own domain and note the issuer, the expiry date and the subject. Run the one from claim 6 and look for "Verify return code: 0 (ok)". Request your plain HTTP address with curl -I and confirm a single 301 to HTTPS rather than a chain of redirects. Open the site in a private window and click the padlock to see the certificate details, then look at the browser console for mixed content messages. Finally, put the expiry date in a calendar with an alert, or check it with the SSL expiry tool now and then. If you meet an error you cannot place, the troubleshooting guide is a good next stop.
Smaller questions
Do I need a dedicated IP address for HTTPS?
No. SNI lets many certificates share one address, and every current browser supports it. Dedicated addresses are only needed for very old client software.
Does the padlock mean a site is safe to trust?
It means the connection is encrypted and the certificate matches the domain. It does not say the owner is honest, and phishing sites routinely have valid certificates.
What happens to my certificate if I change hosts?
The certificate belongs to the key pair on the old server. You normally issue a new one on the new host, ideally before pointing the DNS at it, so there is no gap in coverage.
Are self-signed certificates acceptable?
For internal testing, yes. For a public site, no: browsers do not trust them and visitors will see a warning on every visit.