Home » Blog updates » Free vs Paid SSL Certificates: What Your Website Really Needs (Part 3 of 20)

Free vs Paid SSL Certificates: What Your Website Really Needs (Part 3 of 20)

March 10, 2026
Business, Maintenance, WordPress Tips

This guide explains how SSL/TLS actually works, breaks down every certificate type and when each is appropriate, and walks you through setting up HTTPS correctly – including common gotchas that trip people up even after they think they are done.

How SSL and TLS Actually Work

SSL (Secure Sockets Layer) is technically obsolete – it was replaced by TLS (Transport Layer Security) years ago. But “SSL” persists as the common term for what is actually TLS encryption. When someone visits your website over HTTPS, the following sequence happens:

The visitor’s browser connects to your server and requests a secure connection, announcing which TLS versions and cipher suites it supports.
Your server responds with its SSL/TLS certificate and its preferred cipher suite.
The browser verifies the certificate: Is it issued by a trusted Certificate Authority (CA) in the browser’s trust store? Has it expired? Does the domain in the certificate match the domain being visited?
A TLS handshake establishes the session: The browser and server agree on encryption keys using asymmetric encryption (public/private key pairs). This key exchange is computationally expensive, which is why TLS 1.3 reduced the handshake from 2 round trips to 1.
The encrypted session begins: All data exchanged between browser and server is encrypted using the session keys, making it unreadable to anyone intercepting the traffic.

The certificate itself is what establishes trust. It is issued by a Certificate Authority (CA) – an organization that browsers trust to vouch for domain ownership. When a CA issues a certificate, it signs it with its own private key. The browser can verify this signature using the CA’s public key, which is included in the browser’s built-in trust store.

Let’s Encrypt: Free SSL for the Entire Web

Let’s Encrypt launched in 2015 as a nonprofit CA backed by Mozilla, EFF, Akamai, Cisco, and others. Its mission was to make HTTPS the default for every website by removing the cost and complexity of obtaining certificates. It succeeded. Today, Let’s Encrypt issues over 3 million certificates per day and secures hundreds of millions of websites.

What Makes Let’s Encrypt Different

Free: No cost, ever. Let’s Encrypt is funded by sponsors and donations, not certificate fees.
Automated: The ACME protocol allows automatic certificate issuance and renewal without human intervention.
Domain Validated (DV): Let’s Encrypt only issues DV certificates (more on certificate types below).
90-day validity: Let’s Encrypt certificates expire after 90 days, much shorter than the 1-2 year validity of paid certificates. This is intentional – it forces automation and limits the window of exposure if a certificate’s private key is compromised.
Widely trusted: Let’s Encrypt’s root certificate is trusted by all major browsers and operating systems.

Setting Up Let’s Encrypt with Certbot

Certbot is the official ACME client for Let’s Encrypt, maintained by the EFF. Installation varies by operating system. On Ubuntu and Debian, you install Certbot along with the appropriate web server plugin (for Nginx or Apache), then run Certbot with your domain names. Certbot automatically validates domain ownership, downloads the certificate, and configures your web server to use HTTPS – including setting up HTTP-to-HTTPS redirects. The official documentation at certbot.eff.org provides step-by-step instructions for every major operating system and web server combination.

Configuring Auto-Renewal

When Certbot is installed on modern Debian/Ubuntu systems, it automatically sets up a systemd timer (or cron job) to check certificate expiry twice daily. Certbot will only actually renew a certificate when it is within 30 days of expiry – so running the check frequently does not waste resources. You can verify the auto-renewal timer is active via systemctl, and run a dry-run renewal test to confirm it would succeed without actually renewing the certificate.

For WordPress sites hosted at managed providers (Kinsta, WP Engine, Cloudways, SiteGround), Let’s Encrypt certificate issuance and renewal is typically handled automatically by the hosting panel. You do not need to touch Certbot at all.

Certificate Types: DV vs OV vs EV

SSL certificates differ in how thoroughly the Certificate Authority verified the identity of the entity requesting the certificate. This is the primary distinction between the three types.

Domain Validated (DV) Certificates

DV certificates verify only that the person requesting the certificate controls the domain. The validation is automated – the CA checks domain control either by placing a specific file on the web server (HTTP-01 challenge) or by creating a specific DNS TXT record (DNS-01 challenge). No identity verification happens. Let’s Encrypt issues only DV certificates. Most paid CAs (DigiCert, Sectigo, Comodo, etc.) also sell DV certificates.

