What Is an SSL Certificate? Free vs Paid Explained

SSL and TLS Explained

SSL (Secure Sockets Layer) was developed in the 1990s to encrypt web communications. The modern version is TLS (Transport Layer Security), but the industry still calls it SSL. The protocol creates an encrypted connection so data between your site and visitors cannot be read or tampered with.

During the SSL handshake, the browser verifies your server's certificate, then establishes an encrypted session using symmetric keys. Without SSL, data travels in plain text and anyone on the same network could intercept it.

Types of SSL Certificates

• Domain Validated (DV): The most common type, verifying domain ownership only. Free through Let's Encrypt and included with BearHost hosting. Ideal for blogs, personal sites, and small businesses.
• Organisation Validated (OV): Requires business identity verification taking one to three days. Displays your organisation name in certificate details for extra trust.
• Extended Validation (EV): The most rigorous verification including legal entity checks. Used by banks, large e-commerce sites, and organisations handling highly sensitive data.

Free vs Paid SSL Certificates

Free SSL from Let's Encrypt provides identical encryption strength to paid certificates. BearHost automatically installs and renews free Let's Encrypt SSL on all hosting accounts. For most websites, a free DV certificate is sufficient.

Paid certificates are needed only for OV and EV validation, which require manual verification. Some also include warranty coverage if the certificate fails and causes a breach. Only pursue paid options if compliance or customer confidence specifically requires enhanced validation.

SEO and Browser Trust Benefits

Google confirmed HTTPS as a ranking signal in 2014 and its importance has grown since. Visitors are more likely to stay on secure sites, reducing bounce rates and improving engagement. These positive signals reinforce search rankings.

Websites without SSL receive "Not Secure" warnings in Chrome, Firefox, Safari, and Edge. These warnings damage trust and cause users to leave immediately. For e-commerce, a missing SSL certificate can single-handedly kill online sales.

Installing SSL on Your Website

With BearHost, SSL installation is completely automatic. When you add a domain, a free Let's Encrypt certificate is generated, installed, and configured without any action required — Knowledge Base Wordpress How To Install Free Ssl Certificate walks through it in screenshots. Certificates renew automatically every 90 days.

After installing SSL, redirect all HTTP traffic to HTTPS using 301 redirects. Update your sitemap, internal links, and hardcoded URLs. For WordPress sites, plugins like Really Simple SSL handle this automatically.

TLS 1.3 vs TLS 1.2: Why the Handshake Matters

RFC 8446 defines TLS 1.3, published in August 2018, and it is the first TLS version designed with modern cryptanalysis in mind. The handshake is a single round-trip compared to TLS 1.2's two round-trips, which shaves roughly 60 to 100 milliseconds off every new HTTPS connection depending on latency. For mobile visitors on 4G, that is visible to the naked eye on a page with a dozen third-party origins.

TLS 1.3 removes every cipher suite that does not provide authenticated encryption with associated data (AEAD). That means CBC mode, RC4, 3DES, MD5, and SHA-1 are gone entirely. The surviving suites are TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, and TLS_CHACHA20_POLY1305_SHA256, all of which are safe against BEAST, Lucky13, and SWEET32-class attacks that haunted TLS 1.2.

0-RTT resumption is the controversial new feature. It lets returning clients send data on the very first packet, saving another round-trip, but that data is replayable. Use it only for idempotent GET requests, never for state-changing POSTs. Nginx exposes this as `ssl_early_data on;` and you should leave it off unless you have audited your application for replay safety.

HSTS, Preload Lists, and includeSubDomains

Installing a certificate is only half the job. Without HSTS (HTTP Strict Transport Security), a visitor typing yourdomain.com for the first time hits HTTP, gets a 301 to HTTPS, and in that tiny window is vulnerable to SSL stripping on a hostile network. The fix is the `Strict-Transport-Security` response header.

A cautious rollout uses `max-age=300` for a week to verify nothing breaks, then ramps to `max-age=31536000; includeSubDomains` (one year). Only add `preload` once you are certain every subdomain, including internal staging and intranet services, serves valid HTTPS, because submitting to hstspreload.org is a one-way door and removal takes months.

The `includeSubDomains` directive is the one people forget. Without it, an attacker can still intercept http://api.yourdomain.com even if the root domain is preloaded. If you host APIs, admin panels, or internal tools on subdomains, verify every single one serves valid HTTPS before enabling subdomain inclusion.

Wildcard, SAN, and Multi-Domain Certificates

A standard DV certificate covers exactly one hostname, for example yourdomain.com plus www.yourdomain.com as a SAN. A wildcard certificate covers *.yourdomain.com, so api.yourdomain.com and shop.yourdomain.com are both valid. Wildcards are convenient when you provision new subdomains dynamically, for example per-customer tenant subdomains on a SaaS product.

Wildcards cannot be issued using the HTTP-01 challenge because Let's Encrypt needs to prove you control the entire zone, not just a single hostname. You must use DNS-01, which requires placing a TXT record at _acme-challenge.yourdomain.com. This is trivial if your DNS provider has an API; acme.sh and Certbot both ship plugins for Cloudflare, Route 53, and most major registrars. Our guide on Free SSL Certificates has the commands for the common cases.

A SAN (Subject Alternative Name) or multi-domain certificate is different again. It covers a fixed list of distinct hostnames, such as brand.com plus brand.co.uk plus brand.de. Use these when you run separate domains for localisation rather than subdomains. Let's Encrypt allows up to 100 SAN entries per certificate.

