Defaults.Exposed

Let's Encrypt TLS setup with Certbot

Setting up TLS with Let’s Encrypt on a server you control is one command run by an ACME client, and nothing on the way costs money. That command proves to the certificate authority that you control the domain name, fetches a certificate, writes it into your web server’s configuration, offers to send plain HTTP visitors to HTTPS, and leaves a timer behind that renews the certificate before it expires. This page takes that line apart.

Let’s Encrypt is a non-profit certificate authority that issues certificates free of charge through the automated ACME protocol, which also performs the renewal. It does not host the domain’s DNS or terminate the connection at an edge; the certificate it issues has to be installed and served from your own server running Nginx or Apache.

What the certificate is and what it proves

TLS is the protocol behind the https in a browser’s address bar: it encrypts what passes between a visitor and your server, and it lets the visitor’s browser check that it reached the right server. The check rests on a certificate, a signed statement from a certificate authority that whoever holds a particular private key controls a named host. Browsers ship with a list of authorities they trust, so a certificate from any of them turns the padlock on.

A certificate on its own encrypts nothing: it sits in the server’s configuration next to the private key, and the server presents it during the handshake that starts each connection. The job therefore has two halves: an authority issues the certificate, and your web server has to be told where it is and which protocol versions to offer.

Why the domain’s DNS has to point at the server first

An authority issues nothing until it has proof that you control the name you’re asking for, and it collects that proof through DNS. With the HTTP challenge, the client places a file on your server and the authority fetches it over port 80 at whatever address the domain’s A or AAAA record points to. With the DNS challenge, the client publishes a TXT record at _acme-challenge.yourdomain.com and the authority reads it back. Either way, a domain whose DNS points somewhere else fails validation before any certificate exists.

Check whether the domain sits behind Cloudflare with the orange cloud switched on, because Cloudflare then terminates the connection at its own edge with its own certificates and visitors already see a valid padlock, though the leg from Cloudflare to the origin server still wants a certificate, either from Let’s Encrypt or from Cloudflare’s own free Origin CA.

Check next whether the site runs on a managed host or a site builder such as Squarespace, Wix, Shopify or most cPanel hosts, because these issue and renew certificates automatically, many of them using Let’s Encrypt underneath under a name such as cPanel’s AutoSSL, which leaves nothing to install beyond confirming the padlock and switching on force HTTPS. Only a reader running their own VPS or dedicated server with Nginx or Apache needs to install Certbot and run the commands below.

DNS has a second say. A CAA record at your domain lists the authorities allowed to issue for it, and an authority that isn’t on the list refuses. Domains without one accept issuance from any authority, and the DNS piece covers what the record looks like.

What the one command decides for you

Inside that single line sit choices a manual setup would ask about one at a time, starting with the names. A certificate covers the hostnames listed in it and no others, so the client asks which of the names it found in your server config to include, and the apex and the www form both belong on it if you serve both. Miss one and visitors to that name see a certificate for a different host.

The client picks the key type without asking, an RSA key of 2048 bits or an elliptic curve key. The challenge defaults to HTTP over port 80 because it needs no access to your DNS provider, and the DNS challenge stays for wildcard names that the HTTP method can’t validate. The lifetime is short on purpose, weeks rather than years, and that only works because the same client renews the certificate on a timer with no one watching.

Let’s Encrypt issues and signs the certificate once the ACME challenge over port 80 proves control of the domain, and it also runs the automated renewal protocol behind the scenes. It does not touch the domain’s DNS or the server configuration itself; Certbot, running on your own server, writes the certificate into the Nginx or Apache config, arms the HTTP to HTTPS redirect and reloads the server.

The redirect is the one choice worth pausing on. A certificate on a server that still answers on plain HTTP protects the visitors who typed https and nobody else, and most people type the bare domain and land on port 80. The redirect sends them to the encrypted version, and it’s the setting that changes what a scan sees for your domain.

Start with the defaults: both names, the HTTP challenge, the redirect switched on, TLS 1.2 and 1.3 offered. Tighten later, in the three places at the end of this page.