DV certificates are appropriate for: blogs, portfolios, informational sites, SaaS apps, APIs, and any site where the primary goal is encrypted data transmission. They display the padlock icon in the browser address bar. The vast majority of websites on the internet use DV certificates – including most major tech companies.

Organization Validated (OV) Certificates

OV certificates require the CA to verify the legal existence and identity of the organization requesting the certificate. The CA checks against public business registries, may contact the organization directly, and validates that the person requesting the certificate is authorized to act on behalf of the organization. Issuance takes 1-3 business days. OV certificates contain the verified organization name in the certificate details.

The practical impact for website visitors is minimal – OV and DV certificates both display the same padlock icon. To see the organization name, a visitor would need to click on the certificate details in their browser. OV certificates cost $50-200/year from paid CAs. For most businesses, OV offers minimal additional trust signal to end users compared to DV, and Let’s Encrypt’s free DV certificates are a perfectly reasonable alternative.

Extended Validation (EV) Certificates

EV certificates require the most rigorous validation – legal existence, operational existence, physical address, authorization of the requester, and more. EV certificates were originally distinguished by a green address bar displaying the organization name prominently. Major browsers (Chrome, Firefox) removed the green EV indicator between 2019 and 2020, finding in user studies that it was not understood by most users and did not improve security decisions.

Without the visible browser indicator, the case for EV certificates has weakened significantly. The certificate details still show the verified organization name for users who inspect them, but most users never do. EV certificates cost $100-300+/year and require 3-7 days for issuance. They still make sense for highly regulated industries (banking, healthcare, government) where compliance requirements specifically call for EV, or for organizations that want the rigorous identity verification process for internal governance reasons.

Type	Validation	Issuance Time	Cost	Browser Indicator	Best For
DV	Domain control only	Minutes	Free (Let’s Encrypt)	Padlock	Most websites
OV	Domain + organization identity	1-3 days	$50-200/yr	Padlock (same as DV)	Some business/enterprise sites
EV	Full extended validation	3-7 days	$100-300+/yr	Padlock (green bar removed in 2019)	Regulated industries, compliance requirements

Wildcard SSL Certificates

A wildcard certificate covers a domain and all its first-level subdomains. For example, a wildcard certificate for *.yourdomain.com would be valid for blog.yourdomain.com, shop.yourdomain.com, api.yourdomain.com, and any other subdomain – but not for two levels of subdomain (*.blog.yourdomain.com would need its own wildcard).

Let’s Encrypt issues free wildcard certificates, but they require DNS-01 validation (adding a specific TXT record to your DNS) rather than HTTP-01 validation. This is because proving you control a wildcard domain requires proving you control the entire domain’s DNS. Certbot supports DNS-01 with plugins for most major DNS providers (Cloudflare, Route 53, Namecheap, etc.).

For a site with multiple subdomains, a wildcard certificate is significantly simpler to manage than individual certificates for each subdomain. The cert is issued once, renewed once, and covers everything automatically as you add new subdomains.

Multi-Domain (SAN) Certificates

A SAN (Subject Alternative Name) certificate, also called a multi-domain certificate, includes multiple domain names in a single certificate. For example, one certificate might cover yourdomain.com, yourotherdomain.com, and shop.yourdomain.com simultaneously.

Let’s Encrypt allows up to 100 domain names on a single certificate. When using Certbot, you can list multiple domains in a single command using multiple -d flags. This is useful if you are managing multiple related domains on the same server and want a single certificate to manage rather than several independent ones.

HSTS: Forcing HTTPS at the Browser Level

HTTPS redirects (HTTP to HTTPS) work by sending a 301 or 302 redirect response when someone visits the HTTP version of your URL. But there is a window of vulnerability: the initial HTTP request is made over an unencrypted connection before the redirect happens. An attacker on the network could intercept that initial request.

HSTS (HTTP Strict Transport Security) solves this by telling browsers: “Only ever connect to this site over HTTPS, even if the user types http:// or clicks an http:// link.” Once a browser receives the HSTS header, it automatically upgrades all future requests to HTTPS before they even leave the browser – no HTTP request is ever sent to the server.

