Home / Blog / Security and Reliability / SSL Certificates and HTTPS Explained

Security and Reliability

SSL Certificates and HTTPS Explained

Every modern website should load over HTTPS. Browsers warn visitors away from plain HTTP sites, search engines treat HTTPS as a ranking signal, and any page that handles logins, payments, or personal data needs encryption. Yet the terminology — SSL, TLS, DV, OV, EV, wildcard, SAN — confuses even experienced site owners.

This guide explains what actually happens when a browser connects over HTTPS, which certificate type fits which site, and how to avoid the renewal and configuration mistakes that take sites offline.

SSL vs TLS: the name is old, the protocol is not

SSL (Secure Sockets Layer) is the original protocol from the 1990s. It has been replaced by TLS (Transport Layer Security), and the old SSL versions are insecure and should not be used. The industry still says “SSL certificate” out of habit, but what you are actually buying or installing is a TLS certificate. When a host or a guide says “SSL”, read it as “TLS” unless it specifically means an obsolete SSL version — in which case, walk away.

What happens when a visitor opens your site

The TLS handshake, simplified:

  1. The browser connects and says which TLS versions and encryption methods it supports.
  2. The server replies with its certificate, which contains the site’s public key and the domain names it covers.
  3. The browser validates the certificate: was it issued by a certificate authority (CA) the browser trusts? Is it within its validity dates? Does it match the domain being visited?
  4. The two sides agree on session keys, and all further traffic is encrypted.

If any check fails — expired certificate, wrong domain, untrusted issuer — the browser shows a warning and most visitors leave. Encryption also provides authentication (you are talking to the server named on the certificate, not an impostor) and integrity (the data cannot be altered in transit without detection).

Certificate types: validation levels

Certificates differ mainly in how much the CA checks before issuing:

Type What is verified Issuance time Best for
DV — Domain Validation Control of the domain only Minutes Most websites, blogs, small business sites, APIs
OV — Organization Validation Domain control plus the organisation’s identity 1–3 business days Business sites where verified identity matters
EV — Extended Validation Strictest checks on the legal entity 1–2 weeks Banks, large e-commerce, regulated sectors

A DV certificate provides the same encryption as an OV or EV certificate. The difference is identity assurance, not cryptographic strength. For the vast majority of websites, DV is the right choice. OV and EV matter when a compliance framework, a contract, or a customer explicitly requires verified organisational identity — or when the certificate’s warranty and support terms are part of the requirement.

One historical note: browsers no longer display the green organisation name bar for EV certificates, as they did years ago. The visual distinction that once justified EV for many buyers has largely disappeared.

Certificate types: domain coverage

  • Single-domain: covers one exact hostname, for example example.com (often including www.example.com as well, depending on the issuer).
  • Wildcard: covers a domain and all of its first-level subdomains, for example *.example.com covering blog.example.com and shop.example.com. Useful when you run many subdomains.
  • Multi-domain (SAN): covers a list of specific, unrelated domain names on one certificate.

Check the certificate’s coverage before you buy or install: a certificate for example.com that does not include www.example.com will produce a warning for visitors who type the www address.

Let’s Encrypt and free certificates

Let’s Encrypt is a non-profit certificate authority that issues DV certificates free of charge. Its certificates are trusted by all major browsers and provide the same encryption as a paid DV certificate. They are valid for 90 days and are designed to be renewed automatically — the short lifetime is deliberate, encouraging automation rather than manual renewal.

Most managed hosting providers now include Let’s Encrypt certificates with automatic renewal. If your hosting includes it, you should rarely need to buy a certificate at all. Paid certificates become worth considering when you need OV or EV validation, a warranty above the free tier, a long validity period for a system that cannot automate renewal, or a CA management portal for dozens of certificates. [TO BE CONFIRMED: whether Offshore Hosting includes free SSL certificates and automatic renewal on its plans — confirm before publishing any such claim.]

How to get HTTPS working

The usual sequence on shared or managed hosting:

  1. Point the domain’s DNS at the hosting server and wait for propagation.
  2. Issue or enable the certificate in the hosting panel (often a one-click “SSL” or “Let’s Encrypt” option). The CA verifies domain control, usually by checking a file on the server or a DNS record.
  3. Confirm the site loads on https:// with no browser warning.
  4. Force HTTPS with a redirect, so visitors who type http:// are sent to the secure version. In Apache this is typically a rule in .htaccess; in Nginx, a server block redirect.
  5. Fix mixed content: any image, script, or stylesheet still loaded over http:// will trigger a browser warning or be blocked. Update internal links and media URLs to HTTPS or to protocol-relative paths.

