Let's Encrypt

Last updated

Let's Encrypt
FormationNovember 18, 2014;8 years ago (2014-11-18)
Founder
Headquarters San Francisco, California, U.S.
Coordinates 37°48′01″N122°27′00″W / 37.800322°N 122.449951°W / 37.800322; -122.449951
Services X.509 certificate authority
Parent organization
Internet Security Research Group
Budget (2019)
US$3.6 million [1]
Staff (2020)
16 [2]
Website letsencrypt.org OOjs UI icon edit-ltr-progressive.svg

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, [2] used by more than 300 million websites, [3] with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. [4] Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. [5] Other partners include the certificate authority IdenTrust, [6] the University of Michigan (U-M), [7] and the Linux Foundation. [8]

Contents

Overview

Example of a website using Let's Encrypt HTTPS on Firefox 89 screenshot.png
Example of a website using Let's Encrypt
Example of a Let's Encrypt certificate Let's Encrypt example certificate on Firefox 94 screenshot.png
Example of a Let's Encrypt certificate

The mission for the organization is to create a more secure and privacy-respecting World-Wide Web by promoting the widespread adoption of HTTPS. [9] Let's Encrypt certificates are valid for 90 days, during which renewal can take place at any time. [10] This is handled by an automated process designed to overcome manual creation, validation, signing, installation, and renewal of certificates for secure websites. [11] [12] The project claims its goal is to make encrypted connections to World Wide Web servers ubiquitous. [13] By eliminating payment, web server configuration, validation email management and certificate renewal tasks, it is meant to significantly lower the complexity of setting up and maintaining TLS encryption. [14]

On a Linux web server, execution of only two commands is sufficient to set up HTTPS encryption and acquire and install certificates. [15] [16] To that end, a software package was included into the official Debian and Ubuntu software repositories. [17] [18] Current initiatives of major browser developers such as Mozilla and Google to deprecate unencrypted HTTP are counting on the availability of Let's Encrypt. [19] [20] The project is acknowledged to have the potential to accomplish encrypted connections as the default case for the entire Web. [21]

The service only issues domain-validated certificates, since they can be fully automated. Organization Validation and Extended Validation Certificates both require human validation of any registrants, and are therefore not offered by Let's Encrypt. [22] Support of ACME v2 and wildcard certificates was added in March 2018. [23] The domain validation (DV) utilized by Let's Encrypt dates back to 2002 and was at first controversial when introduced by GeoTrust before becoming a widely accepted method for the issuance of SSL certificates. [24]

By being as transparent as possible, the organization hopes to both protect its own trustworthiness and guard against attacks and manipulation attempts. For that purpose it regularly publishes transparency reports, [25] publicly logs all ACME transactions (e.g. by using Certificate Transparency), and uses open standards and free software as much as possible. [15]

History

The Let's Encrypt project was started in 2012 by two Mozilla employees, Josh Aas and Eric Rescorla, together with Peter Eckersley at the Electronic Frontier Foundation and J. Alex Halderman at the University of Michigan. Internet Security Research Group, the company behind Let's Encrypt, was incorporated in May 2013. [7]

Let's Encrypt was announced publicly on November 18, 2014. [26]

On January 28, 2015, the ACME protocol was officially submitted to the IETF for standardization. [27] On April 9, 2015, the ISRG and the Linux Foundation declared their collaboration. [8] The root and intermediate certificates were generated in the beginning of June. [28] On June 16, 2015, the final launch schedule for the service was announced, with the first certificate expected to be issued sometime in the week of July 27, 2015, followed by a limited issuance period to test security and scalability. General availability of the service was originally planned to begin sometime in the week of September 14, 2015. [29] On August 7, 2015, the launch schedule was amended to provide more time for ensuring system security and stability, with the first certificate to be issued in the week of September 7, 2015 followed by general availability in the week of November 16, 2015. [30]

On September 14, 2015, Let's Encrypt issued its first certificate, which was for the domain helloworld.letsencrypt.org . On the same day, ISRG submitted its root program applications to Mozilla, Microsoft, Google and Apple. [31]

On October 19, 2015, the intermediate certificates became cross-signed by IdenTrust, causing all certificates issued by Let's Encrypt to be trusted by all major browsers. [6]

