diff --git a/content/en/caaproblem.md b/content/en/caaproblem.md index e5bd1a85d..6fe41aefd 100644 --- a/content/en/caaproblem.md +++ b/content/en/caaproblem.md @@ -32,8 +32,8 @@ hash of the names on the cert (you can disregard), then the list of names on the cert. The date is when the affected cert was issued. You can download this file and look up your account id(s) (if you received an -email, your account ids were in that email). For each certificate -associated you will need to renew and replace it, unless you have renewed it +email, your account ids were in that email). For each certificate listed, +you will need to renew and replace it, unless you have renewed it more recently than the date listed. For instance, if you know your ACME client always renews certificates when they are 30 days from expiration, you can safely ignore any entries with a date earlier than 2020-01-02. diff --git a/content/en/docs/certificates-for-localhost.md b/content/en/docs/certificates-for-localhost.md index da870f49a..2b846cda9 100644 --- a/content/en/docs/certificates-for-localhost.md +++ b/content/en/docs/certificates-for-localhost.md @@ -37,7 +37,7 @@ used alongside a web site to offer extra features. For instance, the Dropbox and Spotify desktop apps scan for files from across your machine, which a web app would not be allowed to do. One common approach is for these native apps to offer a web service on localhost, and have the web app make requests -to it via XMLHTTPRequest (XHR) or WebSockets. The web app almost always uses HTTPS, which +to it via XMLHttpRequest (XHR) or WebSockets. The web app almost always uses HTTPS, which means that browsers will forbid it from making XHR or WebSockets requests to non-secure URLs. This is called Mixed Content Blocking. To communicate with the web app, the native app needs to provide a secure web service. diff --git a/content/en/docs/dst-root-ca-x3-expiration-september-2021.md b/content/en/docs/dst-root-ca-x3-expiration-september-2021.md index c4fb51d5f..3f5070c3b 100644 --- a/content/en/docs/dst-root-ca-x3-expiration-september-2021.md +++ b/content/en/docs/dst-root-ca-x3-expiration-september-2021.md @@ -15,7 +15,7 @@ show_lastmod: 1 > As planned, the DST Root CA X3 cross-sign has expired, and we're now using our own ISRG Root X1 for trust on almost all devices. For more details about the plan, keep reading! > We have also updated our Production Chain Changes thread on our community forum - [our team and community are here and ready to help](https://community.letsencrypt.org/t/production-chain-changes/150739/4) with any questions you may have about this expiration. -On September 30 2021, there will be a small change in how older browsers and devices +On September 30, 2021, there will be a small change in how older browsers and devices trust Let's Encrypt certificates. If you run a typical website, you won't notice a difference - the vast majority of your visitors will still accept your Let's Encrypt certificate. If you provide an API or have to support IoT devices, you diff --git a/content/en/docs/integration-guide.md b/content/en/docs/integration-guide.md index 6872d6552..c3bc48bd1 100644 --- a/content/en/docs/integration-guide.md +++ b/content/en/docs/integration-guide.md @@ -46,7 +46,7 @@ The upshot of this is that, if you are a hosting provider, you do not need to ge In ACME, it's possible to create one account and use it for all authorizations and issuances, or create one account per customer. This flexibility may be valuable. For instance, some hosting providers may want to use one account per customer, and store the account keys in different contexts, so that an account key compromise doesn't allow issuance for all of their customers. -However, for most larger hosting providers we recommend using a single account and guarding the corresponding account key well. This makes it easier to identify certificates belonging to the same entity, and easier to provide rate limits adjustments if needed. We will be unable to effectively adjust rate limits if many different accounts are used. +However, for most larger hosting providers we recommend using a single account and guarding the corresponding account key well. This makes it easier to identify certificates belonging to the same entity, and easier to provide rate limit adjustments if needed. We will be unable to effectively adjust rate limits if many different accounts are used. # Multi-domain (SAN) Certificates diff --git a/content/en/post/2019-11-20-how-le-runs-ct-logs.md b/content/en/post/2019-11-20-how-le-runs-ct-logs.md index 0d7c07876..d251b7edc 100644 --- a/content/en/post/2019-11-20-how-le-runs-ct-logs.md +++ b/content/en/post/2019-11-20-how-le-runs-ct-logs.md @@ -77,7 +77,7 @@ The certificate transparency front end, or [CTFE](https://github.com/google/cert # Load Balancing -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. +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 balances that traffic to CTFE pods. We employ IP and user agent based rate limiting at this Nginx layer. @@ -92,7 +92,7 @@ We developed a free and open source tool named [ct-woodpecker](https://github.co Here are some ways we may be able to improve the efficiency of our system in the future: * 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. -* See if we can successfully use a cheaper form of storage than IO1 block storage and provisioned IOPs. +* See if we can successfully use a cheaper form of storage than IO1 block storage and provisioned IOPS. * See if we can reduce the Kubernetes worker EC2 instance size or use fewer EC2 instances. # Support Let’s Encrypt diff --git a/content/en/post/2021-01-21-next-gen-database-servers.md b/content/en/post/2021-01-21-next-gen-database-servers.md index 885d19415..1133dae66 100644 --- a/content/en/post/2021-01-21-next-gen-database-servers.md +++ b/content/en/post/2021-01-21-next-gen-database-servers.md @@ -30,7 +30,7 @@ The previous generation of database hardware was powerful but it was regularly b CPU 2x Intel Xeon E5-2650
Total 24 cores / 48 threads - 2x AMD EPYC 7542
Total 64 cores / 128 threads + 2x AMD EPYC 7542
Total 64 cores / 128 threads diff --git a/content/en/post/2022-04-13-receiving-the-levchin-prize.html b/content/en/post/2022-04-13-receiving-the-levchin-prize.html index 60a58f9b1..5690914bb 100644 --- a/content/en/post/2022-04-13-receiving-the-levchin-prize.html +++ b/content/en/post/2022-04-13-receiving-the-levchin-prize.html @@ -10,7 +10,7 @@ On April 13, 2022, the Real World Crypto steering committee presented the Max Levchin Prize for Real-World Cryptography to Let’s Encrypt. The - following is the speech delivered by our Executive Director, Josh Aas upon + following is the speech delivered by our Executive Director, Josh Aas, upon receiving the award. We’d like to thank our community for supporting us and invite you to join us