Let's Encrypt
Let's Encrypt is a free, automated, and open certificate authority (CA) operated by the nonprofit Internet Security Research Group (ISRG) to provide digital certificates enabling HTTPS encryption for websites worldwide.[1] It issues SSL/TLS certificates at no cost, using the open-standard ACME protocol (RFC 8555) for automated validation, issuance, and renewal, thereby lowering barriers to secure web communication.[1] Founded to promote universal encryption on the internet, Let's Encrypt adheres to principles of being free, automatic, secure, transparent, open, and cooperative, ensuring certificates are accessible without manual intervention or payment.[1] The project originated from efforts in 2012 to develop a fully automated CA, leading to the incorporation of ISRG on May 24, 2013, specifically to host Let's Encrypt as its flagship initiative.[2] Public announcement occurred on November 18, 2014, with the first certificates issued in the week of September 7, 2015, and general availability following in the week of November 16, 2015.[3] Since launch, Let's Encrypt has driven widespread HTTPS adoption by eliminating financial and technical hurdles traditionally associated with certificate acquisition, supporting everything from personal blogs to major enterprises.[4] As of January 2025, Let's Encrypt secures over 550 million websites, representing a 42% growth from the previous year. It holds about 60% market share of all websites whose SSL certificate authority is known.[5][6] It issues more than 340,000 certificates per hour, with ongoing infrastructure enhancements—such as scaled rate limits and database optimizations—preparing for over 1 billion active certificates.[5] Funded entirely by donations and sponsorships, the service remains committed to privacy and efficiency, including recent developments like short-lived (six-day) certificates and IP address support introduced in 2025.[4][7]Introduction
Overview
Let's Encrypt is a nonprofit-operated Certificate Authority (CA) that provides free TLS/SSL certificates to enable HTTPS encryption for websites worldwide.[8] Operated by the Internet Security Research Group (ISRG), a 501(c)(3) organization dedicated to advancing Internet security, it focuses on removing barriers to secure web connections.[2] By offering these certificates at no cost, Let's Encrypt addresses the expense and complexity that previously hindered widespread adoption of encryption.[9] Central to its model is automation via the ACME protocol, which facilitates domain validation to confirm that certificate requesters control the domains they intend to secure.[10] Standard certificates issued are valid for 90 days, with an opt-in option for shorter six-day validity periods, encouraging regular automated renewals to maintain security without ongoing manual effort.[9][7] This open-source approach, including the ACME protocol standardized by the IETF, promotes transparency and interoperability to drive universal encryption across the web.[11] In the basic workflow, users deploy open-source client software—such as Certbot—on their servers to request a certificate, complete a validation challenge (like placing a temporary file on the site or updating DNS records), and automatically install the issued certificate, all without human intervention.[10] This streamlined process integrates seamlessly with web servers and hosting environments, making HTTPS accessible to individuals, small organizations, and large-scale deployments alike.[12]Mission and Features
Let's Encrypt's core mission is to promote the widespread adoption of HTTPS across the web, thereby creating a more secure and privacy-respecting internet by providing free, automated digital certificates to website operators.[9] This initiative addresses key barriers to HTTPS deployment, such as the high costs and technical complexities associated with traditional certificate authorities, making encrypted connections accessible to all websites regardless of size or budget.[1] Operated as a nonprofit by the Internet Security Research Group (ISRG), Let's Encrypt adheres to principles of openness and public benefit, eschewing commercial incentives in favor of community-driven development.[1] All of its code, protocols, and specifications are publicly available, including the open standard ACME protocol defined in RFC 8555, which ensures transparency and encourages broad collaboration.[1] This nonprofit structure allows Let's Encrypt to prioritize global internet security over profit, fostering a cooperative ecosystem where improvements benefit the public at large.[9] Among its distinctive features, Let's Encrypt offers automated certificate issuance and renewal, which minimizes human error in managing TLS/SSL configurations and enables seamless integration with popular web servers such as Apache and Nginx through tools like Certbot.[10] It supports wildcard certificates via the DNS-01 challenge method, allowing a single certificate to secure multiple subdomains under a parent domain, which simplifies management for complex sites.[9] Additionally, standard certificates have short 90-day validity periods, with an opt-in for six-day short-lived certificates to enhance security by limiting the impact of potential compromises, and automation facilitating frequent renewals every 60 days or less for standard certificates (or more often for short-lived ones).[9][7] In 2025, Let's Encrypt introduced support for IP address certificates as Subject Alternative Names in short-lived profiles, enabling secure TLS connections for IP-based services without requiring domain validation via DNS-01 challenges.[13]History
Founding and Early Years
The Internet Security Research Group (ISRG) was incorporated on May 24, 2013, as a non-profit public benefit corporation aimed at developing digital infrastructure to enhance internet security, particularly by tackling the limited adoption of HTTPS due to the high costs and complexities of traditional certificate authorities.[14] Founded by Josh Aas, Eric Rescorla, Alex Halderman, and Peter Eckersley, ISRG sought to create an automated system for issuing free SSL/TLS certificates, drawing on expertise from organizations addressing web privacy and security gaps.[15] Backed by initial supporters including the Electronic Frontier Foundation (EFF), Mozilla, Cisco, Akamai, IdenTrust, and the University of Michigan, ISRG positioned Let's Encrypt as a collaborative effort to democratize secure web connections.[16] On November 18, 2014, ISRG publicly announced the Let's Encrypt project, outlining its mission to provide freely available, automated certificates that would simplify HTTPS deployment for websites worldwide and challenge the proprietary models of paid certificate authorities.[17] The initiative emphasized open-source protocols and tools to automate validation and issuance, targeting a launch in mid-2015 to accelerate the encryption of web traffic.[17] This announcement highlighted the project's non-commercial nature, funded through grants and sponsorships, and its commitment to transparency in operations to build community trust.[16] Development progressed through a closed beta phase in 2015, where ISRG tested the Automated Certificate Management Environment (ACME) protocol and issuance systems with select participants.[18] The first certificate was issued on September 14, 2015, to the domain helloworld.letsencrypt.org, demonstrating the system's functionality although initial certificates required cross-signing from IdenTrust's established root for browser trust.[19] Public beta commenced on December 3, 2015, removing invitation requirements and enabling open access to certificate requests.[20] Full general availability, marking the end of the beta period, was achieved on April 12, 2016.[21] One of the primary early challenges was establishing a chain of trust independent of existing authorities; ISRG submitted its root certificate, ISRG Root X1, to major browser and operating system trust stores to gain direct recognition, a process that involved rigorous audits and policy compliance reviews. Integrating with diverse web servers and software ecosystems also required extensive compatibility testing to ensure seamless automation without disrupting site operations.[19] These efforts laid the groundwork for Let's Encrypt's role in promoting universal encryption during its formative period.Growth and Milestones
Following its public launch in late 2015, Let's Encrypt experienced rapid early adoption, issuing its millionth certificate on March 8, 2016, which secured approximately 2.4 million domains.[22] By June 28, 2017, the service had issued over 100 million certificates in total, demonstrating significant uptake among website operators seeking free TLS protection.[23] This momentum continued with the addition of support for wildcard certificates on March 13, 2018, enabling single certificates to cover multiple subdomains and simplifying management for complex site architectures. Key milestone events marked sustained expansion, including reaching 100 million active certificates in May 2019, a threshold that underscored the service's role in encrypting a substantial portion of the web.[24] In 2020 and 2021, Let's Encrypt advanced its cryptographic infrastructure by issuing new intermediate certificates and introducing an ECDSA root (ISRG Root X2) on September 3, 2020, alongside RSA intermediates to enhance efficiency and support modern key types without disrupting existing chains.[25] These updates, including cross-signing for compatibility, facilitated smoother transitions for relying parties while maintaining trust.[25] Scaling infrastructure efforts enabled Let's Encrypt to handle billions of certificates annually, with over 3 billion issued by November 2022 and continued growth supporting more than 309 million domains via 239 million active certificates at that time.[26] The 10th anniversary of Let's Encrypt's first certificate issuance in 2025 prompted reflections on its contributions to HTTPS adoption, noting that encrypted page loads had risen dramatically since 2015, with the service now protecting hundreds of millions of sites globally.[27] Recent milestones include the generation and issuance of new root certificates—ISRG Root YE (ECDSA P-384) and ISRG Root YR (RSA 4096)—on September 3, 2025, as part of a key ceremony to refresh the chain of trust and prepare for future rotations.[28] Additionally, on January 16, 2025, Let's Encrypt announced preparation for short-lived certificates with six-day validity periods, an opt-in feature via ACME profiles to bolster security by reducing exposure windows, alongside support for IP address certificates.[7] Organizational growth at the Internet Security Research Group (ISRG), the nonprofit behind Let's Encrypt, has evolved through diversified funding models relying on sponsorships and donations rather than certificate fees, with founding partners including Mozilla, the Electronic Frontier Foundation, Cisco, Akamai, and the University of Michigan.[2] Ongoing partnerships, such as the 2024 renewal with Princeton University for research on certificate transparency and revocation, have supported technical advancements, while a broad donor base—including Google, Facebook, and Microsoft—ensures operational sustainability without compromising the free service model.[29][30] This structure has allowed ISRG to scale operations, invest in protocol improvements, and maintain independence since its inception in 2013.[2]Operations
Certificate Issuance Process
The certificate issuance process for Let's Encrypt begins when a domain owner uses an ACME client to generate a public-private key pair for their account, which authenticates the client to the Let's Encrypt API.[10] The client then creates a PKCS#10 Certificate Signing Request (CSR) containing the desired domain names and the public key, signed with the account's private key, and submits it to the Let's Encrypt server via the ACME protocol.[10] To verify domain control, the server issues a challenge that the client must complete, after which the server checks the response from multiple network vantage points to ensure authenticity.[10] Upon successful validation, Let's Encrypt signs the certificate with its intermediate CA key and delivers it to the client. Let's Encrypt then submits the certificate to public Certificate Transparency logs for monitoring.[10] Let's Encrypt supports several domain validation methods, each suited to different server configurations. The HTTP-01 challenge requires the client to place a specific token file athttp://<domain>/.well-known/acme-challenge/<token> on port 80, allowing the Let's Encrypt server to retrieve it via HTTP (with support for up to 10 redirects, but no IP-based redirects).[31] This method is widely used but cannot issue wildcard certificates and fails if port 80 is blocked by firewalls.[31] Both HTTP-01 and TLS-ALPN-01 also support validation for IP addresses (IPv4 and IPv6 /64), introduced in 2025, while DNS-01 does not.[7] The DNS-01 challenge involves adding a TXT record with a specific token value at _acme-challenge.<domain>, which the server queries via DNS resolution; it supports wildcard certificates and CNAME/NS delegation but may require up to an hour for propagation.[31] The TLS-ALPN-01 challenge, which validates control through a custom TLS Application-Layer Protocol Negotiation (ALPN) extension on port 443 using Server Name Indication (SNI), remains active but has limited client support and does not work for wildcards.[31] For historical context, the TLS-SNI-01 challenge was deprecated in March 2019 due to vulnerabilities allowing unauthorized issuance.[31]
Certificates issued by Let's Encrypt have a fixed lifetime of 90 days to encourage automation and rapid revocation if compromised, though an opt-in short-lived option of 6 days is available.[9] Renewal follows the same issuance workflow, with clients typically automating re-issuance around 30 days before expiration to maintain continuous coverage; validation results are cached for up to 30 days, potentially skipping re-validation during renewal if unchanged.[9] Clients are advised to schedule renewals at randomized intervals to distribute load evenly across Let's Encrypt's infrastructure.[9]
Common errors during issuance often stem from misconfigured validation challenges, such as firewalls blocking port 80 for HTTP-01 attempts or DNS propagation delays in DNS-01 setups, which can be troubleshot by verifying network accessibility from external vantage points and using the staging environment for testing.[32] Another frequent issue is cached authorizations preventing expected re-validation, resolvable by forcing a new challenge or waiting out the 30-day cache period.[9]
For seamless integration, tools like Certbot—recommended by Let's Encrypt—automate the entire process, including key generation, challenge completion, installation on web servers like Apache or Nginx, and scheduled renewals via cron jobs or systemd timers.[12] For example, running certbot --nginx on a Ubuntu server with Nginx prompts domain selection, handles HTTP-01 validation, and configures the server to use the new certificate while setting up automatic renewal.[12] Other ACME clients, such as acme.sh or Lego, offer similar functionality for custom environments.[12]
Policies and Rate Limits
Let's Encrypt operates under a set of core policies designed to ensure secure and responsible use of its certificates. The service issues Domain Validation (DV) certificates exclusively, verifying control over domain names through technical methods without providing Organization Validation (OV) or Extended Validation (EV) options.[9][33] Certificates are available only for public domain names and public IP addresses (IPv4 or IPv6 /64 ranges), requiring subscribers to be the legitimate registrant, assignee, or authorized agent of the identifiers in the certificate request.[33] Additionally, the Subscriber Agreement prohibits using certificates for illegal activities, including phishing, fraud, malware distribution, or facilitating man-in-the-middle attacks to intercept encrypted communications.[33] To prevent abuse and maintain service sustainability, Let's Encrypt enforces strict rate limits on certificate issuance and related operations. As of June 2025, key limits include up to 50 new certificates per registered domain (defined by the eTLD+1, such as example.co.uk), per IPv4 address, or per IPv6 /64 range every 7 days, and 300 new orders per account every 3 hours.[32] A separate limit of 5 duplicate certificates per exact set of identifiers applies every 7 days to discourage unnecessary reissuances.[32] These limits use a token bucket algorithm for enforcement, with no resets for revoked certificates, and overrides are available for some via a formal request process.[32] In response to rapid growth, Let's Encrypt evolved its rate limiting infrastructure on January 30, 2025, implementing a system based on Redis for storage and the Generic Cell Rate Algorithm (GCRA) for flow management.[5] This upgrade supports scaling to over 1 billion active certificates by reducing database load by 80% and authorization reads by over 99%, addressing a 42% yearly increase in protected websites from over 550 million (as of January 2025).[5] The changes maintain existing per-domain limits while enabling smoother handling of high-volume requests.[5] Subscribers are encouraged to use the staging environment for testing ACME clients and issuance processes, which features higher rate limits—such as 10 new registrations per IP every 3 hours—to avoid impacting production quotas.[34][32] Enforcement includes automated detection of duplicate certificate requests and temporary suspensions for repeated violations, such as exceeding per-domain limits, which can result in issuance bans until the limit window refills.[32][35] Misuse reports, including potential policy breaches, can be submitted to [email protected] for investigation and possible revocation.[36]Technology
ACME Protocol
The Automated Certificate Management Environment (ACME) protocol facilitates automated issuance, renewal, and revocation of X.509 certificates between client software and a certificate authority (CA) server, such as Let's Encrypt, through a client-server interaction over HTTPS using JSON messages secured by JSON Web Signatures (JWS).[37] Defined in RFC 8555 published in March 2019, ACME version 2 (v2) standardizes this process, while the earlier ACME v1, based on draft specifications, has been deprecated by Let's Encrypt since June 2021 to encourage adoption of the more robust v2.[37][38] The protocol supports the full certificate lifecycle, enabling clients to register accounts, request orders for specific domain identifiers, prove control over those identifiers via challenges, submit certificate signing requests (CSRs), and retrieve issued certificates, all while maintaining security through cryptographic proofs.[39] In 2025, Let's Encrypt introduced support for ACME Profiles as an extension to RFC 8555, allowing clients to negotiate specific features such as short-lived certificates during the order process. This enables issuance of certificates with reduced lifetimes, such as six days, to enhance security by minimizing exposure windows while maintaining automation. Short-lived certificates are requested via profile negotiation in the newOrder request, with general availability targeted by late 2025.[7] Key components of ACME include account registration, where a client creates an account with the server by submitting a signed newAccount request containing a JSON Web Key (JWK) public key, optional contact information, and agreement to the server's terms of service.[40] For security, the server provides a unique nonce value in HTTP headers with each response, which the client must include in the JWS header of subsequent requests to prevent replay attacks.[41] Directory discovery allows clients to locate API endpoints by fetching a directory resource from the server's well-known URL, which lists URLs for resources like newAccount, newOrder, and newNonce.[42] Order objects, created via a newOrder request, represent pending certificate requests and include an array of identifiers (e.g., domain names) along with authorization and finalization URLs provided by the server.[43] The challenge-response mechanism verifies the client's control over a domain without relying on pre-existing trust, using methods like HTTP-01, DNS-01, and TLS-ALPN-01.[44] In the HTTP-01 challenge, the server provides a token, and the client must host a resource athttps://<domain>/.well-known/acme-challenge/<token> containing the key authorization string, formed as <token>.<thumbprint>, where the thumbprint is the base64url-encoded SHA-256 digest of the account's JWK per RFC 7638.[45] The server then fetches this resource and computes the expected key authorization to validate it. For DNS-01, the client adds a TXT DNS record at _acme-challenge.<domain> with the base64url-encoded SHA-256 digest of the key authorization string, allowing wildcard domain validation (e.g., *.example.com), which is not supported by HTTP-01 or TLS-ALPN-01.[45][46] TLS-ALPN-01 involves the client serving a self-signed TLS certificate during a TLS handshake over Application-Layer Protocol Negotiation (ALPN) with the ACME protocol identifier, embedding the key authorization in the certificate's extensions for server validation.[47] Upon successful challenge completion for all identifiers in an order, the client submits a CSR via a finalize request, after which the server issues and provides the certificate download URL.[48]
Security features in ACME rely on JOSE and JWS standards to sign all client requests with the account's private key, ensuring authenticity and integrity without transmitting private keys to the server.[49] Anti-replay protection is enforced by requiring a fresh nonce from the server in each JWS, which is single-use and time-bound to mitigate man-in-the-middle attacks.[41] Rate limiting is integrated at the server level, where excessive requests (e.g., for new accounts or orders) trigger a rateLimited error response with details on exceeded limits, helping prevent abuse and denial-of-service attempts.[50]
ACME extensions include support for wildcard certificates exclusively through DNS-01 challenges, revocation requests via a signed revokeCert message to the CA using the certificate's serial number or encoded body, and key rollover through a keyChange request that allows updating an account's key pair while authorizing the transition with the old key.[51][52] These features enable flexible management while adhering to the protocol's core security model.[53]