Certificate Transparency Logs and Monitoring for Misissuance

Since 2018, Chrome has required every publicly trusted certificate to appear in at least two Certificate Transparency logs before it is accepted. These logs are append-only, publicly auditable, and act as a tripwire when a CA issues a certificate for your domain without authorisation. This has caught real incidents at DigiNotar, Symantec, and more recently a handful of smaller CAs.

crt.sh is the easiest free service for monitoring. Search for `%.yourdomain.com` and you will see every certificate ever issued for your apex or subdomains. For automated alerts, services like Cert Spotter (free for the first five domains) or Facebook's CT monitor email you whenever a new certificate appears, so you can revoke anything unexpected immediately.

Pair CT monitoring with a CAA record in your DNS: `yourdomain.com. IN CAA 0 issue "letsencrypt.org"` tells the world that only Let's Encrypt is authorised to issue for you. Any compliant CA will refuse issuance requests that violate this. Combined with CT monitoring, you get a robust early warning system against certificate hijacking, which is exactly the kind of thing attackers do after a successful domain-takeover.

OCSP Stapling, Revocation, and the Move to Short-Lived Certificates

When a certificate is compromised, the CA publishes a revocation notice. Browsers historically checked this via OCSP (Online Certificate Status Protocol), but an OCSP request sent from the client leaks the visitor's browsing history to the CA and adds a round-trip on first visit. The industry fix is OCSP stapling, where your web server fetches the OCSP response itself and includes it ("staples" it) in the TLS handshake.

Enabling stapling in Nginx is three lines: `ssl_stapling on;`, `ssl_stapling_verify on;`, and a `resolver 1.1.1.1 1.0.0.1 valid=300s;` so the server can look up the CA's OCSP responder. Apache uses `SSLUseStapling on` and `SSLStaplingCache`. BearHost shared servers staple by default, so customers on BearHost Shared Hosting get this without configuration.

The longer-term trend is even more aggressive: certificate lifetimes are shrinking. The CA/Browser Forum voted in April 2025 to phase lifetimes down from the current 398 days to 200 days by 2026, 100 days by 2027, and 47 days by 2029. Certificates valid for only a few weeks make revocation almost irrelevant because a stolen key becomes useless quickly. ACME clients like Certbot and acme.sh on a weekly cron already cope with this, so anyone using Let's Encrypt or ZeroSSL is future-proof.

Mixed Content, Cipher Suite Configuration, and Real-World Testing

A common mistake after enabling HTTPS is mixed content: the page loads over HTTPS but embeds images, scripts, or iframes over plain HTTP. Modern browsers block mixed active content (scripts, iframes) outright and display warnings on mixed passive content (images). Search for `http://` in your database with `wp cli search-replace "http://yourdomain.com" "https://yourdomain.com"` for WordPress, and use a Content Security Policy header with `upgrade-insecure-requests` to catch anything you missed.

Cipher suite configuration is where old SSL guides go badly wrong. The correct reference in 2026 is Mozilla's SSL Configuration Generator at ssl-config.mozilla.org, which publishes "modern", "intermediate", and "old" profiles updated regularly. The "intermediate" profile supports every browser from Firefox 27 onward, covers both TLS 1.2 and 1.3, and disables every cipher with known weaknesses.

Test your deployment with SSL Labs at ssllabs.com/ssltest. Aim for A or A+ grade; anything lower usually indicates a missing HSTS header, a misordered chain, or a legacy cipher that should have been disabled. Once you have A+, add the testssl.sh CLI tool to your CI pipeline so future configuration changes that break TLS are caught before deployment. Our Blogs Ssl Certificates Https Web Hosting Security post goes deeper on the ongoing operational side of running HTTPS at scale.

One final gotcha: certificate chain order matters. A server that sends its leaf certificate without the intermediate CA will work in Chrome (which caches intermediates) but fail in curl, Java, and some mobile clients. Always test with `openssl s_client -connect yourdomain.com:443 -servername yourdomain.com` from a clean machine and confirm every certificate in the chain is present.

Post-Quantum Cryptography: What Is Coming in 2026 and Beyond

Quantum computers large enough to break today's RSA and ECDSA keys do not exist yet, but the threat model called "harvest now, decrypt later" is already real. Adversaries are recording encrypted traffic today on the bet that they will be able to decrypt it in 10 to 20 years. The defence is hybrid post-quantum key exchange, and it is already shipping.

Chrome enabled the X25519MLKEM768 hybrid key exchange by default in April 2024, combining the classical X25519 elliptic-curve exchange with ML-KEM (formerly Kyber), which is a NIST-standardised post-quantum KEM published as FIPS 203 in August 2024. Firefox added support in version 124. On the server side, Cloudflare, Google, and AWS all announced support during 2024, and OpenSSL 3.5 shipped the algorithm in production form in April 2025.

For site owners running BearHost VPS Hosting , the practical implication is that you should keep OpenSSL, Nginx, and your TLS library fully up to date, because post-quantum algorithms require current versions. Certificate signature algorithms (the part attackers cannot record and decrypt later) will move to post-quantum later, probably during 2027 to 2028 as the NIST FIPS 204 ML-DSA standard matures. BearHost shared servers track upstream OpenSSL closely so customers get hybrid key exchange automatically as soon as the wider TLS ecosystem stabilises.