Let's Encrypt - Free SSL/TLS Certificates

Launching Our Crowdfunding Campaign

Tue, 01 Nov 2016 00:00:00 -0700

Today we kicked off our first crowdfunding campaign with the goal of raising enough funds to cover about one month of our operations - $200,000. That amount covers the operational and engineering staff, the hardware and the software, and general operating expenses needed to securely and reliably issue and manage many millions of certificates.

We decided to run a crowdfunding campaign for a couple of reasons. First, there is a gap between the funds we’ve raised and what we need for next year. Second, we believe individual supporters from our community can come to represent a significant diversification of our annual revenue sources, in addition to corporate sponsorship and grants.

We will provide updates on our progress throughout the campaign via Twitter (@letsencrypt).

Thank you for your support!

Our First Grant: The Ford Foundation

Thu, 27 Oct 2016 00:00:00 -0700

We are proud to announce that The Ford Foundation has awarded us a grant to help our growing operations.

The Ford Foundation is a major philanthropic entity both in the US and globally. One of its programmatic areas, Internet Freedom, is focused on creating a more open and inclusive Internet experience for all people. Our relationship with Ford was born out of this mutual desire.

According to Michael Brennan, Ford Foundation Internet Freedom Program Officer, “We are thrilled to be able to support the growth of a Web that meets the needs of all its users through Let’s Encrypt.”

This grant will support various software development staff and activities, including the work we recently did to add support for Internationalized Domain Name (IDN) certificates.

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

Squarespace OCSP Stapling Implementation

Mon, 24 Oct 2016 00:00:00 -0700

We’re excited that Squarespace has decided to protect the millions of sites they host with HTTPS! While talking with their team we learned they were deploying OCSP Stapling from the get-go, and we were impressed. We asked them to share their experience with our readers in our first guest blog post (hopefully more to come).

- Josh Aas, Executive Director, ISRG / Let’s Encrypt

OCSP stapling is an alternative approach to the Online Certificate Status Protocol (OCSP) for checking the revocation status of certificates. It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses by appending (“stapling”) a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA. The certificate holder queries the OCSP responder at regular intervals and caches the responses.

Traditional OCSP requires the CA to provide responses to each client that requests certificate revocation information. When a certificate is issued for a popular website, a large amount of queries start hitting the CA’s OCSP responder server. This poses a privacy risk because information must pass through a third party and the third party is able to determine who browsed which site at what time. It can also create performance problems, since most browsers will contact the OCSP responder before loading anything on the web page. OCSP stapling is efficient because the user doesn’t have to make a separate connection to the CA, and it’s safe because the OCSP response is digitally signed so it cannot be modified without detection.

OCSP Stapling @ Squarespace

As we were planning our roll out of SSL for all custom domains on the Squarespace platform, we decided that we wanted to support OCSP stapling at time of launch. A reverse proxy built by our Edge Infrastructure team is responsible for terminating all SSL traffic, it’s written in Java and is powered by Netty. Unfortunately, the Java JDK 8 only has preliminary, client-only, OCSP stapling support. JDK 9 introduces OCSP stapling with JEP 249, but it is not available yet.

Our reverse proxy does not use the JDK’s SSL implementation. Instead, we use OpenSSL via netty-tcnative. At this time, neither the original tcnative nor Netty’s fork have OCSP stapling support. However, the tcnative library exposes the inner workings of OpenSSL, including the address pointers for the SSL context and engine. We were able to use JNI to extend the netty-tcnative library and add OCSP stapling support using the tlsext_status OpenSSL C functions. Our extension is a standalone library but we could equally well fold it into the netty-tcnative library itself. If there is interest, we can contribute it upstream as part of Netty’s next API-breaking development cycle.

One of the goals of our initial OCSP stapling implementation was to take the biggest edge off of the OCSP responder’s operator, in this case Let’s Encrypt. Due to the nature of the website traffic on our platform, we have a very long tail. At least to start, we don’t pre-fetch and cache all OCSP responses. We decided to fetch OCSP responses asynchronously and we try to do it only if more than one client is going to use it in the foreseeable future. Bloom filters are utilized to identify “one-hit wonders” that are not worthy of being cached.

Squarespace invests in the security of our customers’ websites and their visitors. We will continue to make refinements to our OCSP stapling implementation to eventually have OCSP staples on all requests. For a more in depth discussion about the security challenges of traditional OCSP, we recommend this blog post.

Introducing Internationalized Domain Name (IDN) Support

Fri, 21 Oct 2016 00:00:00 -0700

Let’s Encrypt is pleased to introduce support for issuing certificates that contain Internationalized Domain Names (IDNs). This means that our users around the world can now get free Let’s Encrypt certificates for domains containing characters outside of the ASCII set, which is built primarily for the English language.

