SSL Certificates and HTTPS for Business Sites
The padlock and the "https" in your address bar come from a TLS certificate, still often called an SSL certificate (MDN notes that SSL is the precursor to TLS). Every business site needs one, and most can get one free. This guide explains what the certificate does and does not do, the difference between DV, OV and EV certificates, why certificates now expire sooner than they used to, and two follow-up jobs: fixing mixed content and turning on HSTS. It is based on documentation from MDN, Let's Encrypt and the CA/Browser Forum, checked on 30 October 2026.
What TLS and HTTPS actually do
MDN's page on Transport Layer Security (TLS) describes it as a protocol that lets a browser talk securely to a server across an untrusted network; HTTP over TLS is HTTPS. It protects the connection in three ways:
- Encryption: data passing between the visitor and your server cannot be read by anyone in between.
- Integrity: nobody can secretly change it on the way.
- Authentication: the server proves it really is the site the visitor asked for. This is the certificate's job.
MDN adds that browsers treat HTTPS pages as a "secure context", and many modern browser features only work in one. Its advice is that all websites should serve all pages and resources over HTTPS.
What HTTPS does not do is make the site itself secure. It protects data in transit, not an outdated plugin, a weak admin password or a hacked server. Our guide to website security basics covers those.
DV, OV and EV certificates
Public certificate authorities (CAs) follow the CA/Browser Forum's Baseline Requirements, which define the certificate types by what the CA has checked:
- Domain Validated (DV): the CA has confirmed that the applicant controls the domain. The certificate names the domain and may carry a country, but no organisation name is allowed.
- Organization Validated (OV): the CA has also verified the organisation, and the certificate must include its name and location.
- Extended Validation (EV): follows a separate, stricter CA/Browser Forum standard, the EV Guidelines, for verifying the organisation.
All three give the same encryption. The difference is how much identity information the certificate carries. Let's Encrypt, for example, says in its FAQ that it issues only DV certificates, because OV and EV issuance cannot be automated. For most business websites, a DV certificate that renews automatically is the practical choice. If a bank, partner or tender asks for an OV or EV certificate, buy one from a commercial CA and plan for the manual verification and renewal.
One certificate can cover several names, such as example.com and www.example.com. A wildcard certificate (*.example.com) covers subdomains; Let's Encrypt issues those only through the DNS check described below. Make sure every address your site answers on is covered, or visitors on the missing one will see an error.
How a certificate is issued
Many hosts now issue and renew certificates for you using the ACME protocol, the system Let's Encrypt uses. Its page on how it works explains the two steps: software on the server (an ACME client) proves to the CA that it controls the domain, and then requests the certificate. No human needs to be involved.
Let's Encrypt's challenge types page describes the two common proofs:
- HTTP-01: the client puts a file at a fixed address on your website and the CA fetches it. It is the most common method, but it needs the domain to already point at the server.
- DNS-01: the client adds a TXT record to your domain's DNS. It is harder to set up, but works before the site is live and is required for wildcard certificates.
That difference matters when you change host or DNS: an HTTP-01 renewal fails if the domain no longer points where the client expects. Our guide to moving a site to a new host covers getting the certificate right on cutover day, and domain names and DNS explains the records involved.
Certificate lifetimes are getting shorter
In April 2025 the CA/Browser Forum adopted Ballot SC-081, which cuts the maximum validity of public TLS certificates in stages. Section 6.3.2 of the current Baseline Requirements sets these limits:
- Issued before 15 March 2026: up to 398 days.
- From 15 March 2026: up to 200 days.
- From 15 March 2027: up to 100 days.
- From 15 March 2029: up to 47 days.
Let's Encrypt already issues shorter certificates: its FAQ says its default certificates are valid for 90 days and recommends renewing every 60 days. Its December 2025 announcement, decreasing certificate lifetimes to 45 days, sets out its own schedule: 64-day certificates by default from 10 February 2027 and 45-day certificates from 16 February 2028. It says most users with automatic renewal will not need to change anything, but should check their automation copes with shorter lifetimes, that manual renewal is not recommended, and that monitoring should alert you if a certificate is not renewed when expected.
The practical lesson: if anyone on your team renews a certificate by hand once a year, that process will not survive these changes. Move to automatic renewal, and add an expiry check to your monitoring.
Mixed content
MDN defines mixed content as a page loaded over HTTPS that fetches images, scripts or other resources over plain HTTP. Those resources can be read or changed on the way, which undoes the protection of the page. Scripts are the most dangerous because they can change anything on the page.
MDN says browsers now automatically upgrade image, video and audio requests from HTTP to HTTPS, and block insecure requests for other resource types. So the usual symptom on an older site is not a warning but something that silently stops working: a script, a stylesheet, an embedded form or a font. The fix is to change those addresses to https:// (or to files on your own site), including old links stored in the CMS database, theme files and third-party embeds. Your browser's developer console lists the blocked requests.
HSTS: telling browsers to always use HTTPS
Redirecting HTTP to HTTPS still lets a visitor's very first request go out unencrypted. The Strict-Transport-Security header (HSTS) tells browsers to use only HTTPS for your domain from then on. MDN explains that the browser then upgrades any HTTP address for that domain before sending it, and will not let visitors click through certificate errors.
That second point is why HSTS needs care: if your certificate ever breaks, visitors cannot bypass the error. The HSTS preload site recommends checking that every subdomain works over HTTPS first, then raising the max-age in stages (5 minutes, 1 week, 1 month) while watching for broken pages. Preloading, which builds your domain into browsers, requires a max-age of at least one year plus includeSubDomains, applies to every subdomain including internal ones, and is hard to undo quickly. It is not a step to take casually.
Moving a site from HTTP to HTTPS
Google's site move guide lists a change from HTTP to HTTPS as a site move with URL changes. In practice that means a permanent (301) redirect from every HTTP address to its HTTPS version, updated internal links, canonical tags and sitemap, and a check in Search Console afterwards. Google notes you do not need its Change of Address tool for an HTTP to HTTPS move. Our guide to 404s and redirects explains the redirect types.
Checklist
- A valid certificate covering every address the site answers on, including
www. - Automatic renewal in place, and tested after any DNS or hosting change.
- Expiry monitoring that alerts someone before a certificate lapses.
- HTTP redirects to HTTPS with a 301, straight to the final address.
- No mixed content: the browser console shows no blocked HTTP requests.
- HSTS added only after every subdomain works over HTTPS, with
max-ageraised in stages. - OV or EV only where someone actually requires it, with manual renewal planned.
Frequently asked questions
Is SSL the same as TLS?
In everyday use, yes. SSL was the older protocol; today's secure connections use TLS, but certificates are still widely called SSL certificates. Either name means the certificate that lets your site use HTTPS.
Do I need to pay for a certificate?
Usually not. Let's Encrypt does not charge for its certificates, and many hosts issue them automatically. They are Domain Validated (DV) certificates; you only need a paid OV or EV certificate if someone requires the organisation's verified details in it.
How long does a certificate last?
Under the CA/Browser Forum Baseline Requirements, public certificates issued from 15 March 2026 last at most 200 days, falling to 100 days from 15 March 2027 and 47 days from 15 March 2029. Let's Encrypt's default is currently 90 days.
Does HTTPS make my website secure?
It secures the connection: encryption, integrity and proof of the server's identity. It does not protect against outdated software, weak passwords or a compromised server, which need updates, backups and access control.
Want certificates, renewals and updates handled for you? See our website maintenance service, see all our services, or email info@creahive.com.