The HSTS response header looks like this: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age=31536000: The browser will remember this HSTS policy for 1 year (31,536,000 seconds).
includeSubDomains: The policy applies to all subdomains as well.
preload: Indicates you want your domain included in browsers’ HSTS preload lists (see below).

HSTS Preloading

The HSTS preload list is a hardcoded list of domains that browsers ship with, ensuring HTTPS is enforced from the very first visit – even before the browser has ever received an HSTS header from your site. To be included, submit your domain at hstspreload.org. Requirements: HTTPS must be working correctly, you must serve the HSTS header with the preload directive, and the policy must cover all subdomains. Once preloaded, removing a domain from the list takes months to propagate to all browser versions. Only preload if you are fully committed to HTTPS on all subdomains indefinitely.

Mixed Content: The Most Common HTTPS Problem

Mixed content happens when an HTTPS page loads resources (images, scripts, stylesheets, iframes) over HTTP. Browsers block most mixed content (active mixed content like scripts) and warn about others (passive mixed content like images). Both scenarios are bad: blocked resources break your site’s functionality, and warnings create security indicators that undermine user trust.

Finding Mixed Content

Open Chrome DevTools (F12) and look at the Console tab for mixed content warnings after loading your page.
Use the Why No Padlock tool (whynopadlock.com) – it crawls your page and lists all HTTP resources.
Search your database for hard-coded http:// URLs: in WordPress, search wp_posts and wp_options for your domain prefixed with http://.

Fixing Mixed Content in WordPress

The most reliable way to fix mixed content in WordPress is using WP-CLI’s database search-and-replace functionality via SSH. You tell it to find every instance of your http:// URL and replace it with the https:// version, while skipping the guid column (which WordPress uses internally for post identification and should not be changed). After running the replacement, regenerate your theme files and flush caches. If you use Cloudflare, the “Automatic HTTPS Rewrites” feature can catch remaining mixed content by rewriting HTTP resource URLs to HTTPS before they reach the browser – a useful safety net even after doing the database replacement.

SSL for Subdomains

Each subdomain needs its own certificate coverage – a certificate for yourdomain.com does not cover blog.yourdomain.com. Your options are:

Individual DV certificates: Issue a separate Let’s Encrypt certificate for each subdomain. Works fine for a small, fixed number of subdomains.
Wildcard certificate: Issue *.yourdomain.com to cover all first-level subdomains. Best choice if you have many subdomains or create them dynamically.
SAN certificate: List specific subdomains in a single certificate. Useful when the subdomains are distinct domains rather than subdomains of the same root.

SSL Monitoring Tools

Certificate expiry is the most common SSL problem for sites not using automated renewal. Even with auto-renewal configured, monitoring for expiry adds a safety net – misconfigured cron jobs or ACME validation failures can cause renewal to silently fail.

SSL Labs SSL Test (ssllabs.com/ssltest): The gold standard for SSL configuration analysis. Gives you a letter grade (A+ to F) and detailed breakdown of your TLS configuration, cipher suites, protocol support, and common misconfigurations.
UptimeRobot SSL Monitoring: Free plan includes SSL certificate expiry monitoring with email alerts. Sends a notification when your certificate is less than 30 days from expiry.
Let’s Encrypt expiry emails: Let’s Encrypt automatically sends reminder emails to the address you provided when the certificate was issued, starting 20 days before expiry.
Certbot dry-run renewal: Run a renewal dry-run periodically to verify auto-renewal would succeed. Good to do after any server configuration changes.
crt.sh: Certificate Transparency log search. Shows all certificates issued for your domain. Useful for detecting unauthorized certificate issuance.

Certificate Transparency Logs

Certificate Transparency (CT) is a public audit system for SSL certificates. Every CA that wants its certificates trusted by Chrome must submit issued certificates to publicly auditable CT logs. This means that every SSL certificate issued for your domain is publicly visible within hours of issuance.

This matters for security monitoring. If an attacker somehow convinces a CA to issue a fraudulent certificate for your domain (a real threat historically – several CAs have been compromised), you can detect it by monitoring CT logs. Tools like Facebook’s Certificate Transparency Monitoring (developers.facebook.com/tools/ct/) and crt.sh allow you to search and set up alerts for certificate issuances on your domain.