On November 12, 2015, Let's Encrypt announced that general availability would be pushed back and that the first public beta would commence on December 3, 2015. [32] The public beta ran from December 3, 2015 [33] to April 12, 2016. [34] It launched on April 12, 2016. [35] [36] [4]

On March 3, 2020, Let's Encrypt announced that it would have to revoke over 3 million certificates on March 4, due to a flaw in its Certificate Authority software. [37] Through working with software vendors and contacting site operators, Let's Encrypt was able to get 1.7 million of the affected certificates renewed before the deadline. They ultimately decided not to revoke the remaining affected certificates, as the security risk was low and the certificates were to expire within the next 90 days. [38] The mass-revocation event has significantly increased the global revocation rate. [39]

In March 2020, Let's Encrypt was awarded the Free Software Foundation's annual Award for Projects of Social Benefit. [40]

On February 27, 2020, Let's Encrypt announced having issued a billion certificates. [41]

As of September 2022, Let's Encrypt reports having issued 234 million active (unexpired) certificates. [3]

Technology

Chain of trust

ISRG Root X1 (RSA)

In June 2015, Let's Encrypt announced the generation of their first RSA root certificate, ISRG Root X1. [42] The root certificate was used to sign two intermediate certificates, [42] which are also cross-signed by the certificate authority IdenTrust. [6] [43] One of the intermediate certificates is used to sign issued certificates, while the other is kept offline as a backup in case of problems with the first intermediate certificate. [42] Because the IdenTrust certificate was already widely trusted by major web browsers, Let's Encrypt certificates can normally be validated and accepted by relying parties [28] even before browser vendors include the ISRG root certificate as a trust anchor.

ISRG Root X2 (ECDSA)

Let's Encrypt developers planned to generate an ECDSA root key back in 2015, [42] but then pushed back the plan to early 2016, then to 2019, and finally to 2020. On September 3, 2020, Let’s Encrypt issued six new certificates: one new ECDSA root named "ISRG Root X2", four intermediates, and one cross-sign. The new ISRG Root X2 is cross-signed with ISRG Root X1, Let's Encrypt's own root certificate. Let's Encrypt did not issue an OCSP responder for the new intermediate certificates and instead plans to rely solely on certificate revocation lists (CRLs) to recall compromised certificates and short validity periods to reduce danger of certificate compromise. [44]

ACME protocol

The challenge–response protocol used to automate enrolling with the certificate authority is called Automated Certificate Management Environment (ACME). It can query either Web servers or DNS servers controlled by the domain covered by the certificate to be issued. Based on whether the resulting responses match the expectations, control of the enrollee over the domain is assured (domain validation). The ACME client software can set up a dedicated TLS server that gets queried by the ACME certificate authority server with requests using Server Name Indication (Domain Validation using Server Name Indication, DVSNI), or it can use hooks to publish responses to existing Web and DNS servers.

The validation processes are run multiple times over separate network paths. Checking whether DNS entries are provisioned is done from multiple geographically diverse locations to make DNS spoofing attacks harder to carry out.

ACME interactions are based on exchanging JSON documents over HTTPS connections. [45] A draft specification is available on GitHub, [46] and a version has been submitted to the Internet Engineering Task Force (IETF) as a proposal for an Internet standard. [47]

Let's Encrypt implemented its own draft of the ACME protocol. At the same time, they pushed for standardization. This led to a "proposed standard" (RFC8555) in May 2019. It introduced breaking changes and as such it has been dubbed ACMEv2. Let's Encrypt implemented the new version and started pushing existing clients into upgrades. The nudging was implemented with intermittent down-times of the ACMEv1 API. The end-of-lifetime was announced with dates and phases in "End of Life Plan for ACMEv1". [48] Since November 8, 2019, ACMEv1 no longer accepts new account registrations. Since June 2020, ACMEv1 stopped accepting new domain validations. From January 2021, ACMEv1 underwent 24-hour brownouts. The ACMEv1 API was turned off completely on June 1, 2021. [49]

Software implementation

Domain selection dialogue Letsencrypt screenshot 2 domain choice.png
Domain selection dialogue

The certificate authority consists of a piece of software called Boulder, written in Go, that implements the server side of the ACME protocol. It is published as free software with source code under the terms of version 2 of the Mozilla Public License (MPL). [50] It provides a RESTful API that can be accessed over a TLS-encrypted channel.

