Let's Encrypt - Free SSL/TLS Certificates

Leaving Beta, New Sponsors

Tue, 12 Apr 2016 00:00:00 -0700

Let’s Encrypt is leaving beta today. We’re also excited to announce that founding sponsors Cisco and Akamai have renewed their Platinum sponsorships with 3-year commitments, Gemalto is joining as our newest Gold sponsor, and HP Enterprise, Fastly, Duda and ReliableSite.net are our newest Silver sponsors.

Since our beta began in September 2015 we’ve issued more than 1.7 million certificates for more than 3.8 million websites. We’ve gained tremendous operational experience and confidence in our systems. The beta label is simply not necessary any more.

We set out to encrypt 100% of the Web. We’re excited to be off to a strong start, and with so much support across the industry.

“From the very beginning, Akamai has been committed to supporting Let’s Encrypt’s vision of enabling greater use of SSL/TLS across the internet,” says Stephen Ludin, Chief Architect at Akamai. “This milestone is confirmation of Let’s Encrypt’s ability to execute on that vision and have a tremendous impact to the Internet ecosystem.”

“Cisco is committed to improving the security of the Internet, not only for our customers and partners, but for everyone else as well,” says David Ward, CTO of Engineering and Chief Architect at Cisco. “Let’s Encrypt has been doing impressive work toward that goal. Our support of this community towards real-time, on-demand certificates will make the Internet more secure.”

“We’re very proud to be a Gold Sponsor for Let’s Encrypt which leverages our industry-leading hardware security modules to protect their certificate authority system,” says Todd Moore, Vice President of Encryption Product Management at Gemalto. “Encryption by default is critical to privacy and security, and by working with Let’s Encrypt Gemalto is helping to deliver trust for the digital services that billions of people use every day.”

Let’s Encrypt depends on industry and community support. Please consider getting involved, and if your company or organization would like to sponsor Let’s Encrypt please email us at sponsor@letsencrypt.org.

ISRG Legal Transparency Report, July 2015 - December 2015

Fri, 01 Apr 2016 00:00:00 -0700

The trust of our users is ISRG’s most critical asset. Transparency regarding legal requests is an important part of making sure our users can trust us, and to that end we will be publishing reports twice annually. Reports will be published three months after the period covered in order to allow us time to research all requests and orders received during the period.

Download Legal Transparency Report, July 2015 - December 2015

New Name, New Home for the Let's Encrypt Client Software

Wed, 09 Mar 2016 05:00:00 -0800

Update: Added clarification that only the Let’s Encrypt client software is changing its name and host. The Let’s Encrypt certificate authority and associated services are not changing names or relocating.

Over the next few months the Let’s Encrypt client software will transition to a new name, soon to be announced, and a new home at the Electronic Frontier Foundation (EFF).

This change does not affect the Let’s Encrypt certificate authority (CA) or associated services, which will retain the Let’s Encrypt name and continue to be hosted by the Internet Security Research Group.

The goal of Let’s Encrypt is to make turning on HTTPS as easy as possible. To accomplish that, it’s not enough to fully automate certificate issuance on the certificate authority (CA) side - we have to fully automate on the client side as well. The Let’s Encrypt client is now being used by hundreds of thousands of websites and we expect it to continue to be a popular choice for sites that are run from a single server or VPS.

That said, the web server ecosystem is complex, and it would be impossible for any particular client to serve everyone well. As a result, the Let’s Encrypt community has created dozens of clients to meet many diverse needs. Moving forward, we feel it would be best for Let’s Encrypt to focus on promoting a generally healthy client and protocol ecosystem and for our client to move to the EFF. This will also allow us to focus our engineering efforts on running a reliable and rapidly growing CA server infrastructure.

The Let’s Encrypt client goes further than most other clients in terms of end-to-end automation and extensibility, both getting certificates and in many cases installing them. This is an important strategy since major servers don’t yet have built-in support, and we want to make sure it’s given a proper chance to thrive. The EFF has led development of the Let’s Encrypt client from the beginning, and they are well-qualified to continue pursuing this strategy.

The rename is happening for reasons that go beyond the move to the EFF. One additional reason for the rename is that we want the client to be distributable and customisable without having to create a complex process for deciding whether customized variants are appropriate for use with Let’s Encrypt trademarks. Another reason is that we want it to be clear that the client can work with any ACME-enabled CA in the future, not just Let’s Encrypt.

We expect the client to do well at the EFF and continue to be used by many people to get certificates from Let’s Encrypt.

Our Millionth Certificate

Tue, 08 Mar 2016 04:00:00 -0800

Let’s Encrypt has issued its millionth certificate. Our first million certificates are helping to secure approximately 2.4 million domains. This milestone means a lot to a team that started building a CA from scratch 16 months ago with an aim to have a real impact on the security of the Web as soon as possible.