Get the certificate from Let’s Encrypt

The lines below are the whole job on a server you have shell access to. Keep the terminal open until the renewal check further down has passed.

sudo certbot (with the nginx plugin flag, or the apache one)
sudo certbot renew (with the dry-run flag)

Certbot has no separate type, host or value fields to fill in: it reads the Nginx or Apache configuration directly, lists the hostnames it finds and asks which to secure, so the only choice is which domain names to select, both with and without www. The one prompt that matters is the redirect choice, where choosing to redirect HTTP to HTTPS moves every visitor onto the encrypted connection. There is no TTL to set, since Certbot writes the certificate straight into the server configuration and reloads the server itself.

  1. Install Certbot on the server with sudo snap install certbot in classic mode on most modern Linux distributions.
  2. Create the command link afterwards with sudo ln -s /snap/bin/certbot /usr/bin/certbot.
  3. On Debian or Ubuntu, install instead with sudo apt install certbot python3-certbot-nginx.
  4. Run sudo certbot with its Nginx plugin flag against an Nginx server, or with its Apache plugin flag against an Apache server.
  5. Select the domain from the list Certbot finds in the server config, choosing both with and without www if both are served.
  6. Choose the option to redirect HTTP to HTTPS when Certbot prompts for it.
  7. Let Certbot obtain the certificate, write it into the server config and reload the server.
  8. Run sudo certbot renew in dry-run mode afterwards to confirm the renewal timer works.

Prove the renewal is armed, then check the handshake

A certificate that issued cleanly and a renewal that will fire on its own are two separate things, and the second one is what people skip. The certificate is issued and installed the moment the Certbot command finishes, and the server reload makes it live straight away. Certificates last 90 days, and the timer Certbot installs renews it around day 60, with nothing to check in a separate console.

Then run the free scan against your domain. It opens a connection the way a browser does and tells you in plain words whether the certificate validates, whether the chain is complete, and which protocol versions and ciphers the server offers.

The dry-run renewal output states whether the simulated renewal succeeded, which is the proof that the timer is armed.

From the command line, openssl s_client -connect yourdomain.com:443 -servername yourdomain.com prints the chain the server sent and ends with Verify return code: 0 (ok) when a client with a standard trust store accepts it. Any other return code names the problem.

What breaks when the certificate is missing or wrong

Without a certificate the site answers on http only, and browsers label the page “Not secure” beside the address. Of the 316,600,902 graded and dead domains in the September 2026 census, 104,446,408 (33.0%) answered on HTTP only, and it’s the one failing on a scan report that visitors can see for themselves.

A certificate that exists and is wrong is worse for a visitor than none, because the browser stops them with a full-page warning instead of a label. An expired certificate produces NET::ERR_CERT_DATE_INVALID, which is what a renewal timer that never armed looks like from outside, around the day the lifetime runs out. A certificate that doesn’t list the name typed produces NET::ERR_CERT_COMMON_NAME_INVALID, usually the www form left off the list.

A server that sends the certificate without its intermediate passes in a browser that fetches the missing link itself and fails in a script, a payment webhook or an older phone that doesn’t. Of the 212,154,494 domains that answered on HTTPS in the same census, 23,036,743 (10.9%) presented a certificate that failed validation for one of those reasons.

Each of those fails loudly to the visitor and silently to you, since the server doesn’t know its certificate has expired. The dry run above and a scan a month after setup catch it first.

Tighten once it’s working

Three settings turn a working certificate into a configuration that stays right. Add a CAA record naming your issuer, so no other authority can issue for the domain; the client’s renewal keeps working as long as the issuer you named stays on the list.

Send the HTTP Strict Transport Security header once the redirect has run without incident for a few weeks, so browsers skip the plain HTTP step on return visits. The HSTS piece covers the header and the max-age value to start with.

If your server config predates the client’s installer, check which protocol versions it offers, because a config that still allows TLS 1.0 or 1.1 keeps them on regardless of how new the certificate is. The TLS piece explains what a scan reads from the handshake and why the versions count as much as the padlock does.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.