An Apache-licensed [51] Python certificate management program called certbot (formerly letsencrypt) gets installed on the client side (the Web server of an enrollee). This is used to order the certificate, to conduct the domain validation process, to install the certificate, to configure the HTTPS encryption in the HTTP server, and later to regularly renew the certificate. [15] [52] After installation and agreeing to the user license, executing a single command is enough to get a valid certificate installed. Additional options like OCSP stapling or HTTP Strict Transport Security (HSTS) can also be enabled. [45] Automatic setup initially only works with Apache and nginx.

Let's Encrypt issues certificates valid for 90 days. The reason given is that these certificates "limit damage from key compromise and mis-issuance" and encourage automation. [53]

Initially, Let's Encrypt developed its own ACME client Certbot as an official implementation. This has been transferred to Electronic Frontier Foundation and its name "letsencrypt" has been changed to "certbot". There is a large selection of ACME clients and projects for a number of environments developed by the community. [54]

    See also

    Further reading

    Related Research Articles

    <span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

    Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

    Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

    <span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

    A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

    In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes information about the key, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

    In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

    The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

    <span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

    Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

    GeoTrust is a digital certificate provider. The GeoTrust brand was bought by Symantec from Verisign in 2010, but agreed to sell the certificate business in August 2017 to private equity and growth capital firm Thoma Bravo LLC. GeoTrust was the first certificate authority to use the domain-validated certificate method which accounts for 70 percent of all SSL certificates on the Internet. By 2006, GeoTrust was the 2nd largest certificate authority in the world with 26.7 percent market share according to independent survey company Netcraft.

    Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.

    Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC3546.

    DigiCert, Inc. is a global digital security company and a leading global provider of digital trust headquartered in Lehi, Utah, with over a dozen global offices in various countries including: Australia, Belgium, Bermuda, Ireland, Japan, India, Germany, France, Netherlands, South Africa, Switzerland and United Kingdom. As a certificate authority (CA) and trusted third party, DigiCert provides the public key infrastructure (PKI) and validation required for issuing digital certificates or TLS/SSL certificates. These certificates are used to verify and authenticate the identities of organizations and domains and to protect the privacy and data integrity of users’ digital interactions with web browsers, email clients, documents, software programs, apps, networks and connected IoT devices.

    The Certification Authority Browser Forum, also known as the CA/Browser Forum, is a voluntary consortium of certification authorities, vendors of Internet browser and secure email software, operating systems, and other PKI-enabled applications that promulgates industry guidelines governing the issuance and management of X.509 v.3 digital certificates that chain to a trust anchor embedded in such applications. Its guidelines cover certificates used for the SSL/TLS protocol and code signing, as well as system and network security of certificate authorities.

    The Transport Layer Security (TLS) protocol provides the ability to secure communications across or inside networks. This comparison of TLS implementations compares several of the most notable libraries. There are several TLS implementations which are free software and open source.

    DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

    HTTPS Everywhere is a discontinued free and open-source browser extension for Google Chrome, Microsoft Edge, Mozilla Firefox, Opera, Brave, Vivaldi and Firefox for Android, which is developed collaboratively by The Tor Project and the Electronic Frontier Foundation (EFF). It automatically makes websites use a more secure HTTPS connection instead of HTTP, if they support it. The option "Encrypt All Sites Eligible" makes it possible to block and unblock all non-HTTPS browser connections with one click. Due to the widespread adoption of HTTPS on the World Wide Web, and the integration of HTTPS-only mode on major browsers, the extension was retired in January 2023.

    The Internet Security Research Group (ISRG) is a Californian public-benefit non-profit corporation which focuses on Internet security.

    DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a new "CAA" Domain Name System (DNS) resource record.

    <span class="mw-page-title-main">Automatic Certificate Management Environment</span> Communications protocol for automating interactions between certificate authorities and web servers

    The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users' servers, allowing the automated deployment of public key infrastructure at very low cost. It was designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service.

    <span class="mw-page-title-main">J. Alex Halderman</span> American computer scientist

    J. Alex Halderman is professor of Computer Science and Engineering at the University of Michigan, where he is also director of the Center for Computer Security & Society. Halderman's research focuses on computer security and privacy, with an emphasis on problems that broadly impact society and public policy.

    <span class="mw-page-title-main">Peter Eckersley (computer scientist)</span> Australian computer scientist (1978/1979–2022)

    Peter Daniel Eckersley was an Australian computer scientist, computer security researcher and activist. From 2006 to 2018, he worked at the Electronic Frontier Foundation, including as chief computer scientist and head of AI policy. In 2018, he left the EFF to become director of research at the Partnership on AI, a position he held until 2020. In 2021, he co-founded the AI Objectives Institute.

    References

    1. Aas, Josh (December 31, 2019). "Looking Forward to 2019". Let's Encrypt. Retrieved January 26, 2019.
    2. 1 2 "For A Better Internet - ISRG 2020 Annual Report" (PDF). Internet Security Research Group . November 17, 2020. Retrieved May 11, 2021.
    3. 1 2 "Let's Encrypt Stats - Let's Encrypt - Free SSL/TLS Certificates". letsencrypt.org. Retrieved October 1, 2022.
    4. 1 2 "About Let's Encrypt". Let's Encrypt.
    5. "Current Sponsors and Funders". Let's Encrypt.
    6. 1 2 3 Aas, Josh (October 19, 2015). "Let's Encrypt is Trusted".
    7. 1 2 Aas, Josh (November 18, 2014). "Let's Encrypt | Boom Swagger Boom". Boomswaggerboom.wordpress.com. Archived from the original on December 8, 2015. Retrieved January 6, 2016.
    8. 1 2 Kerner, Sean Michael (April 9, 2015). "Let's Encrypt Becomes Linux Foundation Collaborative Project". eWeek. QuinStreet Enterprise.[ permanent dead link ]
    9. "Let's Encrypt - FAQ". Let's Encrypt. Retrieved May 11, 2021.
    10. "Why ninety-day lifetimes for certificates? - Let's Encrypt". letsencrypt.org. Retrieved September 5, 2021.
    11. Kerner, Sean Michael (November 18, 2014). "Let's Encrypt Effort Aims to Improve Internet Security". eWeek.com. Quinstreet Enterprise. Archived from the original on December 13, 2016. Retrieved February 27, 2015.
    12. Eckersley, Peter (November 18, 2014). "Launching in 2015: A Certificate Authority to Encrypt the Entire Web". Electronic Frontier Foundation . Retrieved February 27, 2015.
    13. "How It Works". Let's Encrypt. Retrieved July 9, 2016.
    14. Tung, Liam (November 19, 2014). "EFF, Mozilla to launch free one-click website encryption". ZDNet. CBS Interactive.
    15. 1 2 3 Fabian Scherschel (November 19, 2014). "Let's Encrypt: Mozilla und die EFF mischen den CA-Markt auf" (in German). heise.de.
    16. Marvin, Rob (November 19, 2014). "EFF wants to make HTTPS the default protocol". Software Development Times . BZ Media. Archived from the original on June 17, 2016. Retrieved May 27, 2019.
    17. Marier, Francois (January 1, 2015). "ITP: letsencrypt – Let's Encrypt client that can update Apache configurations". Debian Bug report logs.
    18. "python-letsencrypt". Debian Package Tracker. May 27, 2015.
    19. Barnes, Richard (April 30, 2015). "Deprecating Non-Secure HTTP". Mozilla Security Blog. Mozilla.
    20. "Marking HTTP As Non-Secure". The Chromium Projects.
    21. Moody, Glyn (November 25, 2014). "The Coming War on Encryption, Tor, and VPNs". Computerworld UK. IDG UK.
    22. Vaughan-Nichols, Steven J. (April 9, 2015). "Securing the web once and for all: The Let's Encrypt Project". ZDNet. CBS Interactive.
    23. Aas, Josh (March 13, 2018). "ACME v2 and Wildcard Certificate Support is Live". Let's Encrypt. Retrieved May 24, 2018.
    24. "There's certs and certs – VeriSign badmouths rivals". www.theregister.com. Retrieved August 20, 2020.
    25. Zorz, Zeljka (July 6, 2015). "Let's Encrypt CA releases transparency report before its first certificate". Help Net Security.
    26. Joseph Tsidulko (November 18, 2014). "Let's Encrypt, A Free And Automated Certificate Authority, Comes Out Of Stealth Mode". crn.com. Retrieved August 26, 2015.
    27. History for draft-barnes-acme
    28. 1 2 Reiko Kaps (June 5, 2015). "Let's Encrypt: Meilenstein zu kostenlosen SSL-Zertifikaten für alle" (in German). heise.de.
    29. Josh Aas (June 16, 2015). "Let's Encrypt Launch Schedule". letsencrypt.org. Let's Encrypt. Retrieved June 19, 2015.
    30. "Updated Let's Encrypt Launch Schedule". August 7, 2015.
    31. Michael Mimoso. "First Let's Encrypt Free Certificate Goes Live". Threatpost.com, Kaspersky Labs. Retrieved September 16, 2015.
    32. "Public Beta: December 3, 2015". November 12, 2015.
    33. "Entering Public Beta - Let's Encrypt - Free SSL/TLS Certificates". Let's Encrypt. December 3, 2015. Retrieved January 6, 2016.
    34. "Let's Encrypt Leaves Beta". LinuxFoundation.org. Archived from the original on April 15, 2016. Retrieved April 17, 2016.
    35. Josh Aas; ISRG Executive Director. "Leaving Beta, New Sponsors". EFF. Retrieved April 12, 2016.
    36. Catalin Cimpanu. "Let's Encrypt Launched Today, Currently Protects 3.8 Million Domains". Softpedia News. Retrieved April 12, 2016.
    37. "Revoking certain certificates on March 4". March 3, 2020. Retrieved March 4, 2020.
    38. Barrett, Brian (March 9, 2020). "The Internet Avoided a Minor Disaster Last Week". Wired. Conde Nast. Retrieved May 12, 2020.
    39. Korzhitskii, Nikita; Carlsson, Niklas (2021). Revocation Statuses on the Internet. In proceedings of 2021 Passive and Active Measurement Conference (PAM 2021). arXiv: 2102.04288 .
    40. Let's Encrypt, Jim Meyering, and Clarissa Lima Borges receive FSF's 2019 Free Software Awards Free Software Foundation, 2020
    41. "Let's Encrypt Has Issued a Billion Certificates - Let's Encrypt - Free SSL/TLS Certificates". letsencrypt.org. Retrieved April 3, 2021.
    42. 1 2 3 4 Aas, Josh (June 4, 2015). "Let's Encrypt Root and Intermediate Certificates". Let's Encrypt.
    43. Reiko Kaps (June 17, 2015). "SSL-Zertifizierungsstelle Lets Encrypt will Mitte September 2015 öffnen" (in German). heise.de.
    44. Gable, Aaron (September 17, 2020). "Let's Encrypt's New Root and Intermediate Certificates". Let's Encrypt. Retrieved September 22, 2020.
    45. 1 2 Brook, Chris (November 18, 2014). "EFF, Others Plan to Make Encrypting the Web Easier in 2015". Threatpost: The Kaspersky Lab Security News Service.
    46. "Draft ACME specification". GitHub. May 6, 2020.
    47. Barnes, Richard; Eckersley, Peter; Schoen, Seth; Halderman, Alex; Kasten, James (January 28, 2015). "Automatic Certificate Management Environment (ACME) draft-barnes-acme-01". Network Working Group.
    48. "End of Life Plan for ACMEv1". Let's Encrypt Community Support. March 11, 2019. Retrieved August 20, 2020.
    49. "End of Life Plan for ACMEv1 - API Announcements". Let's Encrypt Community Support. May 5, 2021. Retrieved May 12, 2021.
    50. letsencrypt. "boulder/LICENSE.txt at master · letsencrypt/boulder · GitHub". Github.com. Retrieved January 6, 2016.
    51. letsencrypt (November 23, 2015). "letsencrypt/LICENSE.txt at master · letsencrypt/letsencrypt · GitHub". Github.com. Retrieved January 6, 2016.
    52. Sanders, James (November 25, 2014). "Let's Encrypt initiative to provide free encryption certificates". TechRepublic. CBS Interactive.
    53. Aas, Josh (November 9, 2015). "Why ninety-day lifetimes for certificates?". Let's Encrypt. Retrieved June 26, 2016.
    54. "ACME Client Implementations - Let's Encrypt - Free SSL/TLS Certificates". letsencrypt.org. Retrieved August 20, 2020.