Installing and Renewing a Free SSL Certificate with Let’s Encrypt

Every site should be running on HTTPS by now, and there is no excuse not to: Let’s Encrypt gives out free, browser-trusted SSL/TLS certificates to anyone who can prove they control a domain. This guide covers what Let’s Encrypt actually does, how to get your first certificate with certbot, and how to make sure renewal happens automatically so you never end up with an expired certificate taking your site down. If you’d rather not manage certbot and renewal yourself, aoitcloud’s SSL Certificates are installed and renewed for you automatically.

What Let’s Encrypt Actually Is

Let’s Encrypt is a nonprofit certificate authority (CA) run by the Internet Security Research Group. It issues domain-validated (DV) SSL/TLS certificates at no cost, using an automated protocol rather than a manual application process. That automation is the whole point: it removed the cost and friction that used to stop a lot of small sites bothering with HTTPS at all.

A Let’s Encrypt certificate proves one thing only: that whoever requested it controls the domain named on it. It doesn’t validate your organisation or your identity the way an Extended Validation (EV) certificate does. For the vast majority of websites, that’s exactly the right level of assurance, and it’s the same domain validation model used by most paid certificates too.

How the ACME Protocol Works, in Plain Terms

Let’s Encrypt issues certificates through ACME (Automatic Certificate Management Environment), an IETF standard protocol (RFC 8555) for automating interactions between a certificate authority and a web server. Instead of you filling in a web form and waiting for a human to approve it, a piece of software on your server talks directly to Let’s Encrypt’s ACME server and completes a “challenge” to prove domain control.

The two most common challenge types are:

• HTTP-01: the ACME client places a specific file at a known URL under /.well-known/acme-challenge/ on your site, and Let’s Encrypt fetches it over plain HTTP to confirm you control the server.
• DNS-01: the client creates a specific TXT record under your domain’s DNS, and Let’s Encrypt queries DNS to confirm it. This is the only option for wildcard certificates (e.g. *.example.com), since HTTP-01 can’t validate a wildcard.

Once the challenge passes, the CA signs a certificate for the public key your client generated, and your ACME client (usually certbot) downloads and installs it. All of this happens without any human at Let’s Encrypt ever looking at the request.

Installing Certbot

Certbot is the ACME client maintained by the Electronic Frontier Foundation, and it’s the most widely used tool for working with Let’s Encrypt. On a Debian or Ubuntu server with Nginx, install it with:

sudo apt update
sudo apt install certbot python3-certbot-nginx

For Apache, swap the plugin package:

sudo apt install certbot python3-certbot-apache

Certbot is also available on most other Linux distributions and can be run inside Docker if you’d rather not install it on the host. Avoid installing it via your distribution’s older repositories if the version is badly out of date; the Certbot project recommends using snap or the official instructions on their website to get a current release.

Getting Your First Certificate

If certbot has a plugin for your web server, the simplest route lets it edit your server config automatically:

sudo certbot --nginx -d example.com -d www.example.com

This obtains a certificate covering both example.com and www.example.com, installs it, and offers to set up an HTTPS redirect for you. If you’d rather handle the web server config yourself, or you’re not running Nginx or Apache, use the webroot method instead, pointing it at the document root that’s already being served:

sudo certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com

certonly obtains the certificate files and drops them under /etc/letsencrypt/live/example.com/ without touching your server config, so you can wire them in manually. There’s also a standalone mode, which spins up its own temporary web server to answer the challenge, useful when nothing is listening on port 80 yet, such as a brand new server.

Before running any of this against a live domain for the first time, it’s worth testing against Let’s Encrypt’s staging environment (add –staging) to avoid burning through production rate limits while you’re still getting the command right.

How Long Does the Certificate Last?

Let’s Encrypt certificates are currently valid for 90 days. That’s deliberately short: shorter lifetimes limit how much damage a compromised key can do and reduce reliance on revocation, which doesn’t always work reliably across the web. Let’s Encrypt has announced a firm roadmap to shorten this: the default classic-profile lifetime drops to 64 days from February 2027 and then to 45 days from February 2028, in line with a wider CA/Browser Forum requirement capping all public certificates at 47 days by 2029. A shorter opt-in profile already exists today, too – six-day short-lived certificates became generally available in January 2026 for anyone who wants tighter key-compromise exposure now. For most sites, though, 90 days remains the standard certificate issued by default.

The short lifetime is the reason automatic renewal isn’t optional in practice. A certificate you have to remember to renew manually every three months is a certificate that will eventually expire while you’re on holiday.

Setting Up Automatic Renewal

When you install certbot via the official packages, it typically sets up a systemd timer (or a cron job on older systems) that runs certbot renew automatically, usually twice a day. Each run checks every certificate on the system and only actually renews the ones within 30 days of expiry, so running it frequently is harmless.

Confirm the timer is active with:

sudo systemctl list-timers | grep certbot

And test that renewal would actually succeed, without using up a real certificate issuance, with a dry run:

sudo certbot renew --dry-run

If your web server needs reloading to pick up a renewed certificate, add a deploy hook so that happens automatically after every successful renewal:

sudo certbot renew --deploy-hook "systemctl reload nginx"

It’s also worth pointing certbot’s expiry notification emails at an address someone actually reads, so if automatic renewal ever fails for some reason, you find out with weeks to spare rather than finding out when a visitor sees a browser security warning. Pairing this with a website monitoring service that checks your certificate’s expiry independently is a good backstop in case renewal fails silently.

Watch Out for Rate Limits

Let’s Encrypt applies rate limits to stop the free service being abused. The ones most likely to affect a normal site are:

Limit	Allowance
Certificates per registered domain	50 per 7 days
Duplicate certificate (same exact set of hostnames)	5 per 7 days
Accounts per IP address	10 per 3 hours
New orders per account	300 per 3 hours

Routine automatic renewals are largely exempt from these limits as long as the set of hostnames on the certificate stays the same, so a properly configured renewal timer won’t run into trouble. Where people usually get caught out is testing and re-testing certificate requests against production while debugging a config, which is exactly why the –staging flag exists.

Summary

Let’s Encrypt makes HTTPS free and largely automatic: certbot handles the ACME challenge, installs the certificate, and, once set up correctly, renews it without you thinking about it again. The one thing worth checking today, right now, is whether your renewal timer is actually running and whether a dry run succeeds. A free certificate that silently fails to renew is worse than no certificate at all, because you won’t notice until it’s already expired.