We want to see HTTPS become the default on the Web, and today’s occasion gives us confidence that we’re going to get there - much faster than even we predicted. We’re growing at a current rate of more than 100,000 certificates per week and don’t see this slowing down anytime soon. This is dramatic and very rapid change for the Web.

Our rapid growth is due to strong demand for an easy-to-use, low-cost, widely trusted, and truly global solution for certificate issuance and management. We also received a considerable boost from industry endorsement, with major hosting companies like OVH, Wordpress.com, Gandi, Dreamhost, and Digital Ocean helping many sites move to HTTPS with Let’s Encrypt.

HTTPS has been around for a long time but according to Firefox telemetry only ~40% of websites and ~65% of transactions used HTTPS at the end of 2015. Those numbers should both be 100% if the Web is to provide the level of privacy and security that people expect, and Let’s Encrypt is going to lead the way.

Let’s Encrypt depends on support from a wide variety of individuals and organizations. Please consider getting involved, and if your company or organization would like to sponsor Let’s Encrypt please email us at sponsor@letsencrypt.org.

OVH Sponsors Let's Encrypt

Mon, 21 Dec 2015 09:00:00 -0800

We’re pleased to announce that OVH has become a Platinum sponsor of Let’s Encrypt.

According to OVH CTO and Founder Octave Klaba, “OVH is delighted to become a Platinum sponsor. With Let’s Encrypt, OVH will be able to set a new standard for security by offering end-to-end encrypted communications by default to all its communities.”

The Web is an increasingly integral part of our daily lives, and encryption by default is critical in order to provide the degree of security and privacy that people expect. Let’s Encrypt’s mission is to encrypt the Web and our sponsors make pursuing that mission possible.

OVH’s sponsorship will help us to pay for staff and other operation costs in 2016.

If your company or organization would like to sponsor Let’s Encrypt, please email us at sponsor@letsencrypt.org.

Entering Public Beta

Thu, 03 Dec 2015 10:00:00 -0800

We’re happy to announce that Let’s Encrypt has entered Public Beta. Invitations are no longer needed in order to get free certificates from Let’s Encrypt.

It’s time for the Web to take a big step forward in terms of security and privacy. We want to see HTTPS become the default. Let’s Encrypt was built to enable that by making it as easy as possible to get and manage certificates.

We’d like to thank everyone who participated in the Limited Beta. Let’s Encrypt issued over 26,000 certificates during the Limited Beta period. This allowed us to gain valuable insight into how our systems perform, and to be confident about moving to Public Beta.

We’d also like to thank all of our sponsors for their support. We’re happy to have announced earlier today that Facebook is our newest Gold sponsor.

We have more work to do before we’re comfortable dropping the beta label entirely, particularly on the client experience. Automation is a cornerstone of our strategy, and we need to make sure that the client works smoothly and reliably on a wide range of platforms. We’ll be monitoring feedback from users closely, and making improvements as quickly as possible.

Instructions for getting a certificate with the Let’s Encrypt client can be found here.

Let’s Encrypt Community Support is an invaluable resource for our community, we strongly recommend making use of the site if you have any questions about Let’s Encrypt.

Facebook Sponsors Let's Encrypt

Thu, 03 Dec 2015 09:00:00 -0800

We’re happy to share today that Facebook is the newest Gold sponsor of Let’s Encrypt. Facebook has taken multiple important steps to support and advance encryption this year, and we are glad to see Let’s Encrypt as the latest example.

According to Alex Stamos, Chief Security Officer at Facebook, “Making it easier for websites to deploy HTTPS encryption is an important step in improving the security of the whole internet, and Facebook is proud to support this effort.”

Facebook’s sponsorship will help us produce a greater impact as we open up our public beta today and usher in more participants over the coming months.

If your company or organization would like to sponsor Let’s Encrypt, please email us at sponsor@letsencrypt.org.

Public Beta: December 3, 2015

Thu, 12 Nov 2015 07:00:00 -0800

Let’s Encrypt will enter Public Beta on December 3, 2015. Once we’ve entered Public Beta our systems will be open to anyone who would like to request a certificate. There will no longer be a requirement to sign up and wait for an invitation.

Our Limited Beta started on September 12, 2015. We’ve issued over 11,000 certificates since then, and this operational experience has given us confidence that our systems are ready for an open Public Beta.

Why ninety-day lifetimes for certificates?

Mon, 09 Nov 2015 07:00:00 -0800

We’re sometimes asked why we only offer certificates with ninety-day lifetimes. People who ask this are usually concerned that ninety days is too short and wish we would offer certificates lasting a year or more, like some other CAs do.

Ninety days is nothing new on the Web. According to Firefox Telemetry, 29% of TLS transactions use ninety-day certificates. That’s more than any other lifetime. From our perspective, there are two primary advantages to such short certificate lifetimes:

They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.
They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenience than longer ones.

For these reasons, we do not offer certificates with lifetimes longer than ninety days. We realize that our service is young, and that automation is new to many subscribers, so we chose a lifetime that allows plenty of time for manual renewal if necessary. We recommend that subscribers renew every sixty days. Once automated renewal tools are widely deployed and working well, we may consider even shorter lifetimes.