We’re excited about this feature because our goal is to serve the entire Web, including those who want to use domains with language-specific characters. This feature was also commonly requested by our community.

There are more details on how to request a certificate containing IDNs at our community forum. Visit our Getting Started page for information on how to request certificates in general.

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, January 2016 - June 2016

Sat, 01 Oct 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, January 2016 - June 2016

What It Costs to Run Let's Encrypt

Tue, 20 Sep 2016 00:00:00 -0700

Today we’d like to explain what it costs to run Let’s Encrypt. We’re doing this because we strive to be a transparent organization, we want people to have some context for their contributions to the project, and because it’s interesting.

Let’s Encrypt will require about $2.9M USD to operate in 2017. We believe this is an incredible value for a secure and reliable service that is capable of issuing certificates globally, to every server on the Web free of charge.

We’re currently working to raise the money we need to operate through the next year. Please consider donating or becoming a sponsor if you’re able to do so! In the event that we end up being able to raise more money than we need to just keep Let’s Encrypt running we can look into adding other services to improve access to a more secure and privacy-respecting Web.

Here’s how our 2017 budget breaks down:

Expense	Cost
Staffing	$2.06M USD
Hardware/Software	$0.20M USD
Hosting/Auditing	$0.30M USD
Legal/Administrative	$0.35M USD
Total	$2.91M USD

Staffing is our dominant cost. We currently have eight full time employees, plus two full time staff that are employed by other entities (Mozilla and EFF). This includes five operations/sysadmin staff, three software developers, one communications and fundraising person, and an executive director. Our 2017 budget covers salary and benefits for ten employees.

Our systems administration staff are at the heart of our day to day operations. They are responsible for building and improving our server, networking, and deployed software infrastructure, as well as monitoring the systems every hour of every day. It’s the critical 24/7 nature of the work that makes this our biggest team. Any issues need to be dealt with immediately, ideally with multiple people on hand.

Our software developers work primarily on boulder, our open source CA software. We needed to write our own software in order to create a secure, reliable, and fully-automated CA that is capable of issuing and managing enough certificates to serve the entire Web. Our software development staff also allow us to support new features much more quickly than we could if we relied on third party software for implementation.

The majority of our administrative support (e.g. HR, payroll, accounting) is provided by the Linux Foundation, so we don’t hire for those roles and related expenses come in under the “Legal/Administrative” category.

Hardware expenses include compute, storage, networking, and HSM hardware, as well as the associated support contracts. There is quite a bit of duplication for redundancy. Software expenses are low since the majority of the software we use is freely available open source software.

Hosting costs include space in two different highly secure geographically separated rooms inside secure data centers, as well as internet connections and power. The hardware and physical infrastructure we have in place is capable of issuing hundreds of millions of certificates - enough for every server on the Web. We need to maintain strong physical control over all hardware and infrastructure related to certificate issuance and management for security and auditing reasons.

Auditing costs include the required annual WebTrust audits as well as third party expert security review and testing. The third party security audits include code review, infrastructure review, penetration testing, and ACME protocol analysis. We are not required to do third party auditing beyond the WebTrust audits, but it would be irresponsible of us not to.

Legal costs go towards attorney time, primarily in the areas of corporate governance, contract development and review, and trademarks. Administrative costs include HR, payroll and benefits management, accounting and tax services, as well as travel and other miscellaneous operating costs.

Our 2016 budget is very similar to our 2017 budget, the major difference being that we will only spend approximately $2.0M USD due to a number of our staff starting after the beginning of the year. We will pay full staffing costs next year because all of the staff that joined us in 2016 will be on our payroll for the entirety of 2017.

Currently, the majority of our funding comes from corporate sponsorships. If your company or organization would like to sponsor Let’s Encrypt please email us at sponsor@letsencrypt.org. We’re working to make grants and individual contributions more significant sources of income over the next year.

We’re grateful for the industry and community support that we receive, and we look forward to continuing to create a more secure and privacy-respecting Web!

Let's Encrypt Root to be Trusted by Mozilla

Fri, 05 Aug 2016 00:00:00 -0700

The Let’s Encrypt root key (ISRG Root X1) will be trusted by default in Firefox 50, which is scheduled to ship in Q4 2016. Acceptance into the Mozilla root program is a major milestone as we aim to rely on our own root for trust and have greater independence as a certificate authority (CA).

Public CAs need their certificates to be trusted by browsers and devices. CAs that want to issue independently under their own root accomplish this by either buying an existing trusted root, or by creating a new root and working to get it trusted. Let’s Encrypt chose to go the second route.

