HTTPS, SSL & Security
What is Let's Encrypt?
Let’s Encrypt is a free, automated, and open certificate authority that provides SSL certificates to anyone who controls a domain, at no cost and with no manual process beyond proving domain control. Launched in 2016 by the Internet Security Research Group, ISRG, Let’s Encrypt was created with a single mission, to make HTTPS the default for the entire web by removing the two biggest barriers to SSL adoption, cost and complexity.
Before Let’s Encrypt obtaining an SSL certificate required paying a certificate authority, typically $50 to $200 per year for a basic domain validation certificate, and navigating a manual purchase and installation process that involved generating certificate signing requests, submitting them to the CA, downloading the issued certificate, and configuring it on the server. For small websites, individual developers, and resource-constrained organisations this combination of cost and complexity meant many sites simply did not have HTTPS, accepting the security risk as the price of avoiding the hassle.
Let’s Encrypt changed this fundamentally. Certificates are free, always, with no premium tier. Issuance is automated through the ACME protocol, a software client handles the entire process of proving domain control, requesting the certificate, installing it, and renewing it automatically before expiry. A domain that supports HTTPS through Let’s Encrypt requires essentially zero ongoing human effort for certificate management once the ACME client is configured.
The impact has been transformative. Let’s Encrypt has issued over three billion certificates since launching. The percentage of web traffic served over HTTPS has risen dramatically, from around 40 percent when Let’s Encrypt launched to over 90 percent of Chrome page loads. Let’s Encrypt is directly responsible for a significant portion of this increase, by making HTTPS free and automatic it removed the practical barriers that previously kept millions of websites on HTTP.
How Let’s Encrypt works
Let’s Encrypt issues certificates through the ACME protocol, Automated Certificate Management Environment, a standardised protocol for automated certificate issuance and renewal. The ACME protocol defines how a domain owner proves control of a domain to the certificate authority and how the CA issues and manages certificates in response.
The ACME protocol: ACME is defined in RFC 8555 and is the open standard that Let’s Encrypt pioneered. Other certificate authorities, ZeroSSL, Google Trust Services, Buypass, have adopted ACME as well, meaning ACME clients can work with multiple CAs. Let’s Encrypt is the most widely used ACME CA and the default for most ACME client implementations.
ACME operates through a series of API calls between the ACME client, software running on the domain owner’s server, and the Let’s Encrypt CA servers. The client requests a certificate, the CA challenges the client to prove domain control, the client completes the challenge, and the CA issues the certificate.
Domain validation challenges: Let’s Encrypt offers three challenge types for proving domain control, HTTP-01, DNS-01, and TLS-ALPN-01.
HTTP-01 challenge: the most commonly used challenge for single domains. Let’s Encrypt specifies a random token that the ACME client must make available at a specific URL path on the domain, http://example.com/.well-known/acme-challenge/TOKEN. Let’s Encrypt’s servers make an HTTP request to this URL and verify the token is present. If the token is found the domain control is proven, Let’s Encrypt can see that the requester controls a server responding to HTTP requests for the domain.
HTTP-01 challenges require the domain to have a web server accessible over HTTP on port 80. They work well for standard web server setups but cannot be used for wildcard certificates, a wildcard covers all subdomains and proving control of http://example.com does not prove control of all subdomains.
DNS-01 challenge: Let’s Encrypt specifies a token that the ACME client must add as a TXT record to the domain’s DNS zone at _acme-challenge.example.com. Let’s Encrypt queries DNS for this TXT record and verifies the token value. DNS control proves the requester controls the domain’s DNS zone, a stronger form of domain control than HTTP access.
DNS-01 challenges are required for wildcard certificates: only DNS validation proves control of the entire domain namespace needed to issue *.example.com. DNS-01 also works for domains that cannot serve HTTP on port 80, internal services, staging environments, or servers behind firewalls. The DNS-01 challenge requires either manual DNS record management or an ACME client with DNS provider API integration for automated DNS challenge completion.
TLS-ALPN-01 challenge: a less commonly used challenge that proves domain control through a TLS connection on port 443. The ACME client configures a specific TLS certificate for the challenge and Let’s Encrypt connects over TLS to verify it. Useful in specific infrastructure setups where neither HTTP nor DNS challenges are practical.
Certificate issuance: after a challenge is successfully completed Let’s Encrypt issues the certificate, a standard X.509 certificate valid for 90 days. The ACME client downloads the issued certificate and installs it on the server. The server is typically reloaded to pick up the new certificate without requiring a restart.
Automatic renewal: Let’s Encrypt’s 90-day validity period is intentionally short, encouraging automation and limiting the window during which a compromised certificate remains valid. ACME clients handle renewal automatically, typically checking for certificates with 30 days or fewer remaining and initiating renewal before expiry. Once configured correctly the certificate lifecycle, issuance, installation, renewal, requires no human intervention.
Let’s Encrypt and redirect management
Let’s Encrypt is the foundation of SSL automation for redirect management, enabling every domain connected to redirect infrastructure to have valid SSL certificates without manual certificate management.
Automatic SSL for redirect source domains: every domain configured as a redirect source requires a valid SSL certificate for HTTPS visitors to receive redirect responses rather than certificate errors. Manually obtaining and installing certificates for dozens or hundreds of redirect source domains, brand protection domains, legacy domains, acquired domains, would be an enormous operational burden without automation.
Redirect management platforms that integrate Let’s Encrypt, using ACME client libraries within their infrastructure, provision SSL certificates automatically for every domain connected to the platform. When a domain is connected by updating its DNS records to point to the redirect infrastructure the platform detects the connection, initiates the ACME challenge process, obtains the certificate from Let’s Encrypt, and installs it, all without any action required from the domain owner. Certificate renewal happens automatically before expiry.
This automation makes it practical to maintain correct SSL on large redirect domain portfolios, the operational overhead of SSL management does not scale with the number of domains because the process is fully automated for each.
HTTP access on port 80, useful for domains where the HTTP server is not yet configured when the certificate is first needed. DNS-01 also supports wildcard certificates, allowing redirect platforms to issue wildcard certificates that cover all subdomains of connected domains.
CAA records and Let’s Encrypt: domains with CAA records that do not include letsencrypt.org in their issue and issuewild directives will have Let’s Encrypt certificate issuance refused, the CA checks CAA records before issuing and refuses if it is not listed. Domain owners who have configured CAA records must include Let’s Encrypt to enable automatic SSL provisioning through platforms that use Let’s Encrypt.
The required CAA records for Let’s Encrypt:
Both records are needed, issue for standard certificates and issuewild for wildcard certificates.
Let’s Encrypt certificate characteristics
Understanding the specific characteristics of Let’s Encrypt certificates helps manage expectations and plan certificate strategy.
Certificate validity, 90 days: Let’s Encrypt certificates are valid for 90 days, significantly shorter than the one to two year validity of commercial certificates. This short validity is intentional, it encourages automation, reduces the risk of long-lived compromised certificates, and limits exposure from certificate mis-issuance. With automated renewal the 90-day period is transparent, the certificate is renewed before expiry without any visible disruption.
Domain validation only: Let’s Encrypt issues only DV, domain validation certificates. It does not offer OV, organisation validation, or EV, extended validation, certificates that include verified organisation identity information. For the vast majority of use cases DV certificates are appropriate and provide full encryption and domain authentication. Organisations that specifically need OV or EV certificates for compliance or trust reasons must use commercial certificate authorities.
Free, no cost ever: Let’s Encrypt certificates are free at every tier. There is no paid version with additional features. There is no limit on the number of certificates that can be issued for a domain. The free model is sustainable through donations and sponsorships from organisations that benefit from a more secure web, Mozilla, Google, Cisco, and many others support Let’s Encrypt financially.
Rate limits: Let’s Encrypt imposes rate limits to prevent abuse, limits on the number of certificates that can be issued for a domain in a given time period. The most relevant limit for redirect management is 50 certificates per registered domain per week. For large domain portfolios where many subdomains need certificates the rate limits require planning, spacing certificate requests to avoid hitting limits or using wildcard certificates to cover many subdomains with one certificate.
Trusted by all major browsers: Let’s Encrypt’s root certificate, ISRG Root X1, is trusted by all major browsers and operating systems. Certificates issued by Let’s Encrypt are accepted without warnings on Chrome, Firefox, Safari, Edge, and all modern operating systems. Older systems, particularly Android versions before 7.1.1, did not originally trust the ISRG root but Let’s Encrypt maintained compatibility through cross-signing with IdenTrust’s DST Root CA X3 until that root expired. Current Let’s Encrypt certificates are trusted by devices running Android 2.3.6 and later through the ISRG Root X1 being added to the Android trust store.
ACME clients
The ACME client is the software that implements the ACME protocol, handling domain validation challenges, certificate requests, installation, and renewal. Several ACME clients are available, each designed for different use cases and server environments.
Certbot: the official ACME client recommended by Let’s Encrypt. Developed by the EFF, Electronic Frontier Foundation. Certbot integrates with common web servers, Apache, Nginx, to automatically obtain certificates and configure the server. Certbot handles HTTP-01 challenges automatically by temporarily serving challenge files through the web server. Certbot’s --standalone mode runs its own temporary web server for challenges when no web server is present. Available for Linux, macOS, and Windows.
acme.sh: a shell script ACME client that runs on any system with a POSIX-compliant shell. Lightweight and flexible, supports HTTP-01, DNS-01, and TLS-ALPN-01 challenges. Excellent DNS provider API integration, supports over 150 DNS providers for automated DNS-01 challenge completion. Widely used for wildcard certificate automation on Linux servers.
win-acme: a Windows-native ACME client with a command-line and interactive interface. Integrates with IIS, Internet Information Services, for automatic certificate installation on Windows web servers.
Caddy: a web server that implements ACME natively, automatically obtaining and renewing Let’s Encrypt certificates for all configured domains with zero additional configuration. Caddy’s automatic HTTPS is one of its most popular features, simply configuring a domain in Caddy’s configuration causes it to obtain an SSL certificate and enforce HTTPS automatically.
Traefik: a reverse proxy and load balancer with built-in ACME client functionality. Widely used in containerised environments, Docker, Kubernetes, where automatic certificate management for dynamically configured services is particularly valuable.
ACME client libraries: libraries in various languages, Go, Python, JavaScript, Ruby, Java, implement the ACME protocol for embedding in custom applications. Redirect management platforms and hosting services use ACME client libraries to integrate automatic certificate provisioning into their infrastructure.
Let’s Encrypt limitations
Let’s Encrypt is appropriate for the vast majority of SSL use cases but has limitations that make alternative certificate authorities necessary in some scenarios.
No OV or EV certificates: organisations requiring verified organisation identity in their certificates, for compliance, legal requirements, or specific trust presentations, cannot use Let’s Encrypt. Commercial CAs provide OV and EV certificates with identity verification.
No multi-year certificates: Let’s Encrypt issues only 90-day certificates. Organisations that manage certificates manually, without automation, and prefer annual or biennial renewal cycles may find 90-day validity impractical. Manual certificate management is antithetical to Let’s Encrypt’s automation focus, the 90-day validity is designed for automated environments.
Rate limits for high-volume scenarios: the 50 certificates per registered domain per week rate limit can be a constraint for platforms issuing many certificates for subdomains of the same domain. Wildcard certificates and careful planning manage this but the limit requires awareness in high-volume scenarios.
No phone or dedicated support: Let’s Encrypt provides community forums and documentation but no dedicated customer support. Organisations that need guaranteed SLA-backed support for certificate issues may prefer commercial CAs with dedicated support offerings.
Checking Let’s Encrypt certificates
Verifying that Let’s Encrypt has issued a certificate for a domain and that it is correctly configured uses standard certificate inspection tools.
Certificate transparency search: Let’s Encrypt logs all issued certificates to certificate transparency logs. Searching crt.sh for a domain shows all certificates issued by Let’s Encrypt alongside certificates from other CAs, confirming issuance and showing the SANs, validity period, and issue date.
Browser certificate inspection: clicking the padlock icon in a browser address bar shows the issuing CA. Let’s Encrypt certificates show “Let’s Encrypt” as the issuer, confirming the certificate came from Let’s Encrypt.
Certbot certificate listing: on servers using Certbot certbot certificates lists all managed certificates with their domains, expiry dates, and certificate paths, providing a quick audit of certificate status.
SSL Labs test: the SSL Labs SSL Test provides full certificate chain analysis, showing the Let’s Encrypt certificate, its intermediate CA, and the ISRG root, alongside configuration grading and any issues identified.