The CA's Role in Fighting Phishing and Malware

Thu, 29 Oct 2015 07:00:00 -0700

Since we announced Let’s Encrypt we’ve often been asked how we’ll ensure that we don’t issue certificates for phishing and malware sites. The concern most commonly expressed is that having valid HTTPS certificates helps these sites look more legitimate, making people more likely to trust them.

Deciding what to do here has been tough. On the one hand, we don’t like these sites any more than anyone else does, and our mission is to help build a safer and more secure Web. On the other hand, we’re not sure that certificate issuance (at least for Domain Validation) is the right level on which to be policing phishing and malware sites in 2015. This post explains our thinking in order to encourage a conversation about the CA ecosystem’s role in fighting these malicious sites.

CAs Make Poor Content Watchdogs

Let’s Encrypt is going to be issuing Domain Validation (DV) certificates. On a technical level, a DV certificate asserts that a public key belongs to a domain – it says nothing else about a site’s content or who runs it. DV certificates do not include any information about a website’s reputation, real-world identity, or safety. However, many people believe the mere presence of DV certificate ought to connote at least some of these things.

Treating a DV certificate as a kind of “seal of approval” for a site’s content is problematic for several reasons.

First, CAs are not well positioned to operate anti-phishing and anti-malware operations – or to police content more generally. They simply do not have sufficient ongoing visibility into sites’ content. The best CAs can do is check with organizations that have much greater content awareness, such as Microsoft and Google. Google and Microsoft consume vast quantities of data about the Web from massive crawling and reporting infrastructures. This data allows them to use complex machine learning algorithms (developed and operated by dozens of staff) to identify malicious sites and content.

Even if a CA checks for phishing and malware status with a good API, the CA’s ability to accurately express information regarding phishing and malware is extremely limited. Site content can change much faster than certificate issuance and revocation cycles, phishing and malware status can be page-specific, and certificates and their related browser UIs contain little, if any, information about phishing or malware status. When a CA doesn’t issue a certificate for a site with phishing or malware content, users simply don’t see a lock icon. Users are much better informed and protected when browsers include anti-phishing and anti-malware features, which typically do not suffer from any of these limitations.

Another issue with treating DV certificates as a “seal of approval” for site content is that there is no standard for CA anti-phishing and anti-malware measures beyond a simple blacklist of high-value domains, so enforcement is inconsistent across the thousands of CAs trusted by major browsers. Even if one CA takes extraordinary measures to weed out bad sites, attackers can simply shop around to different CAs. The bad guys will almost always be able to get a certificate and hold onto it long enough to exploit people. It doesn’t matter how sophisticated the best CA anti-phishing and anti-malware programs are, it only matters how good the worst are. It’s a “find the weakest link” scenario, and weak links aren’t hard to find.

Browser makers have realized all of this. That’s why they are pushing phishing and malware protection features, and evolving their UIs to more accurately reflect the assertions that certificates actually make.

TLS No Longer Optional

When they were first developed in the 1990s, HTTPS and SSL/TLS were considered “special” protections that were only necessary or useful for particular kinds of websites, like online banks and shopping sites accepting credit cards. We’ve since come to realize that HTTPS is important for almost all websites. It’s important for any website that allows people to log in with a password, any website that tracks its users in any way, any website that doesn’t want its content altered, and for any site that offers content people might not want others to know they are consuming. We’ve also learned that any site not secured by HTTPS can be used to attack other sites.

TLS is no longer the exception, nor should it be. That’s why we built Let’s Encrypt. We want TLS to be the default method for communication on the Web. It should just be a fundamental part of the fabric, like TCP or HTTP. When this happens, having a certificate will become an existential issue, rather than a value add, and content policing mistakes will be particularly costly. On a technical level, mistakes will lead to significant down time due to a slow issuance and revocation cycle, and features like HSTS. On a philosophical and moral level, mistakes (innocent or otherwise) will mean censorship, since CAs would be gatekeepers for online speech and presence. This is probably not a good role for CAs.

Our Plan

At least for the time being, Let’s Encrypt is going to check with the Google Safe Browsing API before issuing certificates, and refuse to issue to sites that are flagged as phishing or malware sites. Google’s API is the best source of phishing and malware status information that we have access to, and attempting to do more than query this API before issuance would almost certainly be wasteful and ineffective.

We’re going to implement this phishing and malware status check because many people are not comfortable with CAs entirely abandoning anti-phishing and anti-malware efforts just yet, even for DV certificates. We’d like to continue the conversation for a bit longer before we abandon what many people perceive to be an important CA behavior, even though we disagree.

Conclusion

The fight against phishing and malware content is an important one, but it does not make sense for CAs to be on the front lines, at least when it comes to DV certificates. That said, we’re going to implement checks against the Google Safe Browsing API while we continue the conversation.

We look forward to hearing what you think. Please let us know.