Getting a new root trusted and propagated broadly can take 3-6 years. In order to start issuing widely trusted certificates as soon as possible, we partnered with another CA, IdenTrust, which has a number of existing trusted roots. As part of that partnership, an IdenTrust root “vouches for” the certificates that we issue, thus making our certificates trusted. We’re incredibly grateful to IdenTrust for helping us to start carrying out our mission as soon as possible.

Chain of Trust Between Firefox and Let's Encrypt Certificates

However, our plan has always been to operate as an independently trusted CA. Having our root trusted directly by the Mozilla root program represents significant progress towards that independence.

We have also applied to the Microsoft, Apple, Google, Oracle and Blackberry root programs. We look forward to acceptance into these programs as well.

Full Support for IPv6

Tue, 26 Jul 2016 00:00:00 -0700

Let’s Encrypt is happy to announce full support for IPv6.

As IPv4 address space is exhausted, more and more people are deploying services that are only reachable via IPv6. Adding full support for IPv6 allows us to serve more people and organizations, which is important if we’re going to encrypt the entire Web.

IPv6 is an exciting step forward which will allow the Internet to grow and reach more people. You can learn more about it by watching this video from Google’s Chief Internet Evangelist, Vint Cerf. We’re looking forward to the day when both TLS and IPv6 are ubiquitous.

Defending Our Brand [Updated]

Thu, 23 Jun 2016 00:00:00 -0700

Update, June 24 2016

We have confirmed that Comodo submitted Requests for Express Abandonment for all three trademark registration applications in question. We’re happy to see this positive step towards resolution, and will continue to monitor the requests as they make their way through the system.

We’d like to thank our community for their support.

Some months ago, it came to our attention that Comodo Group, Inc., is attempting to register at least three trademarks for the term “Let’s Encrypt,” for a variety of CA-related services [1][2][3]. These trademark applications were filed long after the Internet Security Research Group (ISRG) started using the name Let’s Encrypt publicly in November of 2014, and despite the fact Comodo’s “intent to use” trademark filings acknowledge that it has never used “Let’s Encrypt” as a brand.

We’ve forged relationships with millions of websites and users under the name Let’s Encrypt, furthering our mission to make encryption free, easy, and accessible to everyone. We’ve also worked hard to build our unique identity within the community and to make that identity a reliable indicator of quality. We take it very seriously when we see the potential for our users to be confused, or worse, the potential for a third party to damage the trust our users have placed in us by intentionally creating such confusion. By attempting to register trademarks for our name, Comodo is actively attempting to do just that.

Since March of 2016 we have repeatedly asked Comodo to abandon their “Let’s Encrypt” applications, directly and through our attorneys, but they have refused to do so. We are clearly the first and senior user of “Let’s Encrypt” in relation to Internet security, including SSL/TLS certificates – both in terms of length of use and in terms of the widespread public association of that brand with our organization.

If necessary, we will vigorously defend the Let’s Encrypt brand we’ve worked so hard to build. That said, our organization has limited resources and a protracted dispute with Comodo regarding its improper registration of our trademarks would significantly and unnecessarily distract both organizations from the core mission they should share: creating a more secure and privacy-respecting Web. We urge Comodo to do the right thing and abandon its “Let’s Encrypt” trademark applications so we can focus all of our energy on improving the Web.

[1] “Let’s Encrypt” Trademark Registration Application

[2] “Let’s Encrypt With Comodo” Trademark Registration Application

[3] “Comodo Let’s Encrypt” Trademark Registration Application

Progress Towards 100% HTTPS, June 2016

Wed, 22 Jun 2016 00:00:00 -0700

Our goal with Let’s Encrypt is to get the Web to 100% HTTPS. We’d like to give a quick progress update.

Let’s Encrypt has issued more than 5 million certificates in total since we launched to the general public on December 3, 2015. Approximately 3.8 million of those are active, meaning unexpired and unrevoked. Our active certificates cover more than 7 million unique domains.

A couple of different factors have contributed heavily to this growth. The first is large-scale deployments from companies such as OVH, WordPress.com, Akamai, Shopify, Dreamhost, and Bitly. The second is our ability to serve individual sites globally with a focus on ease-of-use. If we’re going to get to 100% HTTPS we need to reach the “long tail” of the Web, which is in many ways more challenging due to the number of parties involved and widely varying degrees of technical competency.

Our progress is accelerating the growth of HTTPS on the Web in general. When we launched in December of 2015, 39.5% of page loads on the Web used HTTPS (as measured by Firefox Telemetry). By mid-April 2016 that number was up to 42% and today it stands at 45%.

This is an incredible rate of change for the Web. We’re really excited about our early progress. Getting to 50% HTTPS page loads in 2016 used to seem like an overly ambitious goal but now it seems within reach. Let’s get there!