How to Get an SSL Certificate: Free Let's Encrypt to Paid Options

An SSL certificate (technically TLS) is no longer optional. Without HTTPS, Chrome flags your site as "Not secure", Google ranks you lower, and you cannot use HTTP/2 or HTTP/3. The good news: most sites can get a certificate for free in about ten minutes. With Let's Encrypt and certbot, a single command handles issuance, web-server configuration, and automatic renewal.

This guide walks through the DV/OV/EV tiers, the exact certbot commands, the common reasons issuance fails (CAA records, picking the wrong validation method), and what to verify afterwards. Once installed, always confirm the chain and expiry with an SSL Certificate Checker.

DV vs OV vs EV — DV Is Enough for Almost Everyone

Certificates come in three tiers based on what the CA verified, not how strong the encryption is — the cryptography is identical across all three. The only differences are the vetting process and the organization details embedded in the certificate.

• DV (Domain Validation)— proves you control the domain, nothing more. Fully automated, issued in minutes. This is what Let's Encrypt gives you, and it is perfectly adequate for blogs, stores, APIs, and internal services.
• OV (Organization Validation) — the CA also verifies your legal entity, and the company name appears in the certificate details. Manual review takes 1–3 days and costs money.
• EV (Extended Validation) — the strictest vetting. Browsers used to show the company name in a green address bar, but Chrome and Firefox removed that UI years ago, so the visible benefit is gone and adoption has collapsed.

Paid OV/EV certificates still make sense in a few situations: compliance or audit requirements that explicitly demand organization-validated certificates (common in finance and insurance), contracts that require a CA warranty, or air-gapped appliances where automated renewal is impossible and you need a one-year certificate installed by hand. Everyone else should start with free DV.

How Issuance Actually Works — Key Pair, CSR, Domain Validation

certbot hides all of this, but knowing the three steps makes troubleshooting instant when something breaks.

1. Generate a key pair — a private key and public key are created on your server. The private key must never leave it.
2. Submit a CSR (Certificate Signing Request) — a request containing your public key, domain names (CN/SAN), and organization info goes to the CA. If you are buying a paid certificate and generated the CSR yourself, paste it into a CSR Decoder before submitting — forgetting the www variant in the SAN list is one of the most common and expensive mistakes.
3. Domain validation — the CA verifies you actually control the domain, using one of the two standard challenge types below.

One more gotcha: if the domain has a CAA record, only the CAs listed there may issue certificates for it. A domain carrying only CAA 0 issue "digicert.com" will make Let's Encrypt fail with a CAA record prevents issuance error. If issuance fails for no obvious reason, run a CAA Record Check first and, if needed, add issue "letsencrypt.org". No CAA record at all means any CA may issue — that is fine.

Worked Example: nginx from Zero to HTTPS (Let's Encrypt + certbot)

Here is the complete path for example.comon Ubuntu with nginx. Two prerequisites: the domain's A record must point at this server, and ports 80 and 443 must be open in the firewall.

1. Install certbot
   sudo apt update && sudo apt install certbot python3-certbot-nginx
2. Issue and auto-configure nginx
   sudo certbot --nginx -d example.com -d www.example.com
   After you enter an email and accept the terms, certbot passes the HTTP-01 challenge and writes the ssl_certificate / ssl_certificate_keypaths into your nginx config. When it offers an HTTP → HTTPS redirect, choose "2: Redirect".
3. Verify the result — files live in /etc/letsencrypt/live/example.com/ (fullchain.pem = certificate + intermediates, privkey.pem = private key). Load the site, confirm the padlock, then run an SSL Certificate Checker to confirm the chain completes leaf → intermediate → root and the expiry is roughly 90 days out.
4. Rehearse renewal — Let's Encrypt certificates are valid for 90 days; certbot installs a systemd timer (or cron job) that renews them 30 days before expiry. Always dry-run it once:
   sudo certbot renew --dry-run
   If you see "Congratulations, all simulated renewals succeeded", you are done — no further maintenance needed.

Need a wildcard? Use DNS-01: sudo certbot certonly --manual --preferred-challenges dns -d "*.example.com" -d example.com. The manual flow requires re-publishing a TXT record on every renewal, so for production use a certbot DNS plugin (cloudflare, route53, etc.) that automates the record updates.

Post-Install Checklist

• Run an SSL Certificate Checker to confirm the intermediate chain is served — installing only the leaf certificate causes failures that appear only on mobile devices and API clients. Always point nginx at fullchain.pem.
• Confirm both the apex domain and www are in the SAN list — covering only one produces ERR_CERT_COMMON_NAME_INVALID on the other.
• Check that HTTP 301-redirects to HTTPS and that no page still loads http:// resources (mixed content).
• Verify certbot renew --dry-run succeeds and certbot.timer shows up in systemctl list-timers. Roughly 90% of expiry outages come from missing renewal automation, not from the certificate itself.