 |
letsencrypt - sfeed_tests - sfeed tests and RSS and Atom files |
 |
git clone git://git.codemadness.org/sfeed_tests |
 |
Log |
|
Files |
|
Refs |
|
README |
|
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 cert… |
|
6 authority brought to you by the nonprofit <a href="https://www.… |
|
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="… |
|
12 <item> |
|
13 <title>Let's Encrypt's New Root and Intermediate Certifi… |
|
14 <link>https://letsencrypt.org/2020/09/17/new-root-and-intermedia… |
|
15 <pubDate>Thu, 17 Sep 2020 00:00:00 +0000</pubDate> |
|
16 <description><![CDATA[<p>On Thursday, September 3rd, 2020, Let�… |
|
17 one root, four intermediates, and one cross-sign. These new certificates… |
|
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 sma… |
|
20 <p>Given that we issue <a href="https://letsencrypt.org/stats/">1.5 mill… |
|
21 what makes these ones special? Why did we issue them? How did we issue t… |
|
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… |
|
26 least one root certificate which is incorporated into various browser an… |
|
27 vendors’ (e.g. Mozilla, Google) trusted root stores. This is what allo… |
|
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… |
|
30 certificates, by virtue of their widespread trust and long lives, must h… |
|
31 their corresponding private key carefully protected and stored offline, … |
|
32 therefore can’t be used to sign things all the time. So every Certific… |
|
33 Authority (CA) also has some number of “intermediates”, certificates… |
|
34 are able to issue additional certificates but are not roots, which they … |
|
35 for day-to-day issuance.</p> |
|
36 <p>For the last <a href="https://letsencrypt.org/2015/06/04/isrg-ca-cert… |
|
37 Let’s Encrypt has had one root: the <a href="https://crt.sh/?caid=7394… |
|
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 Encr… |
|
40 Authorities <a href="https://crt.sh/?caid=7395">X1</a>, <a href="https:/… |
|
41 <a href="https://crt.sh/?caid=16418">X3</a>, and <a href="https://crt.sh… |
|
42 first two were issued when Let’s Encrypt first began operations in 201… |
|
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… |
|
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… |
|
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">ISR… |
|
50 certificate. This one is a little different – it doesn’t issue a… |
|
51 certificates. Instead, it signs Online Certificate Status Protocol (OCSP) |
|
52 responses that indicate the intermediate certificates have not been revo… |
|
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… |
|
55 offline and safely secured.</p> |
|
56 <p><img src="/images/2020-09-17-hierarchy-pre-sept-2020.png" alt="Let&rs… |
|
57 <h1 id="the-new-certificates">The New Certificates</h1> |
|
58 <p>For starters, we’ve issued two new 2048-bit RSA intermediates which… |
|
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 I… |
|
61 have 5-year lifetimes. They will also be cross-signed by IdenTrust. They… |
|
62 basically direct replacements for our current X3 and X4, which are expir… |
|
63 in a year. We expect to switch our primary issuance pipeline to use R3 l… |
|
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 th… |
|
66 <a href="https://crt.sh/?caid=183269">ISRG Root X2</a>, which has an ECD… |
|
67 instead of RSA, and is valid until 2040. Issued from that, we have two n… |
|
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 … |
|
70 for 5 years.</p> |
|
71 <p>Notably, these ECDSA intermediates are not cross-signed by IdenTrust�… |
|
72 Root CA X3. Instead, the ISRG Root X2 itself is |
|
73 <a href="https://crt.sh/?id=3334561878">cross-signed by our existing ISR… |
|
74 An astute observer might also notice that we have not issued an OCSP Sig… |
|
75 Certificate from ISRG Root X2.</p> |
|
76 <p><img src="/images/2020-09-17-hierarchy-post-sept-2020.png" alt="Let&r… |
|
77 <p>Now that we have the technical details out of the way, let’s dive i… |
|
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 … |
|
80 <p>There are lots of <a href="https://blog.cloudflare.com/ecdsa-the-digi… |
|
81 you can read about the benefits of ECDSA (smaller key sizes for the same |
|
82 level of security; correspondingly faster encryption, decryption, signin… |
|
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 hand… |
|
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 usu… |
|
89 provided by the server. This means that every connection – and a p… |
|
90 covered in ads and tracking pixels might have dozens or hundreds –… |
|
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.… |
|
93 <p>While a 2048-bit RSA public key is about 256 bytes long, an ECDSA P-3… |
|
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. Fact… |
|
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, a… |
|
98 how many connections you get in a day, and the bandwidth savings add up … |
|
99 <p>These savings are a public benefit both for our subscribers – who c… |
|
100 sites for which bandwidth can be a meaningful cost every month – and f… |
|
101 end-users, who may have limited or metered connections. Bringing privacy… |
|
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… |
|
105 a few other measures to save bytes in our new certificates. We’ve shor… |
|
106 their Subject Common Names from “Let’s Encrypt Authority X3” to ju… |
|
107 relying on the previously-redundant Organization Name field to supply the |
|
108 words “Let’s Encrypt”. We’ve shortened their Authority Informati… |
|
109 Issuer and CRL Distribution Point URLs, and we’ve dropped their CPS an… |
|
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 … |
|
112 the certificate.</p> |
|
113 <h1 id="why-we-cross-signed-the-ecdsa-root">Why We Cross-Signed the ECDS… |
|
114 <p>Cross-signing is an important step, bridging the gap between when a n… |
|
115 certificate is issued and when that root is incorporated into various tr… |
|
116 stores. We know that it is going to take 5 years or so for our new ISRG … |
|
117 X2 to be widely trusted itself, so in order for certificates issued by t… |
|
118 intermediate to be trusted, there needs to be a cross-sign somewhere in … |
|
119 chain.</p> |
|
120 <p>We had basically two options: we could cross-sign the new ISRG Root X… |
|
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 ea… |
|
123 <p>Cross-signing the new ISRG Root X2 certificate means that, if a user … |
|
124 Root X2 in their trust store, then their full certificate chain will be … |
|
125 ECDSA, giving them fast validation, as discussed above. And over the nex… |
|
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 user… |
|
128 websites having to change anything. The tradeoff though is that, as long… |
|
129 X2 isn’t in trust stores, user agents will have to validate a chain wi… |
|
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. O… |
|
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 I… |
|
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/tran… |
|
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 … |
|
139 important, and so opted to go with the first option, and cross-sign the … |
|
140 Root X2 itself.</p> |
|
141 <h1 id="why-we-didn-t-issue-an-ocsp-responder">Why We Didn’t Issue an … |
|
142 <p>The Online Certificate Status Protocol is a way for user agents to di… |
|
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 vali… |
|
145 can simply hit a URL contained within the certificate itself and get a y… |
|
146 no response, which is signed by another certificate and can be similarly |
|
147 validated. This is great for end-entity certificates, because the respon… |
|
148 are small and fast, and any given user might care about (and therefore h… |
|
149 to fetch) the validity of wildly different sets of certificates, dependi… |
|
150 what sites they visit.</p> |
|
151 <p>But intermediate certificates are a tiny subset of all certificates i… |
|
152 wild, are generally well-known, and are rarely revoked. Because of this,… |
|
153 can be much more efficient to simply maintain a Certificate Revocation L… |
|
154 (CRL) containing validity information for all well-known intermediates. … |
|
155 intermediate certificates all contain a URL from which a browser can fet… |
|
156 their CRL, and in fact some browsers even aggregate these into their own… |
|
157 which they distribute with each update. This means that checking the |
|
158 revocation status of intermediates doesn’t require an extra network ro… |
|
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/ba… |
|
162 to the Baseline Requirements, which govern CAs, has made it so intermedi… |
|
163 certificates are no longer required to include an OCSP URL; they can now… |
|
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’… |
|
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, th… |
|
169 last thing we’d like to mention: how we actually went about issuing th… |
|
170 <p>The creation of new root and intermediate certificates is a big deal,… |
|
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 call… |
|
173 “ceremony”. Let’s Encrypt <a href="https://letsencrypt.org/about/"… |
|
174 so we wanted our ceremony to require as little human involvement as poss… |
|
175 <p>Over the last few months we’ve built a <a href="https://github.com/… |
|
176 which, given appropriate configuration, can produce all of the desired k… |
|
177 certificates, and requests for cross-signs. We also built a |
|
178 <a href="https://github.com/letsencrypt/2020-hierarchy-demo">demo</a> of… |
|
179 showing what our configuration files would be, and allowing anyone to ru… |
|
180 themselves and examine the resulting output. Our SREs put together a rep… |
|
181 network, complete with Hardware Security Modules, and practiced the cere… |
|
182 multiple times to ensure it would work flawlessly. We shared this demo w… |
|
183 our technical advisory board, our community, and various mailing lists, … |
|
184 in the process received valuable feedback that actually influenced some … |
|
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 w… |
|
187 ceremony, and record it for future audits.</p> |
|
188 <p>And now the ceremony is complete. We’ve updated <a href="https://le… |
|
189 to include details about all of our new certificates, and are beginning … |
|
190 process of requesting that our new root be incorporated into various tru… |
|
191 stores. We intend to begin issuing with our new intermediates over the c… |
|
192 weeks, and will post further announcements in our <a href="https://commu… |
|
193 when we do.</p> |
|
194 <p>We hope that this has been an interesting and informative tour around… |
|
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 bett… |
|
198 <p>We depend on contributions from our community of users and supporters… |
|
199 order to provide our services. If your company or organization would lik… |
|
200 <a href="https://letsencrypt.org/become-a-sponsor/">sponsor</a> Let’s … |
|
201 email us at <a href="mailto:[email protected]">sponsor@letsencrypt… |
|
202 <a href="https://letsencrypt.org/donate/">individual contribution</a> if… |
|
203 means.</p>]]></description> |
|
204 <guid isPermaLink="true">https://letsencrypt.org/2020/09/17/new-… |
|
205 </item><item> |
|
206 <title>Let's Encrypt Has Issued a Billion Certificates</titl… |
|
207 <link>https://letsencrypt.org/2020/02/27/one-billion-certs.html<… |
|
208 <pubDate>Thu, 27 Feb 2020 00:00:00 +0000</pubDate> |
|
209 <description><![CDATA[<p>We issued our billionth certificate on … |
|
210 <p>One thing that’s different now is that the Web is much more encrypt… |
|
211 <p>Another thing that’s different is that our organization has grown a… |
|
212 <p>Nothing drives adoption like ease of use, and the foundation for ease… |
|
213 <p>When you combine ease of use with incentives, that’s when adoption … |
|
214 <p>Thanks for taking the time to reflect on this milestone with us. As a… |
|
215 <p>We depend on contributions from our community of users and supporters… |
|
216 <guid isPermaLink="true">https://letsencrypt.org/2020/02/27/one-… |
|
217 </item><item> |
|
218 <title>Multi-Perspective Validation Improves Domain Validation S… |
|
219 <link>https://letsencrypt.org/2020/02/19/multi-perspective-valid… |
|
220 <pubDate>Wed, 19 Feb 2020 00:00:00 +0000</pubDate> |
|
221 <description><![CDATA[<p>At Let’s Encrypt we’re always looki… |
|
222 <p>Domain validation is a process that all CAs use to ensure that a cert… |
|
223 <p><img src="/images/2020-02-19-single-perspective-validation.png" alt="… |
|
224 <p>A potential issue with this process is that if a network attacker can… |
|
225 <p>The Border Gateway Protocol (BGP) and most deployments of it are not … |
|
226 <p><img src="/images/2020-02-19-multiple-perspective-validation.png" alt… |
|
227 <p>Today we are validating from multiple regions within a single cloud p… |
|
228 <p>This makes the kind of attack described earlier more difficult becaus… |
|
229 <p>We’d like to thank the research groups of Prof. Prateek Mittal and … |
|
230 <p>We depend on contributions from our community of users and supporters… |
|
231 <guid isPermaLink="true">https://letsencrypt.org/2020/02/19/mult… |
|
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.htm… |
|
235 <pubDate>Wed, 20 Nov 2019 00:00:00 +0000</pubDate> |
|
236 <description><![CDATA[<p>Let’s Encrypt <a href="https://letsen… |
|
237 <p><a href="https://sectigo.com/">Sectigo</a> and <a href="https://aws.a… |
|
238 <p>For more background information about CT and how it works, we recomme… |
|
239 <p>If you have questions about any of what we’ve written here, feel fr… |
|
240 <h1 id="objectives">Objectives</h1> |
|
241 <ol> |
|
242 <li><em>Scale:</em> Let’s Encrypt issues over <a href="https://letsenc… |
|
243 <li><em>Stability and Compliance:</em> We target 99% uptime, with no out… |
|
244 <li><em>Sharding:</em> Best practice for a CT log is to break it into se… |
|
245 <li><em>Low Maintenance:</em> Staff time is expensive, we want to minimi… |
|
246 </ol> |
|
247 <h1 id="system-architecture">System Architecture</h1> |
|
248 <p><img src="/images/2019-11-20-ct-architecture.png" alt="System Archite… |
|
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. A… |
|
251 <p>We keep the staging log continually under production-level load so th… |
|
252 <p>As a point of clarification, we consider a log to be comprised of sev… |
|
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 ar… |
|
256 <p>Additionally, AWS provides a solid set of features and our team has e… |
|
257 <h1 id="terraform">Terraform</h1> |
|
258 <p>Let’s Encrypt uses Hashicorp <a href="https://www.terraform.io/">Te… |
|
259 <h1 id="database">Database</h1> |
|
260 <p>We chose to use MariaDB for our CT log database because we have exten… |
|
261 <p>We chose to have our MariaDB instances managed by Amazon RDS because … |
|
262 <p>It’s important to calculate the necessary amount of storage for a C… |
|
263 <p>A back of the napkin storage estimation is 1TB per 100 million entrie… |
|
264 <p>We use 2x db.r5.4xlarge instances for RDS for each CT log. Each of th… |
|
265 <h1 id="kubernetes">Kubernetes</h1> |
|
266 <p>After trying a few different strategies for managing application inst… |
|
267 <p>Kubernetes provides abstractions for operators such as <a href="https… |
|
268 <p>A Kubernetes cluster is comprised of two main components: the control… |
|
269 <p>We use 4x c5.2xlarge EC2 instances for the worker node pool for each … |
|
270 <h1 id="application-software">Application Software</h1> |
|
271 <p>There are three main CT components that we run in a Kubernetes cluste… |
|
272 <p>The certificate transparency front end, or <a href="https://github.co… |
|
273 <p><a href="https://github.com/google/trillian">Trillian</a> describes i… |
|
274 <h1 id="load-balancing">Load Balancing</h1> |
|
275 <p>Traffic enters the CT log through an Amazon ELB which is mapped to a … |
|
276 <p>We employ IP and user agent based rate limiting at this Nginx layer.<… |
|
277 <h1 id="logging-and-monitoring">Logging and Monitoring</h1> |
|
278 <p>Trillian and the CTFE expose <a href="https://prometheus.io/">Prometh… |
|
279 <p>We developed a free and open source tool named <a href="https://githu… |
|
280 <h1 id="future-efficiency-improvements">Future Efficiency Improvements</… |
|
281 <p>Here are some ways we may be able to improve the efficiency of our sy… |
|
282 <ul> |
|
283 <li>Trillian stores a copy of each certificate chain, including many dup… |
|
284 <li>See if we can successfully use a cheaper form of storage than IO1 bl… |
|
285 <li>See if we can reduce the Kubernetes worker EC2 instance size or use … |
|
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… |
|
289 <guid isPermaLink="true">https://letsencrypt.org/2019/11/20/how-… |
|
290 </item><item> |
|
291 <title>Onboarding Your Customers with Let's Encrypt and ACME… |
|
292 <link>https://letsencrypt.org/2019/10/09/onboarding-your-custome… |
|
293 <pubDate>Wed, 09 Oct 2019 00:00:00 +0000</pubDate> |
|
294 <description><![CDATA[<p>If you work at a hosting provider or CD… |
|
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 Meth… |
|
304 <p>The DNS-01 validation method <a href="https://letsencrypt.org/docs/ch… |
|
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” a… |
|
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 ACM… |
|
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 … |
|
314 record (or a CNAME) without interfering with normal website operations.<… |
|
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 … |
|
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… |
|
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.examp… |
|
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>, provision… |
|
326 record at <code>www.example.com.validationserver.example.net</code>. Bec… |
|
327 ACME server’s TXT lookup follows CNAMEs (as do all DNS lookups), it wi… |
|
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 va… |
|
330 for a few reasons. First, it gives your customers all the time they need… |
|
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 consumi… |
|
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. … |
|
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 sh… |
|
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/onbo… |
|
366 </item><item> |
|
367 <title>Introducing Oak, a Free and Open Certificate Transparency… |
|
368 <link>https://letsencrypt.org/2019/05/15/introducing-oak-ct-log.… |
|
369 <pubDate>Wed, 15 May 2019 00:00:00 +0000</pubDate> |
|
370 <description><
