Free SSL certificates: how Let's Encrypt works

Almost every site now runs on HTTPS, and a large share of those certificates come from Let's Encrypt. It exists so that encrypting traffic between browser and server does not depend on paying a certificate authority or filling in forms. Automation is what makes that work: after the initial setup, a program requests, proves and renews the certificate without you touching anything.

If you don't yet know what a TLS certificate does, start with what SSL/TLS is.

What is Let's Encrypt?#

Let's Encrypt is a public certificate authority (CA) run by the Internet Security Research Group (ISRG), a nonprofit. The certificates it issues are trusted by common browsers and operating systems, so visitors see no warning.

The certificate is DV (Domain Validation): it only attests that whoever requested it controls the domain. It does not verify the identity of the company behind the site. For most sites, bots with a web panel and APIs, that is enough.

Let's Encrypt does not charge for certificates. Operations are funded by donations and sponsorships, and the per-certificate cost stays low because everything is automated, with no support desk or manual vetting.

One caveat: when you use Let's Encrypt through a hosting provider or a control panel, the certificate is still free, but the provider may charge a fee for its own administrative work. Read the plan before you assume it all comes free. To compare with paid certificates, see how much an SSL certificate costs.

How does the ACME protocol work?#

ACME (Automatic Certificate Management Environment) is the protocol Let's Encrypt uses. The flow has four steps:

1. Request. The ACME client (Certbot, acme.sh, Caddy, Traefik and others) generates a key pair and requests a certificate for a domain.
2. Challenge. The CA answers with a challenge: a task only someone controlling the domain can complete.
3. Proof. The client completes the challenge by publishing a file or a DNS record.
4. Issuance. The CA checks the proof, signs the certificate and the client installs it.

Because the client repeats this flow by itself, renewal does not depend on remembering a date on a calendar.

What are the challenge types?#

Let's Encrypt supports three challenges. The two most used are HTTP-01 and DNS-01.

HTTP-01 is the simplest: the client places a file on your web server and the CA fetches it over port 80. If several servers sit behind the same domain, the file must be on all of them. Internet providers that block port 80 break this method.

DNS-01 is the only one that issues wildcard certificates (*.example.com). It also works for servers that are not reachable from the internet. The trade-off is automating the TXT record, which requires your DNS provider to have an API. Storing that API credential on the web server is a security risk, so use a key with limited permissions. If DNS records are still new to you, read what DNS records are.

TLS-ALPN-01 has limited client support and suits reverse proxies that terminate TLS.

How do you issue a certificate with Certbot?#

Prerequisites: a domain pointing to the server's IP, port 80 open and sudo access. Installation instructions per system are at certbot.eff.org. On an Ubuntu or Debian server:

sudo apt install certbot
sudo certbot certonly --standalone -d example.com -d www.example.com

The --standalone mode starts a temporary server on port 80, so stop any service using it first. The files end up in /etc/letsencrypt/live/example.com/: fullchain.pem (certificate plus chain) and privkey.pem (private key, never share it).

For a wildcard certificate, use DNS-01. The manual mode below is for testing only and does not renew by itself; in production, use the plugin for your DNS provider:

sudo certbot certonly --manual --preferred-challenges dns -d "*.example.com"

How do you verify and renew?#

List installed certificates and their expiry date:

sudo certbot certificates

Test renewal without issuing anything for real:

sudo certbot renew --dry-run

To check what the server is actually serving:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

The output shows notBefore, notAfter and the issuer.

Let's Encrypt recommends renewing well before expiry, at a random time, to avoid traffic spikes at the CA. As lifetimes keep getting shorter, a fixed interval in days stops working: prefer clients that support ARI (ACME Renewal Information) or renew after about two thirds of the lifetime.

Most Certbot installations already come with automatic renewal, through a systemd timer or a cron entry, but it depends on the install method. Confirm with systemctl list-timers | grep certbot or by looking for certbot renew in /etc/cron.*/*. Certificates issued with --manual do not renew by themselves.

Why are certificates getting shorter?#

For years, Let's Encrypt's default was 90 days. In December 2025 it announced a schedule that cuts that lifetime in stages, first on the opt-in tlsserver profile and then on the default classic profile. The dates and lifetimes of each stage are in the official announcement. There is also a shortlived profile with certificates that last only a few days, which need very frequent renewal.

Short certificates limit the damage from a leaked key, but they only work well with automatic renewal. If you renew by hand, this is the reason to automate. Another change: Let's Encrypt ended OCSP in 2025, so certificates no longer carry an OCSP URL.

What errors show up most often?#

• HTTP-01 validation failure: the domain does not point to the server, port 80 is blocked by a firewall or a redirect breaks the /.well-known/acme-challenge/ path.
• Rate limits: there are caps on validation failures per hostname and account, on identical certificates and on certificates per registered domain, among others. The current values are on the rate limits page. Test with --dry-run before issuing for real.
• Renewal silently stops: the timer was disabled, port 80 is now used by another service or the DNS API credential expired.
• Browser reports an invalid certificate: usually an incomplete chain (use fullchain.pem, not cert.pem) or an expired certificate. See SSL certificate errors.

How to do this on Square Cloud#

On Square Cloud you do not need to issue or renew certificates: TLS is automatic on every plan, with a DV certificate that renews on its own, and HTTP is redirected to HTTPS. Every web application gets a *.squareweb.app subdomain with HTTPS, with no configuration.

To use your own domain, from the Standard plan up, you create the DNS records the dashboard shows at your registrar and follow the validation in real time. TLS for your own domain is automatic too, and the domain stays registered in your name at your registrar.

For the full walkthrough with your own domain, see how to use a custom domain and the domains page.