diff --git a/content/en/certificates.md b/content/en/certificates.md index 26fe98ba6..810cec8d0 100644 --- a/content/en/certificates.md +++ b/content/en/certificates.md @@ -291,6 +291,6 @@ When an ACME client downloads a newly-issued certificate from Let's Encrypt's AC Sometimes there's more than one valid chain for a given certificate: for example, if an intermediate has been cross-signed, then either one of those two certificates could be the second entry, "chaining up to" either of two different roots. In this case, different website operators may want to select different chains depending on the properties that they care about the most. -Each of the active intermediates above documents which chain is offered by default, and which (if any) additional chains may be requested by ACME clients. In general, chains which terminate at ISRG Root X1 have the largest size but also the greatest compatibility with older clients. Chains which terminate at ISRG Root X2 (only offered for ECDSA certificates) are smaller, but will only work with clients that have received an update to their trust store after 2022 or so. Chains which terminate at Root YE or Root YR will are not expected to work with any of the major trust stores, as those roots have not yet been incorporated. +Each of the active intermediates above documents which chain is offered by default, and which (if any) additional chains may be requested by ACME clients. In general, chains which terminate at ISRG Root X1 have the largest size but also the greatest compatibility with older clients. Chains which terminate at ISRG Root X2 (only offered for ECDSA certificates) are smaller, but will only work with clients that have received an update to their trust store after 2022 or so. Chains which terminate at Root YE or Root YR are not expected to work with any of the major trust stores, as those roots have not yet been incorporated. Subscribers who wish to use one of the alternate chains can reference their ACME client's documentation for instructions on how to request the alternate chain (for example, [certbot's `--preferred-chain` flag](https://eff-certbot.readthedocs.io/en/stable/using.html#certbot-command-line-options)). diff --git a/content/en/docs/a-warm-welcome-to-asn1-and-der.md b/content/en/docs/a-warm-welcome-to-asn1-and-der.md index fa699c891..78bb64f89 100644 --- a/content/en/docs/a-warm-welcome-to-asn1-and-der.md +++ b/content/en/docs/a-warm-welcome-to-asn1-and-der.md @@ -560,7 +560,7 @@ Point ::= SEQUENCE { ``` So now, to encode a Point with just an x coordinate of 9, instead of -encoding x as a UNIVERSAL INTEGER, you'd sets bit 8 and 7 of the encoded +encoding x as a UNIVERSAL INTEGER, you'd set bits 8 and 7 of the encoded tag to (1, 0) to indicate the context specific class, and set the low bits to 0, giving this encoding: diff --git a/content/en/docs/challenge-types.md b/content/en/docs/challenge-types.md index 133b6fe5e..48cefa3ad 100644 --- a/content/en/docs/challenge-types.md +++ b/content/en/docs/challenge-types.md @@ -108,7 +108,7 @@ Pros: - You can use this challenge to issue certificates containing wildcard domain names. - It works well even if you have multiple web servers. -- You can use this challenge to domain names whose webservers aren't exposed to the public internet. +- You can use this challenge to validate domain names whose webservers aren't exposed to the public internet. Cons: diff --git a/content/en/docs/faq.md b/content/en/docs/faq.md index d4d6d67a1..f54688051 100644 --- a/content/en/docs/faq.md +++ b/content/en/docs/faq.md @@ -118,6 +118,6 @@ We ask that [ACME clients perform routine renewals at random times](https://lets ## Where can I learn more about TLS/SSL and PKI in general? -Longtime security researcher and practitioner, Ivan Ristić, published a configuration guide that provides useful information about what you should consider as you set up your TLS configuration. +Longtime security researcher and practitioner, Ivan Ristić, published a configuration guide that provides useful information about what you should consider as you set up your TLS configuration. -For more extensive background and greater detail, we recommend Bulletproof TLS and PKI, also written by Ristić. +For more extensive background and greater detail, we recommend Bulletproof TLS and PKI, also written by Ristić. diff --git a/content/en/docs/glossary.md b/content/en/docs/glossary.md index 6194c95c1..1633bc253 100644 --- a/content/en/docs/glossary.md +++ b/content/en/docs/glossary.md @@ -37,7 +37,7 @@ Note for translators: {{% def id="BRs" name="Baseline Requirements" abbr="BRs" %}} A set of technical and policy requirements for CAs. Since all major [root programs](#def-root-program) incorporate the Baseline Requirements, CAs must follow these requirements to be trusted by most browsers. {{% /def %}} -{{% def id="CAA" name="Certificate Authority Authorization" abbr="CAA" abbr_first="1" %}} A DNS record that specifies which [CAs](#def-CA) are allowed to issue certificate for the corresponding domain name. CAA records are checked by CAs, not by browsers. [Let's Encrypt](#def-LE) [honors CAA records](/docs/caa) as required by the [Baseline Requirements](#def-BRs). - [Wikipedia](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) {{% /def %}} +{{% def id="CAA" name="Certificate Authority Authorization" abbr="CAA" abbr_first="1" %}} A DNS record that specifies which [CAs](#def-CA) are allowed to issue certificates for the corresponding domain name. CAA records are checked by CAs, not by browsers. [Let's Encrypt](#def-LE) [honors CAA records](/docs/caa) as required by the [Baseline Requirements](#def-BRs). - [Wikipedia](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) {{% /def %}} {{% def id="CNAME" name="Canonical Name record" abbr="CNAME" %}} A DNS entry which maps one domain name to another, referred to as the Canonical Name. [Wikipedia](https://en.wikipedia.org/wiki/CNAME_record) {{% /def %}} diff --git a/content/en/docs/profiles.md b/content/en/docs/profiles.md index b6c95936f..34b444395 100644 --- a/content/en/docs/profiles.md +++ b/content/en/docs/profiles.md @@ -33,7 +33,7 @@ The classic profile is the default profile selected for all orders which do not | [Max Names](#max-names) | 100 | | [Identifier Types](#identifier-types) | DNS | -\*: If the CSR submitted at finalize time requests a specific Common Name that corresponds to a dNSName Subject Alternative Name, that request is honored. If the the CSR does not request a specific Common Name, the first dNSName Subject Alternative Name requested will be promoted into the Subject Common Name. If either the requested name or the to-be-promoted name is too long to fit in the Common Name field (64+ characters), the Common Name will be left empty. +\*: If the CSR submitted at finalize time requests a specific Common Name that corresponds to a dNSName Subject Alternative Name, that request is honored. If the CSR does not request a specific Common Name, the first dNSName Subject Alternative Name requested will be promoted into the Subject Common Name. If either the requested name or the to-be-promoted name is too long to fit in the Common Name field (64+ characters), the Common Name will be left empty. †: Only included for certificates with RSA public keys. @@ -120,7 +120,7 @@ this profile. | [Max Names](#max-names) | 100 | | [Identifier Types](#identifier-types) | DNS | -\*: If the CSR submitted at finalize time requests a specific Common Name that corresponds to a dNSName Subject Alternative Name, that request is honored. If the the CSR does not request a specific Common Name, the first dNSName Subject Alternative Name requested will be promoted into the Subject Common Name. If either the requested name or the to-be-promoted name is too long to fit in the Common Name field (64+ characters), the Common Name will be left empty. +\*: If the CSR submitted at finalize time requests a specific Common Name that corresponds to a dNSName Subject Alternative Name, that request is honored. If the CSR does not request a specific Common Name, the first dNSName Subject Alternative Name requested will be promoted into the Subject Common Name. If either the requested name or the to-be-promoted name is too long to fit in the Common Name field (64+ characters), the Common Name will be left empty. †: Only included for certificates with RSA public keys. diff --git a/content/en/docs/staging-environment.md b/content/en/docs/staging-environment.md index 5aefc599f..c661716a8 100644 --- a/content/en/docs/staging-environment.md +++ b/content/en/docs/staging-environment.md @@ -64,7 +64,7 @@ If you wish to modify a test-only client to trust the staging environment for te * Key type: `ECDSA P-384` * Certificate details (self-signed): [der](/certs/staging/gen-y/root-ye.der), [pem](/certs/staging/gen-y/root-ye.pem), [txt](/certs/staging/gen-y/root-ye.txt) * Certificate details (cross-signed by Bogus Broccoli X2): [der](/certs/staging/gen-y/root-ye-by-x2.der), [pem](/certs/staging/gen-y/root-ye-by-x2.pem), [txt](/certs/staging/gen-y/root-ye-by-x2.txt) -* **Yearning Yonder Yam Root YR** +* **Yonder Yam Root YR** * Subject: `O = ISRG, CN = (STAGING) Yonder Yam Root YR` * Key type: `RSA 4096` * Certificate details (self-signed): [der](/certs/staging/gen-y/root-yr.der), [pem](/certs/staging/gen-y/root-yr.pem), [txt](/certs/staging/gen-y/root-yr.txt) diff --git a/content/en/post/2015-10-29-phishing-and-malware.markdown b/content/en/post/2015-10-29-phishing-and-malware.markdown index 0c3199922..9b49f6eb1 100644 --- a/content/en/post/2015-10-29-phishing-and-malware.markdown +++ b/content/en/post/2015-10-29-phishing-and-malware.markdown @@ -13,7 +13,7 @@ Deciding what to do here has been tough. On the one hand, we don’t like these # CAs Make Poor Content Watchdogs -Let’s Encrypt is going to be issuing Domain Validation (DV) certificates. On a technical level, a DV certificate asserts that a public key belongs to a domain -- it says nothing else about a site’s content or who runs it. DV certificates do not include any information about a website’s reputation, real-world identity, or safety. However, many people believe the mere presence of DV certificate ought to connote at least some of these things. +Let’s Encrypt is going to be issuing Domain Validation (DV) certificates. On a technical level, a DV certificate asserts that a public key belongs to a domain -- it says nothing else about a site’s content or who runs it. DV certificates do not include any information about a website’s reputation, real-world identity, or safety. However, many people believe the mere presence of a DV certificate ought to connote at least some of these things. Treating a DV certificate as a kind of “seal of approval” for a site’s content is problematic for several reasons. diff --git a/content/en/post/2015-12-3-entering-public-beta.markdown b/content/en/post/2015-12-3-entering-public-beta.markdown index 68c53f3cd..dff02e348 100644 --- a/content/en/post/2015-12-3-entering-public-beta.markdown +++ b/content/en/post/2015-12-3-entering-public-beta.markdown @@ -19,7 +19,7 @@ We have more work to do before we’re comfortable dropping the beta label entir ~~Instructions for getting a certificate with the *Let's Encrypt client* can be found *here*.~~ -Update: Feb. 10 2010, instructions for getting a certificate with [Certbot](https://github.com/certbot/certbot) (Let's Encrypt recommended client) can be found [here](https://certbot.eff.org/). +Update: Feb. 10 2016, instructions for getting a certificate with [Certbot](https://github.com/certbot/certbot) (Let's Encrypt recommended client) can be found [here](https://certbot.eff.org/). [Let’s Encrypt Community Support](https://community.letsencrypt.org/) is an invaluable resource for our community, we strongly recommend making use of the site if you have any questions about Let’s Encrypt. diff --git a/content/en/post/2018-12-31-looking-forward-to-2019.md b/content/en/post/2018-12-31-looking-forward-to-2019.md index 750319696..dc7c46510 100644 --- a/content/en/post/2018-12-31-looking-forward-to-2019.md +++ b/content/en/post/2018-12-31-looking-forward-to-2019.md @@ -14,7 +14,7 @@ We'd like to thank all of the people and organizations who worked hard to create This year we created a new website for the legal entity behind Let's Encrypt, [Internet Security Research Group (ISRG)](https://www.abetterinternet.org/), 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. -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. +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. ## Service Growth diff --git a/content/en/post/2019-10-09-onboarding-your-customers-with-lets-encrypt-and-acme.md b/content/en/post/2019-10-09-onboarding-your-customers-with-lets-encrypt-and-acme.md index c9fabb003..970c7e372 100644 --- a/content/en/post/2019-10-09-onboarding-your-customers-with-lets-encrypt-and-acme.md +++ b/content/en/post/2019-10-09-onboarding-your-customers-with-lets-encrypt-and-acme.md @@ -62,7 +62,7 @@ directly provision their TXT records is to support the best practice of periodically rotating your ACME account key. Because the digest value used for DNS-01 validation is computed based on your current ACME account key, it will change whenever you rotate your account key. If you -asked customers to provision their TXT record manually , that means +asked customers to provision their TXT record manually, that means notifying potential new customers that the value you asked them to put in DNS isn't valid anymore, and they need to use a different one. That’s pretty inconvenient! If you use the CNAME method instead, there’s only one diff --git a/content/en/post/2020-09-17-new-root-and-intermediates.md b/content/en/post/2020-09-17-new-root-and-intermediates.md index adde88505..cd2277da4 100644 --- a/content/en/post/2020-09-17-new-root-and-intermediates.md +++ b/content/en/post/2020-09-17-new-root-and-intermediates.md @@ -119,7 +119,7 @@ their Subject Common Names from “Let’s Encrypt Authority X3” to just “R3 relying on the previously-redundant Organization Name field to supply the words “Let’s Encrypt”. We’ve shortened their Authority Information Access Issuer and CRL Distribution Point URLs, and we’ve dropped their CPS and OCSP -urls entirely. All of this adds up to another approximately 120 bytes of +URLs entirely. All of this adds up to another approximately 120 bytes of savings without making any substantive change to the useful information in the certificate. diff --git a/content/en/post/2021-09-14-speed-at-scale.md b/content/en/post/2021-09-14-speed-at-scale.md index afc408c10..8b5a3f864 100644 --- a/content/en/post/2021-09-14-speed-at-scale.md +++ b/content/en/post/2021-09-14-speed-at-scale.md @@ -12,7 +12,7 @@ Today, Let’s Encrypt provides TLS for 4.5 million Shopify domains. We sat down “In 2016, the TLS team started transitioning all of our merchants' stores to HTTPS through Let’s Encrypt,” Charles said. “And when we started exploring the concept a few years earlier, it was a daunting task.” Implementing TLS for 680,000+ domains wasn’t just daunting, Charles and the team needed automated management, something that simply didn’t exist. “We didn’t want to have TLS be the merchant’s responsibility,” Charles said. -Back in 2016, although Let’s Encrypt had been making noise, it wasn’t Shopify’s first choice for a CA. “We ended up going with a different option that turned out to be problematic because the API was so slow,” Charles said. “We did some napkin math and realized it was going to take us around 100 days to provision all of our certs for our merchants. If this solution had been just for regular issuance, it would have been fine, but an emergency would be very problematic.” +Back in 2016, although Let’s Encrypt had been making noise, it wasn’t Shopify’s first choice for a CA. “We ended up going with a different option that turned out to be problematic because the API was so slow,” Charles said. “We did some napkin math and realized it was going to take us around 100 days to provision all of our certs for our merchants. If this solution had been just for regular issuance, it would have been fine, but an emergency would be very problematic.” That realization led Charles and the team to give Let’s Encrypt a try, making them one of the first single Let’s Encrypt subscribers to request and provision certs at a X00,000 scale. “We were able to roll out all of our domains in a couple of hours,” Charles said. “And to be frank, I think it was our ordering process that caused issuance to take even that long. It was very encouraging.” diff --git a/content/en/post/2021-10-28-tls-simply-and-automatically.md b/content/en/post/2021-10-28-tls-simply-and-automatically.md index 659102a97..72304610f 100644 --- a/content/en/post/2021-10-28-tls-simply-and-automatically.md +++ b/content/en/post/2021-10-28-tls-simply-and-automatically.md @@ -9,7 +9,7 @@ OVHcloud, the largest hosting provider in Europe, has used Let’s Encrypt for T [OVHcloud](https://ovhcloud.com/) first started looking into using Let’s Encrypt certificates because the team saw a need for the protection provided by TLS for every customer (remember, way back five years ago, when that wasn’t just a thing everybody did?). “Our goal was to deliver TLS simply. We didn’t want to have to write a tutorial for our customers to upload a cert, but instead just click and it works,” said Guillaume Marchand, OVHcloud’s Technical Team Lead. -They considered building their own CA but determined the cost and complexity of doing so would be impractical. Instead, they build an ACME client to prepare for using Let’s Encrypt. It took about six months, “we simply followed the RFC and did a bit of reverse engineering of Certbot,” said Guillaume. In addition to a custom client, OVHcloud automated their Certificate Signing Request (CSR) process and certificate installation process. +They considered building their own CA but determined the cost and complexity of doing so would be impractical. Instead, they built an ACME client to prepare for using Let’s Encrypt. It took about six months, “we simply followed the RFC and did a bit of reverse engineering of Certbot,” said Guillaume. In addition to a custom client, OVHcloud automated their Certificate Signing Request (CSR) process and certificate installation process.

Schematic of how OVHcloud automatically and simply gets Let's Encrypt certificates

diff --git a/content/en/post/2023-12-13-ngos.md b/content/en/post/2023-12-13-ngos.md index f3c1044b4..1d5b27c13 100644 --- a/content/en/post/2023-12-13-ngos.md +++ b/content/en/post/2023-12-13-ngos.md @@ -12,7 +12,7 @@ Beyond being a big number, what does that signify? What's the importance of havi ## Serving .org at Internet scale -Let's Encrypt serves 57% of all websites using the .org top level domain (TLD), which is commonly used by nonprofits. In the US alone there are 1.8M registered nonprofit organizations. And while the focus of these organizations are varied, all of them rely on the Internet in some capacity. +Let's Encrypt serves 57% of all websites using the .org top level domain (TLD), which is commonly used by nonprofits. In the US alone there are 1.8M registered nonprofit organizations. And while the focus of these organizations is varied, all of them rely on the Internet in some capacity. When a nonprofit uses a TLS certificate on their website, it protects their visitors and stakeholders from snoopers, MITM attacks, and surveillance. Without TLS, nonprofits' content could be changed without their knowledge or their visitors' private information could be compromised. Access to free and automated TLS via Let's Encrypt means these nonprofits face as few barriers as possible to adopting TLS. diff --git a/content/en/post/2023-12-28-EOY-letter-2023.md b/content/en/post/2023-12-28-EOY-letter-2023.md index 4f7cbc5f8..c76e35a03 100644 --- a/content/en/post/2023-12-28-EOY-letter-2023.md +++ b/content/en/post/2023-12-28-EOY-letter-2023.md @@ -18,7 +18,7 @@ One of the biggest observations I've made during Josh's absence is that all 23 p [Let's Encrypt](http://letsencrypt.org) is supporting 40 million more websites than a year ago, bringing the total to over [360 million](http://letsencrypt.org/stats). The engineering team has grown to 12 people who are responsible for our continued reliability and ability to scale. But they're not maintaining the status quo. Let's Encrypt engineers are pushing forward our expectations for ourselves and for the WebPKI community. We've added shorter-lived certificates to our 2024 roadmap. We're committing to this work because sub-10 day certificates significantly reduce the impact of key compromise and it broadens the universe of people who can use our certs. In addition, the team started an ambitious project to develop a new Certificate Transparency implementation because the only existing option cannot scale for the future and is prone to operational fragility. These projects are led by two excellent technical leads, Aaron Gable and James Renken, who balance our ambition with our desire for a good quality of life for our teams. -[Prossimo](http://memorysafety.org) continues to deliver highly performant and memory safe software and components in a world that is increasingly eager to address the memory safety problem. This was evidenced by participation at [Tectonics](https://tectonics.memorysafety.org/), a gathering we hosted which drew industry leaders for [invigorated conversation](https://www.memorysafety.org/blog/tectonics-recap/). Meanwhile, initiatives like our [memory safe AV1 decoder](https://www.memorysafety.org/initiative/av1/) are in line to replace a C version in Google Chrome. This change would improve security for billions of people. We're grateful to the community that helps to guide and implement our efforts in this area, including Dirkjan Ochtman, the firms Tweede golf and Ferrous Systems, and the maintainers of the many projects we are involved with +[Prossimo](http://memorysafety.org) continues to deliver highly performant and memory safe software and components in a world that is increasingly eager to address the memory safety problem. This was evidenced by participation at [Tectonics](https://tectonics.memorysafety.org/), a gathering we hosted which drew industry leaders for [invigorated conversation](https://www.memorysafety.org/blog/tectonics-recap/). Meanwhile, initiatives like our [memory safe AV1 decoder](https://www.memorysafety.org/initiative/av1/) are in line to replace a C version in Google Chrome. This change would improve security for billions of people. We're grateful to the community that helps to guide and implement our efforts in this area, including Dirkjan Ochtman, the firms Tweede golf and Ferrous Systems, and the maintainers of the many projects we are involved with. Our newest project, [Divvi Up](http://divviup.org), brought on our first two subscribers in 2023. [Horizontal](https://wearehorizontal.org/index), a small international nonprofit serving Human Rights Defenders, will be [collecting privacy-preserving telemetry metrics](https://divviup.org/blog/horizontal/) about the users of their Tella app, which people use to document human rights violations. Mozilla is using Divvi Up to [gain insight into aspects of user behavior](https://divviup.org/blog/divvi-up-in-firefox/) in the [Firefox ](https://www.mozilla.org/en-US/firefox/new/)browser. It took a combination of focus and determination to get us to a production-ready state and our technical lead, Brandon Pitman played a big role in getting us there. diff --git a/content/en/post/2024-04-12-changes-to-issuance-chains.md b/content/en/post/2024-04-12-changes-to-issuance-chains.md index 098e1762b..b30aee696 100644 --- a/content/en/post/2024-04-12-changes-to-issuance-chains.md +++ b/content/en/post/2024-04-12-changes-to-issuance-chains.md @@ -8,7 +8,7 @@ excerpt: "Using our new RSA & ECDSA intermediates to sign certificates starting On **Thursday, June 6th, 2024**, we will be switching issuance to use our [new intermediate certificates](https://letsencrypt.org/2024/03/19/new-intermediate-certificates). Simultaneously, we are removing the DST Root CA X3 cross-sign from our API, aligning with our strategy to shorten the Let's Encrypt chain of trust. We will begin issuing ECDSA end-entity certificates from a default chain that just contains a single ECDSA intermediate, removing a second intermediate and the option to issue an ECDSA end-entity certificate from an RSA intermediate. The Let's Encrypt staging environment will make an equivalent change on April 24th, 2024. -**Most Let's Encrypt Subscribers will not need to take any action** in response to this change because ACME clients, like [certbot](https://certbot.eff.org/), will automatically configure the new intermediates when certificates are renewed. The Subscribers who will be affected are those who currently pins intermediate certificates (more on that later). +**Most Let's Encrypt Subscribers will not need to take any action** in response to this change because ACME clients, like [certbot](https://certbot.eff.org/), will automatically configure the new intermediates when certificates are renewed. The Subscribers who will be affected are those who currently pin intermediate certificates (more on that later). The following diagram depicts what the new hierarchy looks like. You can see details of all of the certificates on our [updated Chain of Trust documentation page](https://letsencrypt.org/certificates/). diff --git a/content/en/post/2025-02-14-encryption-for-everybody.md b/content/en/post/2025-02-14-encryption-for-everybody.md index 5a31237ca..c15dd675d 100644 --- a/content/en/post/2025-02-14-encryption-for-everybody.md +++ b/content/en/post/2025-02-14-encryption-for-everybody.md @@ -21,6 +21,6 @@ From a [community forum](https://letsencrypt.org/2015/08/13/lets-encrypt-communi Each month we'll highlight a different set of people behind our "everybody." Who do you want to see us highlight? What use cases of Let's Encrypt have you seen that amazed you? What about our work do you hope we'll continue or improve as we go forward? Let us know on [LinkedIn](https://www.linkedin.com/company/lets-encrypt), or drop a note to . -*Encryption for Everybody* is our unofficial tagline for this tenth anniversary year. What we love about it is that, yes, it captures our commitment to ensuring anyone around the world can easily get a cert for free. But more importantly, it captures the reality that technical innovation won't work without people believing in it and supporting it. We're grateful that, for ten years (and counting!), our community of supporters has made an impact on the lives of billions of Internet users---an impact that's made theWeb more secure and privacy respecting for everybody, everywhere. +*Encryption for Everybody* is our unofficial tagline for this tenth anniversary year. What we love about it is that, yes, it captures our commitment to ensuring anyone around the world can easily get a cert for free. But more importantly, it captures the reality that technical innovation won't work without people believing in it and supporting it. We're grateful that, for ten years (and counting!), our community of supporters has made an impact on the lives of billions of Internet users---an impact that's made the Web more secure and privacy-respecting for everybody, everywhere. [Internet Security Research Group (ISRG)](https://abetterinternet.org/) is the parent organization of [Let's Encrypt](https://letsencrypt.org/), [Prossimo](https://memorysafety.org/), and [Divvi Up](https://divviup.org/). ISRG is a 501(c)(3) nonprofit. If you'd like to support our work, please consider [getting involved](https://www.abetterinternet.org/getinvolved/), [donating](https://www.abetterinternet.org/donate/), or encouraging your company to [become a sponsor](https://www.abetterinternet.org/sponsor/). \ No newline at end of file diff --git a/content/en/post/2025-04-30-pebbleacmeimplementation.md b/content/en/post/2025-04-30-pebbleacmeimplementation.md index b1bac9da4..c0ba33a5c 100644 --- a/content/en/post/2025-04-30-pebbleacmeimplementation.md +++ b/content/en/post/2025-04-30-pebbleacmeimplementation.md @@ -39,7 +39,7 @@ Pebble is also deliberately different from Boulder in some places in order to pr For instance, the Let's Encrypt service currently offers its `newAccount` resource at the path `/acme/new-acct`, whereas Pebble uses a different name `/sign-me-up`, so clients will be reminded to check the directory rather than assuming a specific path. Other substantive differences include: -- Pebble rejects 5% of all requests as having a invalid nonce, even if the nonce was otherwise valid, so clients can test how they respond this error condition +- Pebble rejects 5% of all requests as having an invalid nonce, even if the nonce was otherwise valid, so clients can test how they respond to this error condition - Pebble only reuses valid authorizations 50% of the time, so clients can check their ability to perform validations when they might not have expected to - Pebble truncates timestamps to a different degree of precision than Boulder - Unlike Boulder, Pebble respects the notBefore and notAfter fields of new-order requests diff --git a/content/en/post/2025-06-04-how-we-reduced-the-impact-of-zombie-clients.md b/content/en/post/2025-06-04-how-we-reduced-the-impact-of-zombie-clients.md index b78184873..da8e7694d 100644 --- a/content/en/post/2025-06-04-how-we-reduced-the-impact-of-zombie-clients.md +++ b/content/en/post/2025-06-04-how-we-reduced-the-impact-of-zombie-clients.md @@ -63,7 +63,7 @@ Currently, the user interface for an affected subscriber looks like this: Let's Encrypt unpause interface -This link would be provided via an ACME error message in response to any request that was blocked due to a pause account-hostname pair. +This link would be provided via an ACME error message in response to any request that was blocked due to a paused account-hostname pair. As it's turned out, the unpause option shown above has only been used by about 3% of affected accounts! This goes to show that most of the zombies we've paused were, in fact, well and truly forgotten about. diff --git a/content/en/upcoming-features.md b/content/en/upcoming-features.md index 25b31e3a3..566547f57 100644 --- a/content/en/upcoming-features.md +++ b/content/en/upcoming-features.md @@ -22,7 +22,7 @@ To comply with CA/Browser Forum Baseline Requirement changes, we are ## Shutdown of Expiration Notification Emails -On June 4, 2025, we [turned off our expiration email notification service](https://letsencrypt.org/2025/01/22/ending-expiration-emails/), and delete all email addresses associated with ACME accounts from our production database. +On June 4, 2025, we [turned off our expiration email notification service](https://letsencrypt.org/2025/01/22/ending-expiration-emails/), and deleted all email addresses associated with ACME accounts from our production database. ## Removal of OCSP URLs diff --git a/i18n/en.toml b/i18n/en.toml index b34d4dcd1..067498a45 100644 --- a/i18n/en.toml +++ b/i18n/en.toml @@ -13,7 +13,7 @@ other = "Donate" other = "Sponsor" [home_hero_annual_report] -other = "Read all about our nonprofit work this year in our 2025 Annual Report." +other = "Read all about our nonprofit work this year in our 2025 Annual Report." [home_major_sponsors] other = "Major Sponsors and Funders"