letsencrypt - sfeed_tests - sfeed tests and RSS and Atom files
(HTM) git clone git://git.codemadness.org/sfeed_tests
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
letsencrypt (65596B)
---
1 <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
2 <channel>
3 <title>Let's Encrypt - Free SSL/TLS Certificates</title>
4 <link>https://letsencrypt.org/</link>
5 <description> Let's Encrypt is a free, automated, and open certificate
6 authority brought to you by the nonprofit <a href="https://www.abetterinternet.org/">Internet Security Research Group (ISRG)</a>.
7 </description>
8 <language>en-US</language>
9 <lastBuildDate>Fri, 18 Sep 2020 00:00:00 +0000</lastBuildDate>
10 <generator>Hugo v0.67.1</generator>
11 <atom:link href="https://letsencrypt.org/feed.xml" rel="self" type="application/rss+xml" />
12 <item>
13 <title>Let's Encrypt's New Root and Intermediate Certificates</title>
14 <link>https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html</link>
15 <pubDate>Thu, 17 Sep 2020 00:00:00 +0000</pubDate>
16 <description><![CDATA[<p>On Thursday, September 3rd, 2020, Let’s Encrypt issued six new certificates:
17 one root, four intermediates, and one cross-sign. These new certificates are
18 part of our larger plan to improve privacy on the web, by making ECDSA
19 end-entity certificates widely available, and by making certificates smaller.</p>
20 <p>Given that we issue <a href="https://letsencrypt.org/stats/">1.5 million certificates every day</a>,
21 what makes these ones special? Why did we issue them? How did we issue them?
22 Let’s answer these questions, and in the process take a tour of how
23 Certificate Authorities think and work.</p>
24 <h1 id="the-backstory">The Backstory</h1>
25 <p>Every publicly-trusted Certificate Authority (such as Let’s Encrypt) has at
26 least one root certificate which is incorporated into various browser and OS
27 vendors’ (e.g. Mozilla, Google) trusted root stores. This is what allows
28 users who receive a certificate from a website to confirm that the
29 certificate was issued by an organization that their browser trusts. But root
30 certificates, by virtue of their widespread trust and long lives, must have
31 their corresponding private key carefully protected and stored offline, and
32 therefore can’t be used to sign things all the time. So every Certificate
33 Authority (CA) also has some number of “intermediates”, certificates which
34 are able to issue additional certificates but are not roots, which they use
35 for day-to-day issuance.</p>
36 <p>For the last <a href="https://letsencrypt.org/2015/06/04/isrg-ca-certs.html">five years</a>,
37 Let’s Encrypt has had one root: the <a href="https://crt.sh/?caid=7394">ISRG Root X1</a>,
38 which has a 4096-bit RSA key and is valid until 2035.</p>
39 <p>Over that same time, we’ve had four intermediates: the Let’s Encrypt
40 Authorities <a href="https://crt.sh/?caid=7395">X1</a>, <a href="https://crt.sh/?caid=9745">X2</a>,
41 <a href="https://crt.sh/?caid=16418">X3</a>, and <a href="https://crt.sh/?caid=16429">X4</a>. The
42 first two were issued when Let’s Encrypt first began operations in 2015, and
43 were valid for 5 years. The latter two were issued about a year later, in
44 2016, and are also valid for 5 years, expiring about this time next year. All
45 of these intermediates use 2048-bit RSA keys. In addition,
46 <a href="https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html">all of these intermediates are cross-signed</a>
47 by IdenTrust’s DST Root CA X3, another root certificate controlled by a
48 different certificate authority which is trusted by most root stores.</p>
49 <p>Finally, we also have the <a href="https://crt.sh/?id=2929281974">ISRG Root OCSP X1</a>
50 certificate. This one is a little different – it doesn’t issue any
51 certificates. Instead, it signs Online Certificate Status Protocol (OCSP)
52 responses that indicate the intermediate certificates have not been revoked.
53 This is important because the only other thing capable of signing such
54 statements is our root itself, and as mentioned above, the root needs to stay
55 offline and safely secured.</p>
56 <p><img src="/images/2020-09-17-hierarchy-pre-sept-2020.png" alt="Let’s Encrypt’s hierarchy as of August 2020" title="Let's Encrypt's hierarchy as of August 2020"></p>
57 <h1 id="the-new-certificates">The New Certificates</h1>
58 <p>For starters, we’ve issued two new 2048-bit RSA intermediates which we’re
59 calling <a href="https://crt.sh/?caid=183267">R3</a> and
60 <a href="https://crt.sh/?caid=183268">R4</a>. These are both issued by ISRG Root X1, and
61 have 5-year lifetimes. They will also be cross-signed by IdenTrust. They’re
62 basically direct replacements for our current X3 and X4, which are expiring
63 in a year. We expect to switch our primary issuance pipeline to use R3 later
64 this year, which won’t have any real effect on issuance or renewal.</p>
65 <p>The other new certificates are more interesting. First up, we have the new
66 <a href="https://crt.sh/?caid=183269">ISRG Root X2</a>, which has an ECDSA P-384 key
67 instead of RSA, and is valid until 2040. Issued from that, we have two new
68 intermediates, <a href="https://crt.sh/?caid=183283">E1</a> and
69 <a href="https://crt.sh/?caid=183284">E2</a>, which are both also ECDSA and are valid
70 for 5 years.</p>
71 <p>Notably, these ECDSA intermediates are not cross-signed by IdenTrust’s DST
72 Root CA X3. Instead, the ISRG Root X2 itself is
73 <a href="https://crt.sh/?id=3334561878">cross-signed by our existing ISRG Root X1</a>.
74 An astute observer might also notice that we have not issued an OCSP Signing
75 Certificate from ISRG Root X2.</p>
76 <p><img src="/images/2020-09-17-hierarchy-post-sept-2020.png" alt="Let’s Encrypt’s hierarchy as of September 2020" title="Let's Encrypt's hierarchy as of September 2020"></p>
77 <p>Now that we have the technical details out of the way, let’s dive in to <em>why</em>
78 the new hierarchy looks the way it does.</p>
79 <h1 id="why-we-issued-an-ecdsa-root-and-intermediates">Why We Issued an ECDSA Root and Intermediates</h1>
80 <p>There are lots of <a href="https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/">other articles</a>
81 you can read about the benefits of ECDSA (smaller key sizes for the same
82 level of security; correspondingly faster encryption, decryption, signing,
83 and verification operations; and more). But for us, the big benefit comes
84 from their smaller certificate sizes.</p>
85 <p>Every connection to a remote domain over https:// requires a TLS handshake.
86 Every TLS handshake requires that the server provide its certificate.
87 Validating that certificate requires a certificate chain (the list of all
88 intermediates up to but not including a trusted root), which is also usually
89 provided by the server. This means that every connection – and a page
90 covered in ads and tracking pixels might have dozens or hundreds – ends up
91 transmitting a large amount of certificate data. And every certificate
92 contains both its own public key and a signature provided by its issuer.</p>
93 <p>While a 2048-bit RSA public key is about 256 bytes long, an ECDSA P-384
94 public key is only about 48 bytes. Similarly, the RSA signature will be
95 another 256 bytes, while the ECDSA signature will only be 96 bytes. Factoring
96 in some additional overhead, that’s a savings of nearly 400 bytes per
97 certificate. Multiply that by how many certificates are in your chain, and
98 how many connections you get in a day, and the bandwidth savings add up fast.</p>
99 <p>These savings are a public benefit both for our subscribers – who can be
100 sites for which bandwidth can be a meaningful cost every month – and for
101 end-users, who may have limited or metered connections. Bringing privacy to
102 the whole Web doesn’t just mean making certificates available, it means
103 making them efficient, too.</p>
104 <p>As an aside: since we’re concerned about certificate sizes, we’ve also taken
105 a few other measures to save bytes in our new certificates. We’ve shortened
106 their Subject Common Names from “Let’s Encrypt Authority X3” to just “R3”,
107 relying on the previously-redundant Organization Name field to supply the
108 words “Let’s Encrypt”. We’ve shortened their Authority Information Access
109 Issuer and CRL Distribution Point URLs, and we’ve dropped their CPS and OCSP
110 urls entirely. All of this adds up to another approximately 120 bytes of
111 savings without making any substantive change to the useful information in
112 the certificate.</p>
113 <h1 id="why-we-cross-signed-the-ecdsa-root">Why We Cross-Signed the ECDSA Root</h1>
114 <p>Cross-signing is an important step, bridging the gap between when a new root
115 certificate is issued and when that root is incorporated into various trust
116 stores. We know that it is going to take 5 years or so for our new ISRG Root
117 X2 to be widely trusted itself, so in order for certificates issued by the E1
118 intermediate to be trusted, there needs to be a cross-sign somewhere in the
119 chain.</p>
120 <p>We had basically two options: we could cross-sign the new ISRG Root X2 from
121 our existing ISRG Root X1, or we could cross-sign the new E1 and E2
122 intermediates from ISRG Root X1. Let’s examine the pros and cons of each.</p>
123 <p>Cross-signing the new ISRG Root X2 certificate means that, if a user has ISRG
124 Root X2 in their trust store, then their full certificate chain will be 100%
125 ECDSA, giving them fast validation, as discussed above. And over the next few
126 years, as ISRG Root X2 is incorporated into more and more trust stores,
127 validation of ECDSA end-entity certificates will get faster without users or
128 websites having to change anything. The tradeoff though is that, as long as
129 X2 isn’t in trust stores, user agents will have to validate a chain with two
130 intermediates: both E1 and X2 chaining up to the X1 root. This takes more
131 time during certificate validation.</p>
132 <p>Cross-signing the intermediates directly has the opposite tradeoff. On the
133 one hand, all of our chains will be the same length, with just one
134 intermediate between the subscriber certificate and the widely-trusted ISRG
135 Root X1. But on the other hand, when the ISRG Root X2 does become widely
136 trusted, we’d have to <a href="https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html">go through another chain switch</a>
137 in order for anyone to gain the benefits of an all-ECDSA chain.</p>
138 <p>In the end, we decided that providing the option of all-ECDSA chains was more
139 important, and so opted to go with the first option, and cross-sign the ISRG
140 Root X2 itself.</p>
141 <h1 id="why-we-didn-t-issue-an-ocsp-responder">Why We Didn’t Issue an OCSP Responder</h1>
142 <p>The Online Certificate Status Protocol is a way for user agents to discover,
143 in real time, whether or not a certificate they’re validating has been
144 revoked. Whenever a browser wants to know if a certificate is still valid, it
145 can simply hit a URL contained within the certificate itself and get a yes or
146 no response, which is signed by another certificate and can be similarly
147 validated. This is great for end-entity certificates, because the responses
148 are small and fast, and any given user might care about (and therefore have
149 to fetch) the validity of wildly different sets of certificates, depending on
150 what sites they visit.</p>
151 <p>But intermediate certificates are a tiny subset of all certificates in the
152 wild, are generally well-known, and are rarely revoked. Because of this, it
153 can be much more efficient to simply maintain a Certificate Revocation List
154 (CRL) containing validity information for all well-known intermediates. Our
155 intermediate certificates all contain a URL from which a browser can fetch
156 their CRL, and in fact some browsers even aggregate these into their own CRLs
157 which they distribute with each update. This means that checking the
158 revocation status of intermediates doesn’t require an extra network round
159 trip before you can load a site, resulting in a better experience for
160 everyone.</p>
161 <p>In fact, a recent change (<a href="https://cabforum.org/2020/07/16/ballot-sc31-browser-alignment/">ballot SC31</a>)
162 to the Baseline Requirements, which govern CAs, has made it so intermediate
163 certificates are no longer required to include an OCSP URL; they can now have
164 their revocation status served solely by CRL. And as noted above, we have
165 removed the OCSP URL from our new intermediates. As a result, we didn’t need
166 to issue an OCSP responder signed by ISRG Root X2.</p>
167 <h1 id="putting-it-all-together">Putting It All Together</h1>
168 <p>Now that we’ve shared our new certificates look the way they do, there’s one
169 last thing we’d like to mention: how we actually went about issuing them.</p>
170 <p>The creation of new root and intermediate certificates is a big deal, since
171 their contents are so regulated and their private keys have to be so
172 carefully protected. So much so that the act of issuing new ones is called a
173 “ceremony”. Let’s Encrypt <a href="https://letsencrypt.org/about/">believes strongly in automation</a>,
174 so we wanted our ceremony to require as little human involvement as possible.</p>
175 <p>Over the last few months we’ve built a <a href="https://github.com/letsencrypt/boulder/tree/main/cmd/ceremony">ceremony tool</a>
176 which, given appropriate configuration, can produce all of the desired keys,
177 certificates, and requests for cross-signs. We also built a
178 <a href="https://github.com/letsencrypt/2020-hierarchy-demo">demo</a> of our ceremony,
179 showing what our configuration files would be, and allowing anyone to run it
180 themselves and examine the resulting output. Our SREs put together a replica
181 network, complete with Hardware Security Modules, and practiced the ceremony
182 multiple times to ensure it would work flawlessly. We shared this demo with
183 our technical advisory board, our community, and various mailing lists, and
184 in the process received valuable feedback that actually influenced some of
185 the decisions we’ve talked about above! Finally, on September 3rd, our
186 Executive Director met with SREs at a secure datacenter to execute the whole
187 ceremony, and record it for future audits.</p>
188 <p>And now the ceremony is complete. We’ve updated <a href="https://letsencrypt.org/certificates">our certificates page</a>
189 to include details about all of our new certificates, and are beginning the
190 process of requesting that our new root be incorporated into various trust
191 stores. We intend to begin issuing with our new intermediates over the coming
192 weeks, and will post further announcements in our <a href="https://community.letsencrypt.org/">community forum</a>
193 when we do.</p>
194 <p>We hope that this has been an interesting and informative tour around our
195 hierarchy, and we look forward to continuing to improve the internet one
196 certificate at a time. We’d like to thank IdenTrust for their early and
197 ongoing support of our vision to change security on the Web for the better.</p>
198 <p>We depend on contributions from our community of users and supporters in
199 order to provide our services. If your company or organization would like to
200 <a href="https://letsencrypt.org/become-a-sponsor/">sponsor</a> Let’s Encrypt please
201 email us at <a href="mailto:sponsor@letsencrypt.org">sponsor@letsencrypt.org</a>. We ask that you make an
202 <a href="https://letsencrypt.org/donate/">individual contribution</a> if it is within your
203 means.</p>]]></description>
204 <guid isPermaLink="true">https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html</guid>
205 </item><item>
206 <title>Let's Encrypt Has Issued a Billion Certificates</title>
207 <link>https://letsencrypt.org/2020/02/27/one-billion-certs.html</link>
208 <pubDate>Thu, 27 Feb 2020 00:00:00 +0000</pubDate>
209 <description><![CDATA[<p>We issued our billionth certificate on February 27, 2020. We’re going to use this big round number as an opportunity to reflect on what has changed for us, and for the Internet, leading up to this event. In particular, we want to talk about what has happened since the last time we talked about a big round number of certificates - <a href="https://letsencrypt.org/2017/06/28/hundred-million-certs.html">one hundred million</a>.</p>
210 <p>One thing that’s different now is that the Web is much more encrypted than it was. In June of 2017 approximately 58% of page loads used HTTPS globally, 64% in the United States. Today 81% of page loads use HTTPS globally, and we’re at 91% in the United States! This is an incredible achievement. That’s a lot more privacy and security for everybody.</p>
211 <p>Another thing that’s different is that our organization has grown a bit, but not by much! In June of 2017 we were serving approximately 46M websites, and we did so with 11 full time staff and an annual budget of $2.61M. Today we serve nearly 192M websites with 13 full time staff and an annual budget of approximately $3.35M. This means we’re serving more than 4x the websites with only two additional staff and a 28% increase in budget. The additional staff and budget did more than just improve our ability to scale though - we’ve made improvements across the board to provide even more secure and reliable service.</p>
212 <p>Nothing drives adoption like ease of use, and the foundation for ease of use in the certificate space is our ACME protocol. ACME allows for extensive automation, which means computers can do most of the work. It was also <a href="https://letsencrypt.org/2019/03/11/acme-protocol-ietf-standard.html">standardized as RFC 8555 in 2019</a>, which allows the Web community to confidently build an <a href="https://letsencrypt.org/docs/client-options/">even richer ecosystem of software</a> around it. Today, thanks to our incredible community, there is an ACME client for just about every deployment environment. Certbot is one of our favorites, and they’ve been working hard to make it <a href="https://www.eff.org/deeplinks/2019/10/certbot-usability-case-study-making-it-easier-get-https-certificates">even easier for people to use</a>.</p>
213 <p>When you combine ease of use with incentives, that’s when adoption really takes off. Since 2017 browsers have started requiring HTTPS for more features, and they’ve greatly improved the ways in which they <a href="https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/">communicate</a> <a href="https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/">to their users</a> <a href="https://support.apple.com/en-us/HT209084#122">about the risks</a> of not using HTTPS. When websites put their users at risk by not using HTTPS, major browsers now show stronger warnings. Many sites have responded by deploying HTTPS.</p>
214 <p>Thanks for taking the time to reflect on this milestone with us. As a community we’ve done incredible things to protect people on the Web. Having issued one billion certificates is affirmation of all the progress we’ve made as a community, and we’re excited to keep working with you to create an even more secure and privacy-respecting Web for everyone.</p>
215 <p>We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to <a href="https://letsencrypt.org/become-a-sponsor/">sponsor</a> Let’s Encrypt please email us at <a href="mailto:sponsor@letsencrypt.org">sponsor@letsencrypt.org</a>. We ask that you make an <a href="https://letsencrypt.org/donate/">individual contribution</a> if it is within your means.</p>]]></description>
216 <guid isPermaLink="true">https://letsencrypt.org/2020/02/27/one-billion-certs.html</guid>
217 </item><item>
218 <title>Multi-Perspective Validation Improves Domain Validation Security</title>
219 <link>https://letsencrypt.org/2020/02/19/multi-perspective-validation.html</link>
220 <pubDate>Wed, 19 Feb 2020 00:00:00 +0000</pubDate>
221 <description><![CDATA[<p>At Let’s Encrypt we’re always looking for ways to improve the security and integrity of the Web PKI. We’re proud to launch multi-perspective domain validation today because we believe it’s an important step forward for the domain validation process. To our knowledge we are the first CA to deploy multi-perspective validation at scale.</p>
222 <p>Domain validation is a process that all CAs use to ensure that a certificate applicant actually controls the domain they want a certificate for. Typically the domain validation process involves asking the applicant to place a particular file or token at a controlled location for the domain, such as a particular path or a DNS entry. Then the CA will check that the applicant was able to do so. Historically it looks something like this:</p>
223 <p><img src="/images/2020-02-19-single-perspective-validation.png" alt="System Architecture Diagram"></p>
224 <p>A potential issue with this process is that if a network attacker can hijack or redirect network traffic along the validation path (for the challenge request, or associated DNS queries), then the attacker can trick a CA into incorrectly issuing a certificate. This is precisely what a research team from Princeton demonstrated <a href="https://www.princeton.edu/~pmittal/publications/bgp-tls-usenix18.pdf">can be done with an attack on BGP</a>. Such attacks are rare today, but we are concerned that these attacks will become more numerous in the future.</p>
225 <p>The Border Gateway Protocol (BGP) and most deployments of it are not secure. While there are ongoing efforts to secure BGP, such as RPKI and BGPsec, it may be a long time until BGP hijacking is a thing of the past. We don’t want to wait until we can depend on BGP being secure, so we’ve worked with the research team from Princeton to devise a way to make such attacks more difficult. Instead of validating from one network perspective, we now validate from multiple perspectives as well as from our own data centers:</p>
226 <p><img src="/images/2020-02-19-multiple-perspective-validation.png" alt="System Architecture Diagram"></p>
227 <p>Today we are validating from multiple regions within a single cloud provider. We plan to diversify network perspectives to other cloud providers in the future.</p>
228 <p>This makes the kind of attack described earlier more difficult because an attacker must successfully compromise three different network paths at the same time (the primary path from our data center, and at least two of the three remote paths). It also increases the likelihood that such an attack will be detected by the Internet topology community.</p>
229 <p>We’d like to thank the research groups of Prof. Prateek Mittal and Prof. Jennifer Rexford at Princeton University for their partnership in developing this work. We will continue to work with them to refine the effectiveness of our multiple perspective validation design and implementation. We’d also like to thank <a href="https://www.opentech.fund/">Open Technology Fund</a> for supporting this work.</p>
230 <p>We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to <a href="https://letsencrypt.org/become-a-sponsor/">sponsor</a> Let’s Encrypt please email us at <a href="mailto:sponsor@letsencrypt.org">sponsor@letsencrypt.org</a>. We ask that you make an <a href="https://letsencrypt.org/donate/">individual contribution</a> if it is within your means.</p>]]></description>
231 <guid isPermaLink="true">https://letsencrypt.org/2020/02/19/multi-perspective-validation.html</guid>
232 </item><item>
233 <title>How Let's Encrypt Runs CT Logs</title>
234 <link>https://letsencrypt.org/2019/11/20/how-le-runs-ct-logs.html</link>
235 <pubDate>Wed, 20 Nov 2019 00:00:00 +0000</pubDate>
236 <description><![CDATA[<p>Let’s Encrypt <a href="https://letsencrypt.org/2019/05/15/introducing-oak-ct-log.html">launched a Certificate Transparency (CT) log</a> this past spring. We’re excited to share how we built it in hopes that others can learn from what we did. CT has quickly become an important piece of Internet security infrastructure, but unfortunately it’s not trivial to run a good log. The more the CT community can share about what has been done, the better the ecosystem will be.</p>
237 <p><a href="https://sectigo.com/">Sectigo</a> and <a href="https://aws.amazon.com/">Amazon Web Services</a> have generously provided support to cover a significant portion of the cost of running our CT log. “Sectigo is proud to sponsor the Let’s Encrypt CT Log. We believe this initiative will provide much-needed reinforcement of the CT ecosystem,” said Ed Giaquinto, Sectigo’s CIO.</p>
238 <p>For more background information about CT and how it works, we recommend reading “<a href="https://www.certificate-transparency.org/how-ct-works">How Certificate Transparency Works</a>.”</p>
239 <p>If you have questions about any of what we’ve written here, feel free to ask on our <a href="https://community.letsencrypt.org/">community forums</a>.</p>
240 <h1 id="objectives">Objectives</h1>
241 <ol>
242 <li><em>Scale:</em> Let’s Encrypt issues over <a href="https://letsencrypt.org/stats/#daily-issuance">1 million certificates per day</a>, and that number grows each month. We want our log to consume our certificates as well as those from other CAs, so we need to be able to handle as many as 2 million or more certificates per day. To support this ever-increasing number of certificates, CT software and infrastructure need to be architected for scale.</li>
243 <li><em>Stability and Compliance:</em> We target 99% uptime, with no outage lasting longer than 24 hours, in compliance with the <a href="https://github.com/chromium/ct-policy/blob/master/log_policy.md">Chromium</a> and <a href="https://support.apple.com/en-gb/HT205280">Apple</a> CT policies.</li>
244 <li><em>Sharding:</em> Best practice for a CT log is to break it into several temporal shards. For more information on temporal sharding, check out these <a href="https://www.digicert.com/blog/scaling-certificate-transparency-logs-temporal-sharding/">blog</a> <a href="https://www.venafi.com/blog/how-temporal-sharding-helps-ease-challenge-growing-log-scale">posts</a>.</li>
245 <li><em>Low Maintenance:</em> Staff time is expensive, we want to minimize the amount of time spent maintaining infrastructure.</li>
246 </ol>
247 <h1 id="system-architecture">System Architecture</h1>
248 <p><img src="/images/2019-11-20-ct-architecture.png" alt="System Architecture Diagram"></p>
249 <h1 id="staging-and-production-logs">Staging and Production Logs</h1>
250 <p>We run two equivalent logs, one for staging and one for production. Any changes we plan to make to the production log are first deployed to the staging log. This is critical for making sure that updates and upgrades don’t cause problems before being deployed to production. You can find access details for these logs in our <a href="https://letsencrypt.org/docs/ct-logs/">documentation</a>.</p>
251 <p>We keep the staging log continually under production-level load so that any scale-related problems manifest there first. We also use the staging CT log to submit certificates from our staging CA environment, and make it available for use by other CAs’ staging environments.</p>
252 <p>As a point of clarification, we consider a log to be comprised of several temporal shards. While each shard is technically a separate log, it makes sense to conceptualize the shards as belonging to a single log.</p>
253 <h1 id="amazon-web-services-aws">Amazon Web Services (AWS)</h1>
254 <p>We decided to run our CT logs on AWS for two reasons.</p>
255 <p>One consideration for us was cloud provider diversity. Since there are relatively few trusted logs in the ecosystem, we don’t want multiple logs to go down due to a single cloud provider outage. At the time we made the decision there were logs running on Google and Digital Ocean infrastructure, as well as self-hosted. We were not aware of any on AWS (in hindsight we may have missed the fact that Digicert had started using AWS for logs). If you’re thinking about setting up a trusted log for CAs to use, please consider cloud provider diversity.</p>
256 <p>Additionally, AWS provides a solid set of features and our team has experience using it for other purposes. We had little doubt that AWS was up to the task.</p>
257 <h1 id="terraform">Terraform</h1>
258 <p>Let’s Encrypt uses Hashicorp <a href="https://www.terraform.io/">Terraform</a> for a number of cloud-based projects. We were able to bootstrap our CT log infrastructure by reusing our existing Terraform code. There are roughly 50 components in our CT deployments; including EC2, RDS, EKS, IAM, security groups, and routing. Centrally managing this code allows our small team to reproduce a CT infrastructure in any Amazon region of the globe, prevent configuration drift, and easily test infrastructure changes.</p>
259 <h1 id="database">Database</h1>
260 <p>We chose to use MariaDB for our CT log database because we have extensive experience using it to run our certificate authority. MariaDB has scaled well on our journey to becoming the largest publicly trusted certificate authority.</p>
261 <p>We chose to have our MariaDB instances managed by Amazon RDS because RDS provides synchronous writes to standby cluster members. This allows for automatic database failover and ensures database consistency. Synchronous writes to database replicas are essential for a CT log. One missed write during a database failover can mean a certificate was not included as promised, and could lead to the log being disqualified. Having RDS manage this for us reduces complexity and saves staff time. We are still responsible for managing the database performance, tuning, and monitoring.</p>
262 <p>It’s important to calculate the necessary amount of storage for a CT log database carefully. Too little storage can result in needing to undertake time-consuming and potentially risky storage migrations. Too much storage can result in unnecessarily high costs.</p>
263 <p>A back of the napkin storage estimation is 1TB per 100 million entries. We expect to need to store 1 billion certificates and precertificates per annual temporal shard, for which we would need 10TB. We considered having separate database storage per annual temporal shard, with approximately 10TB allocated to each, but that was cost prohibitive. We decided to create a 12TB storage block per log (10TB plus some breathing room), which is duplicated for redundancy by RDS. Each year we plan to freeze the previous year’s shard and move it to a less expensive serving infrastructure, reclaiming its storage for our live shards.</p>
264 <p>We use 2x db.r5.4xlarge instances for RDS for each CT log. Each of these instances contains 8 CPU cores and 128GB of RAM.</p>
265 <h1 id="kubernetes">Kubernetes</h1>
266 <p>After trying a few different strategies for managing application instances, we decided to use Kubernetes. There is a hefty learning curve for Kubernetes and the decision was not made lightly. This was our first project making use of Kubernetes, and part of the reason we went with it was to gain experience and possibly apply that knowledge to other parts of our infrastructure in the future.</p>
267 <p>Kubernetes provides abstractions for operators such as <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#use-case">deployments</a>, <a href="https://kubernetes.io/docs/tutorials/kubernetes-basics/scale/">scaling</a>, and <a href="https://kubernetes.io/docs/concepts/services-networking/service/#motivation">service discovery</a> that we would not have to build ourselves. We utilized the example Kubernetes deployment manifests in the <a href="https://github.com/google/trillian/">Trillian repository</a> to assist with our deployment.</p>
268 <p>A Kubernetes cluster is comprised of two main components: the control plane which handles the Kubernetes APIs, and worker nodes where containerized applications run. We chose to have Amazon EKS manage our Kubernetes control plane.</p>
269 <p>We use 4x c5.2xlarge EC2 instances for the worker node pool for each CT log. Each of these instances contains 8 CPU cores and 16GB of RAM.</p>
270 <h1 id="application-software">Application Software</h1>
271 <p>There are three main CT components that we run in a Kubernetes cluster.</p>
272 <p>The certificate transparency front end, or <a href="https://github.com/google/certificate-transparency-go">CTFE</a>, provides <a href="https://tools.ietf.org/html/rfc6962">RFC 6962</a> endpoints and translates them to gRPC API requests for the Trillian backend.</p>
273 <p><a href="https://github.com/google/trillian">Trillian</a> describes itself as a “transparent, highly scalable and cryptographically verifiable data store.” Essentially, Trillian implements a generalized verifiable data store via a Merkle tree that can be used as the back-end for a CT log via the CTFE. Trillian consists of two components; the log signer and log server. The <a href="https://github.com/google/trillian/blob/master/docs/images/LogDesign.png">log signer’s function</a> is to periodically process incoming leaf data (certificates in the case of CT) and incorporate them into a Merkle tree. The log server retrieves objects from a Merkle tree in order to fulfill CT API monitoring requests.</p>
274 <h1 id="load-balancing">Load Balancing</h1>
275 <p>Traffic enters the CT log through an Amazon ELB which is mapped to a Kubernetes Nginx ingress service. The ingress service balances traffic amongst multiple Nginx pods. The Nginx pods proxy traffic to the CTFE service which balance that traffic to CTFE pods.</p>
276 <p>We employ IP and user agent based rate limiting at this Nginx layer.</p>
277 <h1 id="logging-and-monitoring">Logging and Monitoring</h1>
278 <p>Trillian and the CTFE expose <a href="https://prometheus.io/">Prometheus</a> metrics which we transform into monitoring dashboards and alerts. It is essential to set a <a href="https://en.wikipedia.org/wiki/Service-level_objective">Service Level Objective</a> for the CT log endpoints above the 99% uptime dictated by CT policy to ensure that your log is trusted. A FluentD pod running in a DaemonSet ships logs to centralized storage for further analysis.</p>
279 <p>We developed a free and open source tool named <a href="https://github.com/letsencrypt/ct-woodpecker">ct-woodpecker</a> that is used to monitor various aspects of log stability and correctness. This tool is an important part of how we ensure we’re meeting our service level objectives. Each ct-woodpecker instance runs externally from Amazon VPCs containing CT logs.</p>
280 <h1 id="future-efficiency-improvements">Future Efficiency Improvements</h1>
281 <p>Here are some ways we may be able to improve the efficiency of our system in the future:</p>
282 <ul>
283 <li>Trillian stores a copy of each certificate chain, including many duplicate copies of the same intermediate certificates. Being able to de-duplicate these in Trillian would significantly reduce storage costs. We’re planning to look into whether this is possible and reasonable.</li>
284 <li>See if we can successfully use a cheaper form of storage than IO1 block storage and provisioned IOPs.</li>
285 <li>See if we can reduce the Kubernetes worker EC2 instance size or use fewer EC2 instances.</li>
286 </ul>
287 <h1 id="support-let-s-encrypt">Support Let’s Encrypt</h1>
288 <p>We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization is interested in learning more about <a href="https://letsencrypt.org/become-a-sponsor/">sponsorship</a>, please email us at <a href="mailto:sponsor@letsencrypt.org">sponsor@letsencrypt.org</a>. We ask that you make an <a href="https://letsencrypt.org/donate/">individual contribution</a> if it is within your means.</p>]]></description>
289 <guid isPermaLink="true">https://letsencrypt.org/2019/11/20/how-le-runs-ct-logs.html</guid>
290 </item><item>
291 <title>Onboarding Your Customers with Let's Encrypt and ACME</title>
292 <link>https://letsencrypt.org/2019/10/09/onboarding-your-customers-with-lets-encrypt-and-acme.html</link>
293 <pubDate>Wed, 09 Oct 2019 00:00:00 +0000</pubDate>
294 <description><![CDATA[<p>If you work at a hosting provider or CDN, ACME’s DNS-01 validation
295 method can make it a lot easier to onboard new customers who have an
296 existing HTTPS website at another provider. Before your new customer
297 points their domain name at your servers, you need to have a certificate
298 already installed for them. Otherwise visitors to the customer’s site
299 will see an outage for a few minutes while you issue and install a
300 certificate. To fix this, you and your new customer should use the
301 DNS-01 validation method to issue a certificate before the customer
302 switches over DNS for their site.</p>
303 <h1 id="how-the-dns-validation-method-works">How the DNS Validation Method Works</h1>
304 <p>The DNS-01 validation method <a href="https://letsencrypt.org/docs/challenge-types/#dns-01-challenge">works like
305 this</a>: to prove that you control
306 <code>www.example.com</code>, you create a TXT record at
307 <code>_acme-challenge.www.example.com</code> with a “digest value” as specified by
308 ACME (your ACME client should take care of creating this digest value
309 for you). When the TXT record is ready, your ACME client informs the ACME server (for
310 instance, Let’s Encrypt) that the domain is ready for validation. The
311 ACME server looks up the TXT record, compares it to the expected digest
312 value, and if the result is correct, considers your account authorized
313 to issue for <code>www.example.com</code>. Your new customer can set up this TXT
314 record (or a CNAME) without interfering with normal website operations.</p>
315 <h1 id="the-advantages-of-a-cname">The Advantages of a CNAME</h1>
316 <p>There’s an additional trick that I recommend for hosting providers and
317 CDNs: Instead of giving the digest value to your new customer and
318 telling them to make a TXT record with it, tell your customer to
319 configure a CNAME from <code>_acme-challenge.www.example.com</code> to a domain
320 name that you control and that is unique to the domain being validated.
321 For instance, you might use <code>www.example.com.validationserver.example.net</code>.
322 Then, once your
323 software has verified that this CNAME is set up (accounting for
324 propagation delay and anycast), your ACME client should
325 begin the validation process for <code>www.example.com</code>, provisioning a TXT
326 record at <code>www.example.com.validationserver.example.net</code>. Because the
327 ACME server’s TXT lookup follows CNAMEs (as do all DNS lookups), it will
328 see the value you provisioned, and consider your account authorized.</p>
329 <p>This approach is preferable to handing your customers a raw digest value
330 for a few reasons. First, it gives your customers all the time they need to set
331 up the CNAME. If you create a pending authorization up front and give
332 your customer a digest value to deploy themselves, it has a fixed
333 lifetime before it expires (for Let’s Encrypt this lifetime is 7 days).
334 If your customer doesn’t complete the process in that time,
335 you’ll have to create a new pending authorization and give
336 your customer a new digest value. That’s annoying and time consuming for
337 both you and your customer. The CNAME method means even if it
338 takes your new customer a month to make the needed changes to their DNS,
339 you can get things up and running as soon as they do.</p>
340 <p>Another reason to prefer the CNAME method over having new customers
341 directly provision their TXT records is to support the best practice of
342 periodically rotating your ACME account key. Because the digest value
343 used for DNS-01 validation is computed based on your current ACME
344 account key, it will change whenever you rotate your account key. If you
345 asked customers to provision their TXT record manually , that means
346 notifying potential new customers that the value you asked them to put
347 in DNS isn’t valid anymore, and they need to use a different one. That’s pretty
348 inconvenient! If you use the CNAME method instead, there’s only one
349 ACME-related value you’ll ever need to have your new customers put in
350 DNS, and it won’t change as you change your account key.</p>
351 <h1 id="cleaning-up-unused-cnames">Cleaning Up Unused CNAMES</h1>
352 <p>One last note: This is a good way to onboard customers, but you also
353 need to detect when customers offboard themselves. They may simply
354 change their A records to point at a different CDN, without telling you
355 that their plans have changed. You should monitor for this situation and
356 stop attempting to issue certificates. If the customer has left behind a
357 CNAMEd <code>_acme-challenge</code> subdomain that points at you, you should
358 contact that and remind them to delete it. The CNAMEd subdomain
359 represents a delegated authorization to issue certificates, and cleaning
360 up that delegation improves both the customer’s security posture and
361 your own. Similarly, if a customer sets up the CNAME and you issue a
362 certificate on their behalf, but they never point their A records at
363 your servers, you should not reissue new certificates indefinitely
364 without further intervention from the customer.</p>]]></description>
365 <guid isPermaLink="true">https://letsencrypt.org/2019/10/09/onboarding-your-customers-with-lets-encrypt-and-acme.html</guid>
366 </item><item>
367 <title>Introducing Oak, a Free and Open Certificate Transparency Log</title>
368 <link>https://letsencrypt.org/2019/05/15/introducing-oak-ct-log.html</link>
369 <pubDate>Wed, 15 May 2019 00:00:00 +0000</pubDate>
370 <description><![CDATA[<blockquote>
371 <p><strong>Update: Feb. 5 2020</strong></p>
372 <p>The Let’s Encrypt CT logs are now included in approved log lists and are usable by all publicly-trusted certificate authorities.</p>
373 </blockquote>
374 <p>Today we are announcing a new <a href="https://letsencrypt.org/docs/ct-logs">Certificate Transparency log called Oak</a>. The Oak log will be operated by Let’s Encrypt and all publicly trusted certificate authorities will be welcome to submit certificates.</p>
375 <p><a href="https://sectigo.com/">Sectigo</a> generously provided funding to cover a significant portion of our costs to run our CT log. “Sectigo is proud to sponsor the Let’s Encrypt CT Log. We believe this initiative will provide much-needed reinforcement of the CT ecosystem,” said Ed Giaquinto, Sectigo’s CIO. We thank them for their collaboration to improve Internet security.</p>
376 <p><a href="https://www.certificate-transparency.org/what-is-ct">Certificate Transparency (CT)</a> is a system for logging and monitoring certificate issuance. It greatly enhances everyone’s ability to monitor and study certificate issuance, and these capabilities have led to numerous improvements to the CA ecosystem and Web security. As a result, it is rapidly becoming critical Internet infrastructure. Let’s Encrypt accelerated the adoption of CT by logging every certificate since we started issuing in 2015 - approximately half a billion certificates at this point.</p>
377 <p>We decided to create and operate a CT log for a few reasons. First, operating a log is consistent with our mission to create a more secure and privacy-respecting Web. We believe transparency increases security and empowers people to make well-informed decisions. Second, operating a log helps us take control of our destiny. Google Chrome requires all new certificates to be submitted to two separate logs, so multiple log options are imperative to our operation. Finally, Let’s Encrypt often issues <a href="https://letsencrypt.org/stats/">more than 1M certificates each day</a>, so we wanted to design a CT log that is optimized for high volume. We’ve designed our log to be able to handle submissions from all other publicly trusted Certificate Authorities so they can use Oak to fulfill their logging requirements as well.</p>
378 <p>Our log uses Google’s <a href="https://github.com/google/trillian/">Trillian software</a> running on AWS infrastructure. We use Kubernetes for container orchestration and job scheduling and AWS RDS for database management.</p>
379 <p>We are submitting our log for inclusion in the approved log lists for <a href="https://cs.chromium.org/chromium/src/components/certificate_transparency/data/log_list.json">Google Chrome</a> and <a href="https://valid.apple.com/ct/log_list/current_log_list.json">Apple Safari</a>. Following 90 days of successful monitoring, we anticipate our log will be added to these trusted lists and that change will propagate to people’s browsers with subsequent browser version releases.</p>
380 <p>Continuing the forest theme, we are also announcing the launch of our open source CT monitoring tool, <a href="https://github.com/letsencrypt/ct-woodpecker">CT Woodpecker</a>. We use it to monitor and ensure compliance for our log and we’ve made it open source so others in the CT ecosystem can use it as well.</p>
381 <p>We’d like to thank Google, Sectigo, Cloudflare, and DigiCert for also running open logs, and we look forward to contributing to better transparency in Web security!</p>
382 <p>We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to <a href="https://letsencrypt.org/become-a-sponsor/">sponsor</a> Let’s Encrypt please email us at <a href="mailto:sponsor@letsencrypt.org">sponsor@letsencrypt.org</a>. We ask that you make an <a href="https://letsencrypt.org/donate/">individual contribution</a> if it is within your means.</p>]]></description>
383 <guid isPermaLink="true">https://letsencrypt.org/2019/05/15/introducing-oak-ct-log.html</guid>
384 </item><item>
385 <title>Transitioning to ISRG's Root</title>
386 <link>https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html</link>
387 <pubDate>Mon, 15 Apr 2019 00:00:00 +0000</pubDate>
388 <description><![CDATA[<blockquote>
389 <p><strong>Update, September 17, 2020</strong></p>
390 <p>Due to concerns about insufficient ISRG root propagation on Android devices we have <a href="https://community.letsencrypt.org/t/transitioning-to-isrgs-root/94056">decided to move the date on which we will start serving a chain to our own root</a> to <strong>January 11, 2021</strong>. We had originally delayed this change until September 29, 2020.</p>
391 </blockquote>
392 <p>On January 11, 2021, we will change the default intermediate certificate we provide via ACME. Most subscribers don’t need to do anything. Subscribers who support <a href="https://letsencrypt.org/docs/certificate-compatibility/#known-incompatible">very old TLS/SSL clients</a> may want to manually configure the older intermediate to increase backwards compatibility.</p>
393 <p>Since Let’s Encrypt launched, our certificates have been trusted by browsers via a cross-signature from another Certificate Authority (CA) named <a href="https://www.identrust.com/">IdenTrust</a>. A cross-signature from IdenTrust was necessary because our own root was not yet widely trusted. It takes time for a new CA to demonstrate that it is trustworthy, then it takes more time for trusted status to propagate via software updates.</p>
394 <p>Now that our own root, <a href="https://letsencrypt.org/certificates/">ISRG Root X1</a>, is <a href="https://letsencrypt.org/2018/08/06/trusted-by-all-major-root-programs.html">widely trusted by browsers</a> we’d like to transition our subscribers to using our root directly, without a cross-sign.</p>
395 <p>On <strong>January 11, 2021</strong>, Let’s Encrypt will start serving a certificate chain via the ACME protocol which leads directly to our root, with no cross-signature. Most subscribers don’t need to take any action because their ACME client will handle everything automatically. Subscribers who need to support very old TLS/SSL clients may wish to manually configure their servers to continue using the cross-signature from IdenTrust. You can test whether a given client will work with the newer intermediate by accessing our <a href="https://valid-isrgrootx1.letsencrypt.org/">test site</a>.</p>
396 <p>Our current cross-signature from IdenTrust expires on March 17, 2021. The IdenTrust root that we are cross-signed from expires on September 30, 2021. Within the next year we will obtain a new cross-signature that is valid until September 29, 2021. This means that our subscribers will have the option to manually configure a certificate chain that uses IdenTrust until <strong>September 29, 2021</strong>.</p>
397 <p>We’d like to thank IdenTrust for providing a cross-signature while we worked to get our own root trusted. They have been wonderful partners. IdenTrust believed in our mission to encrypt the entire Web when it seemed like a long-term dream. Together, in less than five years, we have helped to raise the percentage of encrypted page loads on the Web from <a href="https://letsencrypt.org/stats/#percent-pageloads">39% to 78%</a>.</p>
398 <p>Let’s Encrypt is currently providing certificates for more than 160 million websites. We look forward to being able to serve even more websites as efforts like this make deploying HTTPS with Let’s Encrypt even easier. If you’re as excited about the potential for a 100% HTTPS Web as we are, please consider <a href="https://letsencrypt.org/getinvolved/">getting involved</a>, <a href="https://letsencrypt.org/donate/">making a donation</a>, or <a href="https://letsencrypt.org/become-a-sponsor/">sponsoring Let’s Encrypt</a>.</p>]]></description>
399 <guid isPermaLink="true">https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html</guid>
400 </item><item>
401 <title>The ACME Protocol is an IETF Standard</title>
402 <link>https://letsencrypt.org/2019/03/11/acme-protocol-ietf-standard.html</link>
403 <pubDate>Mon, 11 Mar 2019 00:00:00 +0000</pubDate>
404 <description><![CDATA[<p>It has long been a dream of ours for there to be a standardized protocol for certificate issuance and management. That dream has become a reality now that the IETF has standardized the ACME protocol as <a href="https://tools.ietf.org/html/rfc8555">RFC 8555</a>. I’d like to thank everyone involved in that effort, including Let’s Encrypt staff and other IETF contributors.</p>
405 <p>Having a standardized protocol for certificate issuance and management is important for two reasons. First, it improves the quality of the software ecosystem because developers can focus on developing great software for a single protocol, instead of having many pieces of less well maintained software for bespoke APIs. Second, a standardized protocol makes switching from one CA to another easier by minimizing technical dependency lock-in.</p>
406 <p>We consider the standardized version of the ACME protocol to be the second major version of ACME, so we refer to it as ACMEv2. The first version, which we call ACMEv1, is the version of ACME that Let’s Encrypt has used since our launch in 2015. Now that ACMEv2 is standardized, <a href="https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430">we are announcing an end-of-life plan for our ACMEv1 support</a>.</p>
407 <p>Let’s Encrypt is currently providing certificates for more than 150 million websites. We look forward to being able to serve even more websites as efforts like this make deploying HTTPS with Let’s Encrypt even easier. If you’re as excited about the potential for a 100% HTTPS Web as we are, please consider <a href="https://letsencrypt.org/getinvolved/">getting involved</a>, <a href="https://letsencrypt.org/donate/">making a donation</a>, or <a href="https://letsencrypt.org/become-a-sponsor/">sponsoring Let’s Encrypt</a>.</p>]]></description>
408 <guid isPermaLink="true">https://letsencrypt.org/2019/03/11/acme-protocol-ietf-standard.html</guid>
409 </item><item>
410 <title>Facebook Expands Support for Let’s Encrypt</title>
411 <link>https://letsencrypt.org/2019/02/12/facebook-expands-support-for-letsencrypt.html</link>
412 <pubDate>Tue, 12 Feb 2019 00:00:00 +0000</pubDate>
413 <description><![CDATA[<blockquote>
414 <p>We’re excited that Facebook is supporting our work through a three-year Platinum sponsorship! We asked them to share their thoughts on HTTPS adoption here. Please join us in thanking Facebook for their support of Let’s Encrypt and our mission to encrypt the Web! - Josh Aas, Executive Director, ISRG / Let’s Encrypt</p>
415 </blockquote>
416 <p>If the web is more secure, everybody wins. A key technology for making this happen is HTTPS, which enables encrypted connections between people and the websites that they visit. Among its many benefits, HTTPS helps to prevent sensitive data from leaking over the network, and from connections being censored or otherwise maliciously manipulated. The more widely it is deployed, the more secure and private the web becomes for everyone.</p>
417 <p>We have long worked to protect Facebook users from <a href="https://www.facebook.com/notes/facebook-security/link-shim-protecting-the-people-who-use-facebook-from-malicious-urls/10150492832835766/">spammy or malicious content</a> when navigating away from our platform, and last year we extended this protection to <a href="https://www.facebook.com/notes/facebook-security/upgrades-to-facebooks-link-security/10155158540455766/">upgrading outbound HTTP links to HTTPS</a> where possible. In this way we can help improve people’s security and privacy as they leave our platform. While we take these steps to improve the security and safety of Facebook users, ultimately we hope to see more websites allowing HTTPS connections.</p>
418 <p>Enabling HTTPS was historically a non-trivial task for any site. It required investment in buying and installing a TLS certificate, which verifies control over the website so that HTTPS can work. The technical difficulty and cost used to serve as barriers to expanding the use of HTTPS across the web. However, things have recently started to change, largely thanks to Let’s Encrypt, a non-profit certificate authority, launched in 2015.</p>
419 <p>Let’s Encrypt provides free TLS certificates, which are often installed using a tool maintained by the Electronic Frontier Foundation, to massively simplify enabling HTTPS. With that, Let’s Encrypt is effectively upgrading the security and privacy of the web, at no cost to <a href="https://letsencrypt.org/stats/">over 150 million websites</a>, including those frequented by Facebook users.</p>
420 <p>We’re excited to see the continuous increase in HTTPS adoption across the internet. More websites are choosing to enable secure connections which provide the security and privacy benefits and enable a better browsing experience. For example, navigating from Facebook to another site can be faster over encrypted connections than HTTP, and an increasing number of browser features will only work when sites use HTTPS.</p>
421 <p>We have sponsored Let’s Encrypt from the start, and are proud to share that we are increasing that support as a platinum sponsor. We believe that Let’s Encrypt has played a significant and important role in bringing encryption into the mainstream and raising the number of secure sites across the internet.</p>
422 <p>As we automatically <a href="https://developers.facebook.com/docs/sharing/webmasters/crawler/">crawl</a> web content on Facebook (for example, to generate link previews), about 38% of HTTPS domains we observe use Let’s Encrypt, making it the top certificate authority. Over 19% of outbound clicks from Facebook to HTTPS-enabled websites go to sites that use certificates from Let’s Encrypt. Overall, more than 72% of outbound clicks from Facebook are now destined for HTTPS-enabled websites, including the links that we <a href="https://www.facebook.com/notes/protect-the-graph/upgrades-to-facebooks-link-security/2015650322008442/">upgrade</a> to HTTPS in real time.</p>
423 <p>We’re proud to continue to collaborate with Let’s Encrypt on helping to improve web security. To any website owners who haven’t yet enabled encryption, we strongly encourage you to use Let’s Encrypt to protect your users and allow HTTPS connections.</p>]]></description>
424 <guid isPermaLink="true">https://letsencrypt.org/2019/02/12/facebook-expands-support-for-letsencrypt.html</guid>
425 </item><item>
426 <title>Looking Forward to 2019</title>
427 <link>https://letsencrypt.org/2018/12/31/looking-forward-to-2019.html</link>
428 <pubDate>Mon, 31 Dec 2018 00:00:00 +0000</pubDate>
429 <description><![CDATA[<p>Let’s Encrypt had a great year in 2018. We’re now serving more than 150 million websites while maintaining a stellar security and compliance track record.</p>
430 <p>Most importantly though, the Web went from 67% encrypted page loads to 77% in 2018, according to statistics from Mozilla. This is an incredible rate of change!</p>
431 <p>We’d like to thank all of the people and organizations who worked hard to create a more secure and privacy-respecting Web.</p>
432 <p>This year we created a new website for the legal entity behind Let’s Encrypt, <a href="https://www.abetterinternet.org/">Internet Security Research Group (ISRG)</a>, because we believe there will be other instances beyond Let’s Encrypt in which ISRG might be able to help to build, or improve access to, a better Internet.</p>
433 <p>While we’re proud of what we accomplished in 2018, we spend most of our time looking forward rather than back. As we wrap up our own planning process for 2019, We’d like to share some of our plans with you, including both the things we’re excited about and the challenges we’ll face. We’ll cover service growth, new features, infrastructure, and finances.</p>
434 <h2 id="service-growth">Service Growth</h2>
435 <p>Let’s Encrypt helps to drive HTTPS adoption by offering a free, easy to use, and globally available option for obtaining the certificates required to enable HTTPS. HTTPS adoption on the Web took off at an unprecedented rate from the day Let’s Encrypt launched to the public.</p>
436 <p>The number of certificates and unique domains we support continues to grow rapidly:</p>
437 <div class="figure">
438 <div id="activeUsage" title="Let's Encrypt Growth" class="statsgraph"></div>
439 </div>
440
441 <span id="plot-translations"
442 data-issued="Issued"
443 data-certificates_active="Certificates Active"
444 data-fully_qualified_domains_active="Fully-Qualified Domains Active"
445 data-registered_domains_active="Registered Domains Active"
446 data-active_count="Active Count"
447 data-issued_per_day="Issued Per Day"
448 data-all_users="All users"
449 data-usa_users="USA users"
450 data-japan_users="Japan users"
451 data-percent_https="Percent of Pageloads over HTTPS (14 day moving average)"
452 ></span>
453
454 <script src="/js/plotly-min.js" defer></script>
455
456
457
458
459 <script src="/js/stats.js" defer></script>
460
461 <p>We expect strong growth again in 2019, likely up to 120M active certificates and 215M fully qualified domains. You can view our recently revamped <a href="https://letsencrypt.org/stats/">stats page</a> for more information.</p>
462 <p>One of the reasons Let’s Encrypt is so easy to use is that our community has done great work making client software that works well for a wide variety of platforms. We’d like to thank everyone involved in the development of more than 85 <a href="https://letsencrypt.org/docs/client-options/">client software options</a> for Let’s Encrypt. Support for our protocol, ACME, is <a href="https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html">built in to Apache</a> and we’re hoping 2019 will be the year that it comes to Nginx.</p>
463 <p>Other organizations and communities are also doing great work to promote HTTPS adoption, and thus stimulate demand for our services. For example, browsers are starting to make their users more aware of the risks associated with unencrypted HTTP (e.g. <a href="https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/">Firefox</a>, <a href="https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/">Chrome</a>). Many hosting providers and CDNs are making it easier than ever for all of their customers to use HTTPS. <a href="https://https.cio.gov/">Government agencies</a> are waking up to the need for stronger security to protect constituents. The media community is working to <a href="https://securethe.news/">Secure the News</a>.</p>
464 <h2 id="new-features">New Features</h2>
465 <p>In 2018 we introduced <a href="https://letsencrypt.org/upcoming-features/">several new features</a>, including ACMEv2 support and wildcard certificates. We’ve got some exciting features planned for 2019.</p>
466 <p>The feature we’re most excited about is multi-perspective validation. Currently, when a subscriber requests a certificate, we validate domain control from a single network perspective. This is standard practice for CAs. If an attacker along the network path for the validation check can interfere with traffic they can potentially cause certificates to be issued that should not be issued. We’re most concerned about this <a href="https://www.princeton.edu/~pmittal/publications/bgp-tls-usenix18.pdf">happening via BGP hijacking</a>, and since BGP is not going to be secured any time soon, we needed to find another mitigation. The solution we intend to deploy in 2019 is multi-perspective validation, in which we will check from multiple network perspectives (distinct Autonomous Systems). This means that potential BGP hijackers would need to hijack multiple routes at the same time in order to pull off a successful attack, which is significantly more difficult than hijacking a single route. We are working with a talented research team at Princeton to design the most effective multi-perspective validation system we can, and have already turned parts of this feature on in our staging environment.</p>
467 <p>We are also planning to introduce a <a href="https://www.certificate-transparency.org/">Certificate Transparency (CT) log</a> in 2019. All certificate authorities like Let’s Encrypt are required to submit certificates to CT logs but there are not enough stable logs in the ecosystem. As such, we are moving forward with plans to run a log which all CAs will be able to submit to.</p>
468 <p>We had planned to add ECDSA root and intermediate certificates in 2018 but other priorities ultimately took precedence. We hope to do this in 2019. ECDSA is generally considered to be the future of digital signature algorithms on the Web due to the fact that it is more efficient than RSA. Let’s Encrypt will currently sign ECDSA keys from subscribers, but we sign with the RSA key from one of our intermediate certificates. Once we have an ECDSA root and intermediates, our subscribers will be able to deploy certificate chains which are entirely ECDSA.</p>
469 <h2 id="infrastructure">Infrastructure</h2>
470 <p>Our CA infrastructure is capable of issuing millions of certificates per day with redundancy for stability and a wide variety of security safeguards, both physical and logical. Our infrastructure also generates and signs around 40 million OCSP responses daily, and serves those responses approximately 5.5 billion times per day. We expect these numbers to grow approximately 40% in 2019.</p>
471 <p>Our physical CA infrastructure currently occupies approximately 55 units of rack space, split between two datacenters, consisting primarily of compute servers, storage, HSMs, switches, and firewalls. When we issue more certificates it puts the most stress on storage for our databases. We regularly invest in more and faster storage for our database servers, and that will continue in 2019.</p>
472 <p>All of our infrastructure is managed by our Site Reliability Engineering (SRE) team, which is comprised of six people. SRE staff are responsible for building and maintaining all physical and logical CA infrastructure. These staff are largely responsible for our high standards for security and compliance. The team also manages a 24/7/365 on-call schedule and they are primary participants in both security and compliance audits.</p>
473 <h2 id="finances">Finances</h2>
474 <p>We pride ourselves on being an efficient organization. In 2019 Let’s Encrypt will secure a massive portion of the Web with a budget of only $3.6M. We believe this represents an incredible value and that contributing to Let’s Encrypt is one of the most effective ways to help create a more secure and privacy-respecting Web.</p>
475 <p>Our 2019 fundraising efforts are off to a strong start with Platinum sponsorships from Cisco, OVH, Mozilla, Google Chrome, Electronic Frontier Foundation, and Internet Society, as well as <a href="https://letsencrypt.org/sponsors/">many other Gold and Silver sponsors</a>. The Ford Foundation has renewed their grant to Let’s Encrypt as well. We are seeking additional sponsorship and grant assistance to meet our full needs for 2019.</p>
476 <h2 id="support-let-s-encrypt">Support Let’s Encrypt</h2>
477 <p>We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to <a href="https://letsencrypt.org/become-a-sponsor/">sponsor</a> Let’s Encrypt please email us at <a href="mailto:sponsor@letsencrypt.org">sponsor@letsencrypt.org</a>. We ask that you make an <a href="https://letsencrypt.org/donate/">individual contribution</a> if it is within your means.</p>
478 <p>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!</p>]]></description>
479 <guid isPermaLink="true">https://letsencrypt.org/2018/12/31/looking-forward-to-2019.html</guid>
480 </item>
481 </channel>
482 </rss>