Free SSL Certificates with Let's Encrypt: Setup, Auto-Renewal, and the Shorter Lifetimes Coming in 2027

A website without HTTPS is marked Not Secure by every major browser, cannot use HTTP/2 in browsers, and exposes logins and form data to anyone on the same network. Since Let's Encrypt launched in 2015, getting a certificate no longer costs anything, and today it issues certificates for hundreds of millions of websites. The hard part is no longer the price but the upkeep: certificate lifetimes are getting shorter across the industry, Let's Encrypt stopped sending expiry reminder emails in 2025, and a renewal that silently fails takes the whole site down. This guide covers how to set it up properly and keep it running.

What an SSL Certificate Actually Does

The name SSL has stuck, but the protocol in use today is TLS, usually version 1.2 or 1.3. A certificate does two jobs. It lets the browser and server agree on encryption keys, so nobody in between can read or modify the traffic. And it proves that the server really belongs to the domain in the address bar, because a certificate authority (CA) trusted by the browser has checked that the requester controls that domain.

Beyond security, HTTPS is now a basic requirement. Browsers block many features on plain HTTP, such as geolocation, service workers, and camera access. Payment gateways and app stores require HTTPS for callbacks and APIs. Search engines treat it as a ranking signal. And when an application handles personal data, encryption in transit is one of the most basic safeguards expected under the Personal Data Protection Law.

Free or Paid: What Is the Difference?

In terms of protecting traffic, a free DV certificate and an expensive EV certificate are equivalent. What you pay for is identity checking, a warranty, and support from the CA. A paid certificate is still sensible when a tender, a bank partner, or an internal policy explicitly asks for OV or EV, or when a support contract matters to you. It does not remove the need for automation, though: since 15 March 2026 the maximum lifetime for any public certificate is 200 days, so even paid certificates have to be replaced at least twice a year.

How Let's Encrypt Verifies Your Domain

Let's Encrypt has no web form and no human review. Everything runs through the ACME protocol: a client on your server asks for a certificate, Let's Encrypt gives it a challenge, and the client proves it controls the domain by answering it.

What Changed in 2025 and 2026

Many setup guides online were written before these changes. If your servers were configured a few years ago, check them against this list.

• No more expiry reminder emails. Let's Encrypt ended this service in June 2025. If renewal breaks, nobody will warn you unless you have your own monitoring.
• OCSP is gone. Let's Encrypt shut down its OCSP service in August 2025, and new certificates no longer contain an OCSP address. Revocation now relies on CRLs. Nginx configurations with ssl_stapling on will log a warning that can be ignored, or you can remove those lines.
• No more client authentication certificates. The TLS client authentication usage was removed from Let's Encrypt certificates in 2026. If a system used these certificates for mutual TLS between servers, it needs a private CA instead.
• Shorter lifetimes across the industry. Under a CA/Browser Forum decision, the maximum lifetime for public certificates fell to 200 days on 15 March 2026, will fall to 100 days on 15 March 2027, and to 47 days on 15 March 2029.
• Let's Encrypt is moving faster than the industry. Its default certificates will change from 90 to 64 days on 10 February 2027, and to 45 days on 16 February 2028. An opt-in profile called tlsserver has issued 45-day certificates since 13 May 2026.
• Six-day certificates and IP address certificates became generally available in January 2026, through the shortlived profile.
• New roots and intermediates. Certificates are now issued from the Generation Y hierarchy, so you may see an intermediate named YE2 or YR2 instead of the older E5 or R10. Never hard-code a specific intermediate in your configuration.
• A new DNS validation method, DNS-PERSIST-01, has been announced. It lets you place one permanent TXT record instead of updating DNS on every renewal. Check whether your ACME client and Let's Encrypt production support it before relying on it.

The common thread is simple. Any setup that depends on a person remembering to renew, or on a cron job hard-coded to renew every 60 days, will break within the next year or two.

Choosing an ACME Client

Installing Let's Encrypt with Certbot on Nginx

The example below uses Ubuntu and Nginx, which is the most common setup on the servers we manage. Before starting, make sure the domain A or AAAA record already points to the server and that ports 80 and 443 are open in the firewall and in the cloud security group.