On a VPS or dedicated server you manage yourself, the same steps apply, but you will typically use a client such as Certbot to obtain and renew the certificate, and configure the web server yourself. Automate renewal from the start — a certificate that expires because someone forgot is one of the most common and most avoidable outages.

Common errors and what they mean

  • “Your connection is not private” / NET::ERR_CERT_DATE_INVALID: the certificate has expired, or the computer’s clock is wrong. Renew the certificate and check the expiry date.
  • NET::ERR_CERT_COMMON_NAME_INVALID: the certificate does not cover the domain being visited — for example, it covers example.com but the visitor opened www.example.com, or it covers a different domain entirely.
  • NET::ERR_CERT_AUTHORITY_INVALID: the certificate was issued by an authority the browser does not trust — often a self-signed certificate, or a missing intermediate certificate in the chain.
  • Mixed content warning: the page loads over HTTPS but pulls some resource over HTTP. Find the insecure URL in the browser’s developer console and fix it.
  • Certificate valid but site still on HTTP: the redirect to HTTPS is missing. Add it, and update any hardcoded http:// links.

A quick check you can run yourself from a terminal:

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -subject

That prints the certificate’s validity dates and the domain it was issued for. Replace example.com with your own domain. It is a read-only check and changes nothing.

Renewal: the part that breaks sites

Let’s Encrypt certificates last 90 days; paid certificates typically last up to a year. Either way, expiry is a scheduled event, not a surprise — if you monitor it. Put these in place:

  • Automatic renewal wherever the hosting or the ACME client supports it, and verify it actually runs — an automation that silently fails is worse than no automation, because nobody is watching.
  • An expiry monitor, whether a built-in hosting alert or an external uptime monitor that checks certificate expiry, set to warn at least 14 days ahead.
  • A calendar note for paid certificates, with the renewal date and the account the certificate was bought under.

If a certificate expires, the fix is to renew and reinstall it — there is no grace period in browsers. Visitors will see a full-page warning until it is fixed.

What HTTPS does not do

HTTPS encrypts traffic between the visitor and your server. It does not make your site secure on its own: it does not patch vulnerable software, stop malware, prevent phishing (attackers can get certificates too), or protect data stored on the server. It is one layer — necessary, but not sufficient. Pair it with the rest of the launch discipline in our website launch checklist and with email authentication in how to set up SPF, DKIM, and DMARC.

Key takeaways

  • “SSL certificate” means a TLS certificate in practice; old SSL versions are insecure and unused.
  • DV, OV, and EV differ in identity checks, not encryption strength — DV is right for most sites.
  • Let’s Encrypt DV certificates are free, trusted, and valid for 90 days with automatic renewal.
  • Always force HTTPS, fix mixed content, and check the certificate covers every hostname visitors use.
  • Monitor expiry and verify automatic renewal works — an expired certificate takes the site down for every visitor.

Sources

  • Let’s Encrypt, “FAQ” — https://letsencrypt.org/docs/faq/
  • DreamHost, “Free SSL/TLS Certificates — Let’s Encrypt” — https://www.dreamhost.com/blog/2015/12/03/lets-encrypt-and-dreamhost/
  • Oderland, “What Types of Certificates Are There and Which One Should I Use?” — https://www.oderland.se/support/en/artikel/what-types-of-certificates-are-there-and-which-one-should-i-use/
  • 301Check, “SSL Certificate Guide — HTTPS, TLS, Certificate Types Explained” — https://301Check.com/en/guides/ssl-checker.html

Sources

  • {‘title’: "Let’s Encrypt — FAQ", ‘url’: ‘https://letsencrypt.org/docs/faq/’}
  • {‘title’: "Free SSL/TLS Certificates — Let’s Encrypt", ‘url’: ‘https://www.dreamhost.com/blog/2015/12/03/lets-encrypt-and-dreamhost/’}
  • {‘title’: ‘What Types of Certificates Are There and Which One Should I Use?’, ‘url’: ‘https://www.oderland.se/support/en/artikel/what-types-of-certificates-are-there-and-which-one-should-i-use/’}
  • {‘title’: ‘SSL Certificate Guide — HTTPS, TLS, Certificate Types Explained’, ‘url’: ‘https://301Check.com/en/guides/ssl-checker.html’}

← All guides · Knowledge Base

Related guides