Cost Comparison: Free vs Paid SSL

Certificate Option	Annual Cost	Issuance Time	Renewal	Type	Best For
Let’s Encrypt (via Certbot)	Free	Minutes	Automatic (90-day)	DV	Most websites
Let’s Encrypt (via hosting panel)	Free	Minutes	Automatic	DV	Managed hosting users
Cloudflare SSL	Free	Minutes	Automatic	DV (shared) or dedicated	Sites using Cloudflare
Sectigo (formerly Comodo) DV	~$8-15/yr	Minutes	Manual (1-year)	DV	Rarely needed
DigiCert DV	~$150/yr	Minutes	Manual	DV	Enterprise with DigiCert contract
Sectigo OV	~$50-100/yr	1-3 days	Manual	OV	Businesses wanting org validation
DigiCert EV	~$300-500/yr	3-7 days	Manual	EV	Regulated industries
Comodo Wildcard	~$100-150/yr	Minutes	Manual	DV wildcard	Multiple subdomains (paid option)
Let’s Encrypt Wildcard	Free	Minutes	Automatic	DV wildcard	Multiple subdomains (free option)

For the overwhelming majority of websites, a free Let’s Encrypt DV certificate is cryptographically identical to a $300 paid DV certificate from a major CA. The difference is identity validation, not encryption strength.

Step-by-Step HTTPS Migration Checklist

Migrating from HTTP to HTTPS is a one-time process with several steps. Here is the complete checklist:

Back up your site before making any changes.
Install SSL certificate via your hosting panel (for managed hosts) or via Certbot (for VPS). Verify the certificate covers your domain and any www variant.
Update WordPress Site URL and Home URL to use https:// in Settings > General, or via WP-CLI via SSH if you have command-line access.
Run database search-and-replace to update hard-coded HTTP URLs throughout your database. Use WP-CLI’s search-replace command via SSH or a plugin like Better Search Replace if you do not have command-line access.
Configure HTTP-to-HTTPS redirects in your web server config (Nginx) or .htaccess (Apache). Or use Cloudflare’s Automatic HTTPS Rewrites if you are on Cloudflare.
Update your CDN to use HTTPS for the origin connection.
Check for mixed content using the Why No Padlock tool and Chrome DevTools console.
Fix any mixed content found – update hardcoded URLs in your theme, plugin settings, and database.
Add HSTS header to your web server configuration after verifying HTTPS is fully working.
Update Google Search Console – add the https:// version of your site as a new property, and set it as preferred.
Update Google Analytics property settings to use https:// as the default URL.
Update all social profiles, directory listings, and external links pointing to your old http:// URLs.
Check email links and newsletter templates for http:// links to your domain.
Verify SSL Labs grade at ssllabs.com/ssltest – aim for at least an A rating.
Monitor for 301 redirect chains that might have formed. HTTP to HTTPS to www (or non-www) should be a single redirect, not a chain of two.

Common SSL Mistakes

Mistake	Symptom	Fix
Certificate expired	“Your connection is not private” warning	Set up auto-renewal with Certbot or hosting panel
Mixed content	Padlock missing or warning; resources blocked	DB search-replace + Cloudflare Automatic HTTPS Rewrites
Wrong domain on certificate	Certificate name mismatch error	Issue new certificate covering the exact domain being requested
No www redirect consistency	Duplicate content, split link equity	Pick www or non-www, redirect the other 301 to it
HTTP to HTTPS redirect chain	Extra 301 redirect wastes load time	Single redirect: http://www to https://www in one step
HSTS too short	HSTS not enforced on return visits	Set max-age to at least 31536000 (one year)
Skipping DNSSEC	DNS spoofing possible	Enable DNSSEC at registrar and DNS provider
Paying for DV cert unnecessarily	Unnecessary cost	Use Let’s Encrypt unless OV/EV is specifically required

Series Navigation – Website Owner’s Toolkit

This post is part of the Website Owner’s Toolkit – a 21-part series covering every essential service and skill you need to run a professional website. View the full series index here.

Varun Dubey

Varun Dubey is a full-stack WordPress developer with a passion for diverse web development projects. As a BuddyPress Core developer, he continuously seeks to enhance his skills and stay current with the latest technologies in the modern tech world. Connect with him on Twitter @vapvarun.