1. 1Install Certbot. The official recommendation is the snap package: sudo snap install --classic certbot, then sudo ln -s /snap/bin/certbot /usr/bin/certbot. The apt package with python3-certbot-nginx also works but is often an older version.
2. 2Make sure Nginx already has a server block with the correct server_name, for example example.com and www.example.com, and that sudo nginx -t reports no errors.
3. 3Request the certificate: sudo certbot --nginx -d example.com -d www.example.com. Certbot verifies the domain over HTTP-01, writes ssl_certificate lines into the Nginx configuration, and can add a redirect from HTTP to HTTPS.
4. 4Test renewal without issuing a real certificate: sudo certbot renew --dry-run. This uses the staging environment, so failures do not count against production rate limits.
5. 5Check that the renewal timer is active: systemctl list-timers | grep certbot. The snap package installs a timer that runs twice a day and only renews when needed.
6. 6Open the site in a browser, then check the certificate from the terminal: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates.

The last command prints the issuer and the validity dates. On a certificate we checked this month, it showed issuer CN = YE2 from Let's Encrypt, a notAfter date 90 days after issuance, and no OCSP address in the Authority Information Access field, which matches the changes described above.

Wildcard Certificates and Servers Without Port 80

A wildcard certificate such as *.example.com covers every subdomain, which is useful for multi-tenant applications where each customer gets their own subdomain. Let's Encrypt only issues wildcards through DNS-01. Avoid the manual DNS mode in Certbot, because it requires you to add a TXT record by hand on every renewal. Use a DNS plugin instead, such as certbot-dns-cloudflare or the Route 53 plugin, or acme.sh with your DNS provider API. Give the API token permission only to edit DNS records for that one zone, and store it with file permissions that only root can read.

Recommended HTTPS Settings After Installation

• Redirect all HTTP traffic to HTTPS, but keep the /.well-known/acme-challenge/ path reachable on port 80 if you use HTTP-01.
• Allow only TLS 1.2 and TLS 1.3. Older versions have been disabled by all modern browsers.
• Use fullchain.pem, not cert.pem, for ssl_certificate. Without the intermediate certificate, browsers usually still work but Android apps, curl, and payment gateway callbacks often fail.
• Add HSTS once you are sure every subdomain works over HTTPS. Start with a short max-age, and only add includeSubDomains and preload when you are certain, because preloading is hard to undo.
• Remove ssl_stapling lines for Let's Encrypt certificates, since there is no longer an OCSP responder to staple.
• Fix mixed content: images, scripts, or API calls that still use http:// will be blocked or flagged by the browser.

Mistakes That Cause Renewal Failures

• Port 80 was closed after the first installation, or a redirect rule sends the challenge path somewhere else. HTTP-01 renewals then fail quietly.
• The certificate was renewed but Nginx was never reloaded, so the server keeps serving the old certificate until it expires. The Certbot Nginx plugin handles this, but certonly with webroot needs a deploy hook such as --deploy-hook "systemctl reload nginx".
• A CAA record on the domain allows only another CA, so Let's Encrypt refuses to issue. Add letsencrypt.org to the CAA record if you use one.
• Testing repeatedly against production and hitting rate limits. Let's Encrypt allows 5 certificates per week for exactly the same set of names, and 5 failed validations per domain per hour. Use --dry-run or the staging server while experimenting.
• A Docker container stores certificates inside the container without a volume, so every redeploy requests new certificates and eventually hits the limit.
• A cron job hard-coded to renew every 60 days, which will not work for 64-day and 45-day certificates. Let the client decide using ARI, or renew at about two thirds of the lifetime.
• Several servers behind a load balancer each requesting their own certificate for the same domain. Request it in one place, or use DNS-01, and distribute it from there.

Monitoring Is Now Your Job

With no reminder emails, an expired certificate is usually discovered by customers first. Add certificate expiry checks to whatever monitoring you already have. Uptime Kuma, Zabbix, and most uptime services can alert when a certificate is close to expiry. Set the alert threshold relative to the certificate lifetime: with 90-day certificates, an alert at 20 days left is reasonable, and with 45-day certificates around 10 days. An alert means automatic renewal has already failed at least once, so treat it as an incident, not a reminder.

A good test for any HTTPS setup: if every engineer on the team were on holiday for three months, would the certificates still renew themselves, and would someone be alerted if they did not? If the answer is no, fix that before anything else.