diff --git a/content/de/certificates.md b/content/de/certificates.md
index 2b068f7852..4e972a84be 100644
--- a/content/de/certificates.md
+++ b/content/de/certificates.md
@@ -81,7 +81,7 @@ nahtlos erstellen.
Das folgende Bild erklärt die Beziehungen zwischen unseren Zertifikaten:
-
+
# OCSP Signiertes Zertifikat
diff --git a/content/de/how-it-works.md b/content/de/how-it-works.md
index 5b7dbd8fe4..3bd282dea6 100644
--- a/content/de/how-it-works.md
+++ b/content/de/how-it-works.md
@@ -29,7 +29,8 @@ Neben den Herausforderungen bietet die Let's Encrypt-Zertifizierungsstelle auch
Die Agentensoftware erfüllt eine der gestellten Herausforderungen. Nehmen wir an, sie ist in der Lage, die zweite Aufgabe oben auszuführen: Sie erstellt eine Datei in einem angegebenen Pfad auf der Website `http://example.com`. Der Agent signiert die bereitgestellte Nonce ausserdem mit seinem privaten Schlüssel. Nachdem der Agent diese Schritte ausgeführt hat, benachrichtigt er die Zertifizierungsstelle, dass sie zur Validierung bereit ist.
@@ -38,7 +39,8 @@ Dann ist es die Aufgabe der Zertifizierungsstelle, zu überprüfen, ob die Auffo
Wenn die Signatur über die Nonce gültig ist und die Herausforderungen ausgecheckt werden, ist der durch den öffentlichen Schlüssel identifizierte Agent berechtigt, die Zertifikatsverwaltung für `example.com` durchzuführen. Wir nennen das Schlüsselpaar, dass der Agent ein "autorisiertes Schlüsselpaar" für `example.com` verwendet hat.
@@ -53,12 +55,14 @@ Wenn die Let's Encrypt-Zertifizierungsstelle die Anforderung erhält, werden bei
Der Widerruf funktioniert auf ähnliche Weise. Der Agent unterzeichnet eine Sperranforderung mit dem für `example.com` autorisierten Schlüsselpaar, und die Let's Encrypt-Zertifizierungsstelle überprüft, ob die Anforderung autorisiert ist. In diesem Fall werden Sperrinformationen in den normalen Sperrkanälen (z.B. OCSP) veröffentlicht, sodass vertrauende Parteien wie Browser wissen können, dass sie das widerrufene Zertifikat nicht akzeptieren sollten.
diff --git a/content/de/trademarks.md b/content/de/trademarks.md
index 03689d43f1..ab897ec966 100644
--- a/content/de/trademarks.md
+++ b/content/de/trademarks.md
@@ -266,7 +266,7 @@ dieser Richtlinie haben, können Sie uns gerne unter
Unser Standardlogo und Text. Abgesehen von wenigen Ausnahmen ist dies
die Standard-Go-To-Version.
- 
+
EPS SVG PNG
### Let's Encrypt weit
@@ -274,7 +274,7 @@ die Standard-Go-To-Version.
Die breite Version unseres Logos und Textes. Verwenden Sie dies in
Kontexten, in denen der vertikale Raum begrenzt ist.
- 
+
EPS SVG PNG
### Let's Encrypt nur Schlüssel
@@ -284,5 +284,5 @@ Encrypt" deutlich sichtbar ist oder an anderer Stelle auf der Seite oder
im Design festgelegt wurde. (Verwenden Sie im Zweifelsfall ein anderes
Format.)
- 
+
EPS SVG PNG
diff --git a/content/en/how-it-works.md b/content/en/how-it-works.md
index 3057a53a64..cbc7b113d5 100644
--- a/content/en/how-it-works.md
+++ b/content/en/how-it-works.md
@@ -3,7 +3,7 @@ title: How It Works
linkTitle: How Let's Encrypt Works
slug: how-it-works
top_graphic: 3
-lastmod: 2019-10-18
+lastmod: 2020-10-28
---
{{< lastmod >}}
@@ -27,7 +27,8 @@ Along with the challenges, the Let's Encrypt CA also provides a nonce that the a
The agent software completes one of the provided sets of challenges. Let's say it is able to accomplish the second task above: it creates a file on a specified path on the `http://example.com` site. The agent also signs the provided nonce with its private key. Once the agent has completed these steps, it notifies the CA that it's ready to complete validation.
@@ -36,7 +37,8 @@ Then, it's the CA's job to check that the challenges have been satisfied. The C
If the signature over the nonce is valid, and the challenges check out, then the agent identified by the public key is authorized to do certificate management for `example.com`. We call the key pair the agent used an "authorized key pair" for `example.com`.
@@ -52,13 +54,15 @@ When the Let's Encrypt CA receives the request, it verifies both signatures
Revocation works in a similar manner. The agent signs a revocation request with the key pair authorized for `example.com`, and the Let's Encrypt CA verifies that the request is authorized. If so, it publishes revocation information into the normal revocation channels (i.e. OCSP), so that relying parties such as browsers can know that they shouldn't accept the revoked certificate.
diff --git a/content/en/post/2016-4-12-leaving-beta-new-sponsors.markdown b/content/en/post/2016-4-12-leaving-beta-new-sponsors.markdown
index e181f32301..fd04bc01d1 100644
--- a/content/en/post/2016-4-12-leaving-beta-new-sponsors.markdown
+++ b/content/en/post/2016-4-12-leaving-beta-new-sponsors.markdown
@@ -13,7 +13,7 @@ Let’s Encrypt is leaving beta today. We’re also excited to announce that fou
Since our beta began in September 2015 we’ve issued more than 1.7 million certificates for more than 3.8 million websites. We’ve gained tremendous operational experience and confidence in our systems. The beta label is simply not necessary any more.
-
+
We set out to encrypt 100% of the Web. We’re excited to be off to a strong start, and with so much support across the industry.
diff --git a/content/en/post/2016-6-22-https-progress-june-2016.markdown b/content/en/post/2016-6-22-https-progress-june-2016.markdown
index 3f7886ce7c..90dd9acda9 100644
--- a/content/en/post/2016-6-22-https-progress-june-2016.markdown
+++ b/content/en/post/2016-6-22-https-progress-june-2016.markdown
@@ -11,7 +11,7 @@ Our goal with Let’s Encrypt is to get the Web to 100% HTTPS. We’d like to gi
Let’s Encrypt has issued more than 5 million certificates in total since we launched to the general public on December 3, 2015. Approximately 3.8 million of those are active, meaning unexpired and unrevoked. Our active certificates cover more than 7 million unique domains.
-
+
A couple of different factors have contributed heavily to this growth. The first is large-scale deployments from companies such as OVH, WordPress.com, Akamai, Shopify, Dreamhost, and Bitly. The second is our ability to serve individual sites globally with a focus on ease-of-use. If we’re going to get to 100% HTTPS we need to reach the “long tail” of the Web, which is in many ways more challenging due to the number of parties involved and widely varying degrees of technical competency.
diff --git a/content/en/post/2016-8-5-le-root-to-be-trusted-by-mozilla.markdown b/content/en/post/2016-8-5-le-root-to-be-trusted-by-mozilla.markdown
index 9e6906ed0f..2dc6d6ed8b 100644
--- a/content/en/post/2016-8-5-le-root-to-be-trusted-by-mozilla.markdown
+++ b/content/en/post/2016-8-5-le-root-to-be-trusted-by-mozilla.markdown
@@ -13,7 +13,7 @@ Public CAs need their certificates to be trusted by browsers and devices. CAs th
Getting a new root trusted and propagated broadly can take 3-6 years. In order to start issuing widely trusted certificates as soon as possible, we partnered with another CA, IdenTrust, which has a number of existing trusted roots. As part of that partnership, an IdenTrust root “vouches for” the certificates that we issue, thus making our certificates trusted. We’re incredibly grateful to IdenTrust for helping us to start carrying out our mission as soon as possible.
-
Chain of Trust Between Firefox and Let's Encrypt Certificates
+
Chain of Trust Between Firefox and Let's Encrypt Certificates
However, our plan has always been to operate as an independently trusted CA. Having our root trusted directly by the Mozilla root program represents significant progress towards that independence.
diff --git a/content/en/post/2017-1-6-le-2016-in-review.markdown b/content/en/post/2017-1-6-le-2016-in-review.markdown
index 298a92e20c..5c8d721517 100644
--- a/content/en/post/2017-1-6-le-2016-in-review.markdown
+++ b/content/en/post/2017-1-6-le-2016-in-review.markdown
@@ -12,7 +12,7 @@ Our first full year as a live CA was an exciting one. I’m incredibly proud of
At the start of 2016, Let’s Encrypt certificates had been available to the public for less than a month and we were supporting approximately 240,000 active (unexpired) certificates. That seemed like a lot at the time! Now we’re frequently issuing that many new certificates in a single day while supporting more than 20,000,000 active certificates in total. We’ve issued more than a million certificates in a single day a few times recently. We’re currently serving an average of 6,700 OCSP responses per second. We’ve done a lot of optimization work, we’ve had to add some hardware, and there have been some long nights for our staff, but we’ve been able to keep up and we’re ready for another year of [strong growth](https://letsencrypt.org/stats/).
-
+
We added a number of [new features](https://letsencrypt.org/upcoming-features/) during the past year, including support for the ACME DNS challenge, ECDSA signing, IPv6, and Internationalized Domain Names.
diff --git a/content/en/post/2017-6-28-hundred-million-certs.markdown b/content/en/post/2017-6-28-hundred-million-certs.markdown
index faaa54c6cd..6c01b19374 100644
--- a/content/en/post/2017-6-28-hundred-million-certs.markdown
+++ b/content/en/post/2017-6-28-hundred-million-certs.markdown
@@ -17,7 +17,7 @@ Third, it illustrates the power of automated certificate management. If getting
The total number of certificates we’ve issued is an interesting number, but it doesn’t reflect much about tangible progress towards our primary goal: a 100% HTTPS Web. To understand that progress we need to look at this graph:
-
+
When Let’s Encrypt’s service first became available, less than 40% of page loads on the Web used HTTPS. It took the Web 20 years to get to that point. In the 19 months since we launched, encrypted page loads have gone up by 18%, to nearly 58%. That’s an incredible rate of change for the Web. Contributing to this trend is what we’re most proud of.
diff --git a/content/en/trademarks.md b/content/en/trademarks.md
index 214e1d43ee..b9637763de 100644
--- a/content/en/trademarks.md
+++ b/content/en/trademarks.md
@@ -3,7 +3,7 @@ title: Trademark Policy
slug: trademarks
top_graphic: 1
date: 2018-09-19
-lastmod: 2018-09-19
+lastmod: 2020-10-28
english_is_canonical: 1
---
@@ -102,19 +102,19 @@ If you’d like to use the ISRG Marks in a way that’s not covered by this poli
Our standard logo and text. Outside of a few exceptions, this is the default, go-to version.
-
+
EPS SVG PNG
### Let's Encrypt Wide
The wide version of our logo and text. Use this in contexts where vertical space is limited.
-
+
EPS SVG PNG
### Let's Encrypt Lock Only
Our logo alone. Use this only when the "Let's Encrypt" word mark is clearly visible or has been well established elsewhere on the page or in the design. (When in doubt, use a different format.)
-
-EPS SVG PNG
\ No newline at end of file
+
+EPS SVG PNG
diff --git a/content/es/certificates.md b/content/es/certificates.md
index e7397bde13..fc85a4fa02 100644
--- a/content/es/certificates.md
+++ b/content/es/certificates.md
@@ -68,7 +68,7 @@ configuración perfectamente.
La siguiente imagen explica visualmente las relaciones entre nuestros certificados:
-
+
# Certificado firma OCSP
diff --git a/content/es/how-it-works.md b/content/es/how-it-works.md
index 70ddc1ea07..01221c347c 100644
--- a/content/es/how-it-works.md
+++ b/content/es/how-it-works.md
@@ -27,7 +27,8 @@ Junto con los retos, el Let's Encrypt CA también provee un `nonce` que el agent
El software de agente completa uno de los conjuntos de retos proveidos. Digamos que es capaz de realizar la segunda tarea anterior: crea un archivo en un *path* especifico en el site `http://example.com`. El agente también firma el `nonce` proveido con su llave privada. Una vez el agente ha completado estos pasos, notifica la AC que está listo para completar la validación.
@@ -36,7 +37,8 @@ Luego, es el trabajo de la AC verificar los que retos han sido satisfechos. La A
Si la firma sobre el `nonce` es válida, y los retos son válidos, entonces el agente identificado por su llave pública está autorizado a realizar la gestión de certificados para `example.com`. Llamamos el par de llaves que el agente usó un "par de llaves autorizado" para `example.com`.
@@ -52,13 +54,15 @@ Cuando el Let's Encrypt CA recibe una solicitud, verifica ambas firmas. Si todo
Revocación funciona de una manera similar. El agent firma una solicitud de revocación con el par de llaves autorizado para `example.com`, y el Let's Encrypt CA verifica que la solicitud es autorizada. Si lo es, publica información de revocación a los canales normales de revocación (i.e. OCSP), para que los confiados tales como navegadores pueden saber que no deben aceptar el certificado recovado.
diff --git a/content/es/trademarks.md b/content/es/trademarks.md
index 98e8381ee0..86665ee2c7 100644
--- a/content/es/trademarks.md
+++ b/content/es/trademarks.md
@@ -102,19 +102,19 @@ Si desea utilizar las Marcas ISRG de una manera que no está cubierta por esta p
Nuestro logotipo y texto estándar. Fuera de algunas excepciones, esta es la versión predeterminada.
-
+
EPS SVG PNG
### Let's Encrypt Ancho
La versión amplia de nuestro logo y texto. Use esto en contextos donde el espacio vertical es limitado.
-
+
EPS SVG PNG
### Let's Encrypt Logo
Nuestro logo solo. Use esto solo cuando la marca de la palabra "Let's Encrypt" sea claramente visible o esté bien establecida en otra parte de la página o en el diseño. (En caso de duda, use un formato diferente).
-
+
EPS SVG PNG
diff --git a/content/fr/certificates.md b/content/fr/certificates.md
index 02feb30bcb..f952160e6f 100644
--- a/content/fr/certificates.md
+++ b/content/fr/certificates.md
@@ -56,7 +56,7 @@ le certificat intermédiaire avec le sujet «Let’s Encrypt Authority X3» et
Le schéma ci-dessous décrit les relations entre nos certificats :
-
+
# Certificat de signature de l'OCSP
diff --git a/content/fr/how-it-works.md b/content/fr/how-it-works.md
index 9773443149..d7dffea3f5 100644
--- a/content/fr/how-it-works.md
+++ b/content/fr/how-it-works.md
@@ -27,7 +27,8 @@ En plus des défis, l'AC Let's Encrypt fournit également un nonce ("Number used
L'agent logiciel réussi l'un des défis fournis. Disons qu'il est capable d'accomplir la seconde tâche ci-dessus: Il crée un fichier à un emplacemet spécifié du site `http://example.com`. L'agent signe également le nonce fourni avec sa clef privée. Une fois que l'agent à terminé ces étapes, il informe l'autorité de certification (AC) qu'il est prêt à poursuivre la validation.
@@ -36,7 +37,8 @@ Ensuite, le travail de l'AC consiste à vérifier que les défis ont été relev
Si la signature sur le nonce est valide et que les défis sont validés, l'agent identifié par la clé publique est autorisé à effectuer la gestion des certificats pour `example.com`. Nous appelons la paire de clefs que l'agent a utilisé une "paire de clés autorisée" pour `example.com`.
@@ -51,12 +53,14 @@ Lorsque l'AC Let's Encrypt reçoit la demande, elle vérifie les deux signa
La révocation fonctionne de la même manière. L'agent signe une demande de révocation avec la paire de clefs autorisée pour `example.com`, et l'AC Let's Encrypt vérifie que la demande est autorisée. Si c'est le cas, elle publie les informations de révocation dans les canaux de révocation normaux (c'est-à-dire l'OCSP), de sorte que les parties dépendantes, telles que les navigateurs, puissent savoir qu'ils ne doivent pas accepter le certificat révoqué.
diff --git a/content/he/certificates.md b/content/he/certificates.md
index ca7b945c40..f15eefd9f5 100644
--- a/content/he/certificates.md
+++ b/content/he/certificates.md
@@ -54,7 +54,7 @@ IdenTrust חתמו באופן צולב את אישורי התווך שלנו ל
התמונה הבאה מסבירה את הקשרים בין האישורים שלנו בצורה חזותית:
-
+
# אישור חתימה OCSP
diff --git a/content/he/how-it-works.md b/content/he/how-it-works.md
index 9ff5974ee7..7fbb46061e 100644
--- a/content/he/how-it-works.md
+++ b/content/he/how-it-works.md
@@ -27,7 +27,8 @@ Let's Encrypt מזהה את מנהל השרת באמצעות מפתח צי
תכנית הסוכן משלימה את אחת מסדרות האתגרים שסופקו. נניח שהוא מצליח להשלים את המשימה השנייה שלעיל: הסוכן יוצר קובץ תחת נתיב מסוים באתר `http://example.com`. הסוכן גם חותם על האסימון המוצפן עם המפתח הפרטי שלו. לאחר שהסוכן השלים את הצעדים האלה, הוא מודיע לרשות האישורים שהוא מוכן להשלים את התיקוף.
@@ -36,7 +37,8 @@ Let's Encrypt מזהה את מנהל השרת באמצעות מפתח צי
אם החתימה על האסימון המוצפן תקפה והאתגרים הושלמו אז הסוכן שמזוהה באמצעות המפתח הציבורי מורשה לנהל אישורים עבור `example.com`. אנו קוראים לצמד המפתחות בהם משתמש הסוכן „צמד מפתחות מורשה” עבור `example.com`.
@@ -52,14 +54,16 @@ Let's Encrypt מזהה את מנהל השרת באמצעות מפתח צי
השלילה עובדת באופן דומה. הסוכן חותם על בקשת שלילה עם צמד המפתחות שמורשים עבור `example.com`, ורשות האישורים Let's Encrypt מוודאה שהבקשה מורשית. אם תהליך זה צלח, פרטי השלילה מפורסמים לערוצי השלילה הרגילים (למשל: OCSP), כדי שהגופים הנסמכים כגון דפדפנים יוכלו לדעת שאין עליהם לסמוך על אישורים שנשללו.
diff --git a/content/he/trademarks.md b/content/he/trademarks.md
index 597f06bb1a..a17926e17b 100644
--- a/content/he/trademarks.md
+++ b/content/he/trademarks.md
@@ -102,19 +102,19 @@ _הוספת קרדיט לסימן_. טקסט ההכרזה הבא אמור להו
הלוגו והטקסט שמתלווה אליו באופן רגיל. למעט מספר חריגות, זאת גרסת בררת המחדל רצוי לעבוד אתה.
-
+
EPS SVG PNG
### Let's Encrypt רחב
הגרסה הרחבה של הלוגו והטקסט שמתלווה אליו. ניתן להשתמש בזה כשהמקום האנכי מוגבל.
-
+
EPS SVG PNG
### המנעול של Let's Encrypt לבד
הלוגו שלנו לבד. ניתן להשתמש בו רק כאשר המילה „Let's Encrypt” מופיעה עם סגנון מתאים באופן מוחצן או שהוא מופיע במקום אחר בעמוד או בעיצוב. (במקרה של ספק, יש להשתמש בתצורה אחרת.)
-
-EPS SVG PNG
\ No newline at end of file
+
+EPS SVG PNG
diff --git a/content/ja/certificates.md b/content/ja/certificates.md
index cde47a9458..a551976342 100644
--- a/content/ja/certificates.md
+++ b/content/ja/certificates.md
@@ -54,7 +54,7 @@ Let's Encrypt の中間証明書は、ISRG Root X1 で署名されています
次の図は、Let's Encrypt の証明書の関係を視覚的に説明したものです。
-
+
# OCSP で署名された証明書
diff --git a/content/ja/how-it-works.md b/content/ja/how-it-works.md
index c4440de2e1..8dea96c5e4 100644
--- a/content/ja/how-it-works.md
+++ b/content/ja/how-it-works.md
@@ -25,7 +25,8 @@ Let's Encrypt はサーバーの管理者を公開鍵で特定します。
エージェント・ソフトウェアは、提示されたチャレンジのうちの1つをクリアします。今、上の例で提示された2つ目のチャレンジをエージェントがクリアできるとしましょう。このとき、エージェントは `http://example.com` のサイト上の特定のパスにファイルを1つ生成します。また、エージェントは提示されたノンスに秘密鍵を使って署名します。エージェントがこれらのステップをクリアしたら、CA に検証の準備ができたことを伝えます。
@@ -34,7 +35,8 @@ Let's Encrypt はサーバーの管理者を公開鍵で特定します。
もし、ノンスに書かれた署名が有効であり、チャレンジがクリアされたならば、公開鍵を持つエージェントは `example.com` に対する証明書の管理を行うことを認証されたことになります。私たちは、このエージェントが使用するキーペアのことを、`example.com` に対して「認証されたキーペア」と呼びます。
@@ -49,12 +51,14 @@ Let's Encrypt CA がこのリクエストを受け取ると、両方の署
無効化の作業も同じ方法で行われます。エージェントは無効化リクエストを作り、`example.com` に対して認証されたキーペアで署名をして送ります。Let's Encrypt CA はリクエストが認証されているかどうかを検証します。もし認証されていれば、証明書の無効化の情報を一般の無効化チャンネル (たとえば、OCSP) に公開します。その結果、このチャンネルを使用しているブラウザなどは、無効化された証明書を受け入れてはいけないことを知ることができます。
diff --git a/content/ko/certificates.md b/content/ko/certificates.md
index 78739f85fc..a104017cc0 100644
--- a/content/ko/certificates.md
+++ b/content/ko/certificates.md
@@ -54,7 +54,7 @@ IdenTrust는 중간 인증서에 교차 서명했습니다. 이렇게 하면 저
다음 그림은 인증서 간의 관계를 시각적으로 설명합니다.
-
+
# OCSP 서명 인증서
diff --git a/content/ko/how-it-works.md b/content/ko/how-it-works.md
index 3d98bd7b5a..bcf3409b12 100644
--- a/content/ko/how-it-works.md
+++ b/content/ko/how-it-works.md
@@ -27,7 +27,8 @@ Let’s Encrypt는 공개키로 서버 관리자를 확인합니다. 에이전
해당 에이전트 소프트웨어는 제공된 도전 중 하나를 완료합니다. 두 번째 작업을 수행할 수 있다고 가정해 보십시오: `http://example.com` 웹 사이트의 특정한 경로에 파일을 생성합니다. 에이전트는 개인 키로 제공된 임시 값에 서명합니다. 에이전트가 이 단계들을 완료하면, 에이전트는 타당성 검증을 완료할 준비가 되었음을 CA에게 통지합니다.
@@ -36,7 +37,8 @@ Let’s Encrypt는 공개키로 서버 관리자를 확인합니다. 에이전
임시 값에 대한 서명이 타당하고, 과제는 사실로 확인되면, 공개 키에 의해 확인된 에이전트는 `example.com` 인증서 관리를 하기 위해 권한이 부여됩니다. 에이전트가 `example.com`을 위해 사용했던 키의 쌍을 “권한을 부여 받은 키의 쌍”이라고 부릅니다.
@@ -51,12 +53,14 @@ Let’s Encrypt CA가 요청을 받을 때, 두 서명을 모두 검증합니다
해지는 비슷한 방식으로 작동합니다. 에이전트가 `example.com`의 인증된 한 쌍의 키로 해지 요청에 서명하고, Let’s Encrypt CA가 그 요청이 권한이 있는지 검증합니다. 권한이 있다면, 브라우저와 같은 의존적인 당사자가 해지된 인증서를 받아들이면 안 된다는 것을 알 수 있도록 일반적인 해지 채널(예: OCSP)에 해지 정보를 게시합니다.
diff --git a/content/ko/trademarks.md b/content/ko/trademarks.md
index 5426e83ef9..de6ee0bac9 100644
--- a/content/ko/trademarks.md
+++ b/content/ko/trademarks.md
@@ -102,19 +102,19 @@ ISRG 마크의 오용 여부를 [press@letsencrypt.org](mailto:press@letsencrypt
표준 로고 및 텍스트. 몇 가지 예외를 제외하고는 기본 버전입니다.
-
+
EPS SVG PNG
### Let's Encrypt 넓은 버전
우리의 로고와 텍스트의 넓은 버전. 수직 공간이 제한된 상황에서 이것을 사용하십시오.
-
+
EPS SVG PNG
### Let's Encrypt 잠금만
로고만. "Let's Encrypt" 단어 표시가 명확하게 표시되거나 페이지 또는 디자인의 다른 곳에 잘 설정된 경우에만 이 옵션을 사용하십시오. (확실하지 않으면 다른 형식을 사용하십시오.)
-
+
EPS SVG PNG
diff --git a/content/pt-br/how-it-works.md b/content/pt-br/how-it-works.md
index bf5f64c7ef..61dc4a133f 100644
--- a/content/pt-br/how-it-works.md
+++ b/content/pt-br/how-it-works.md
@@ -27,7 +27,8 @@ Juntamente com os desafios, a AC Let's Encrypt também provê um pacote de
Vamos assumir que o agente é capaz de completar a segunda tarefa: ele cria um arquivo em um caminho especificado em `http://example.com`. O agente também assina o pacote de dados providos com sua chave privada. Uma vez que ele termina estes passos, ele notifica a AC que está pronto para concluir a validação.
@@ -36,7 +37,8 @@ Agora é responsabilidade da AC verificar que os desafios foram completados. A A
Se a assinatura no pacote de dados é válida e os desafios foram corretamente completados, o agente identificado pela chave pública é autorizado a cuidar do gerenciamento de certificados de `example.com`. Nós chamamos o par de chaves usado pelo agente de "par de chavez autorizado" para `example.com.
@@ -51,13 +53,15 @@ Quando a Let's Encrypt recebe a solicitação ambas as assinaturas são val
A revogação funciona de maneira similar. O agente assina a solicitação de revogação com o par de chaves autorizado para `example.com` e a Let's Encrypt verifica se a solicitação é autorizada. Se for autorizada, a Let's Encrypt publica a informação de revogação em canais normais de revogação (como por exemplo OCSP), de maneira que terceiros que dependem de certificados (como navegadores) saibam que não devem confiar no certificado revogado.
diff --git a/content/ru/certificates.md b/content/ru/certificates.md
index fe36c7112c..ba9be3565f 100644
--- a/content/ru/certificates.md
+++ b/content/ru/certificates.md
@@ -55,7 +55,7 @@ Root X1. Чтобы определить, какой из двух сертиф
Картинка ниже иллюстрируеи взаимосвязи между перечисленными сертификатами:
-
+
# Сертификат подписания ответов OCSP
diff --git a/content/ru/how-it-works.md b/content/ru/how-it-works.md
index cded95321b..3a694678d8 100644
--- a/content/ru/how-it-works.md
+++ b/content/ru/how-it-works.md
@@ -27,7 +27,8 @@ Let's Encrypt идентифицирует web-сервер с запуще
Агент пытается выполнить серию тестов для проверки прав на домен. Допустим, успешно выполнено задание по созданию HTTP-ресурса - создан файл по определённому пути внутри `http://example.com`. Кроме того, агентом получен одноразовый пароль, который был подписан закрытым ключом и отправлен обратно в Let's Encrypt. Как только эти пункты выполнены - агент уведомляет Центр Сертификации о завершении проверки.
@@ -36,7 +37,8 @@ Let's Encrypt идентифицирует web-сервер с запуще
Если цифровая подпись верна, и все тесты пройдены - агенту выдаются права на управление сертификатами для домена `example.com`. Ключевая пара (открытый и закрытый ключи), используемая при проверке прав на домен, называется "авторизованной ключевой парой" для `example.com`.
@@ -51,12 +53,14 @@ Let's Encrypt идентифицирует web-сервер с запуще
Отзыв сертификата происходит аналогично. Агент подписывает запрос об отзыве ключевой парой, авторизованной для `example.com`. Как только ЦС Let's Encrypt подтверждает цифровые подписи запроса, он публикует информацию об отзыве сертификата, используя [OSCP](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol). Таким образом браузеры, полагаясь на данные из OSCP, не будут принимать отозванные сертификаты.
diff --git a/content/sr/certificates.md b/content/sr/certificates.md
index 1872fb9be7..7cf1952137 100644
--- a/content/sr/certificates.md
+++ b/content/sr/certificates.md
@@ -70,7 +70,7 @@ Izdavač “DST Root CA X3.” Preporučeni Let's Encrypt softver,
Sledeća slika objašnjava odnose između naših sertifikata vizuelno:
-
+
# OCSP Signing Sertifikat
@@ -95,4 +95,4 @@ dok ih izdajemo. Možete pregledati sve izdate sertifikate na sledećim linkovim
Privatni ključevi za ISRG root CA i intermedijarni podaci Let’s Encrypt čuvaju se na hardverskim sigurnosnim modulima (HSM), koji pružaju visok stepen zaštite od krađe ključeva.
-Svi ISRG ključevi trenutno su RSA ključevi. U budućnosti [planiramo generisati ECDSA ključeve](/upcoming-features).
\ No newline at end of file
+Svi ISRG ključevi trenutno su RSA ključevi. U budućnosti [planiramo generisati ECDSA ključeve](/upcoming-features).
diff --git a/content/sr/how-it-works.md b/content/sr/how-it-works.md
index 99e82a1a21..0675615a26 100644
--- a/content/sr/how-it-works.md
+++ b/content/sr/how-it-works.md
@@ -27,7 +27,8 @@ Uz dostupne načine verifikacije, Let's Encrypt sertifikaciono telo (CA) takođe
Agentski softver završava verifikaciju jednim od ponuđenih načina. Recimo da je u stanju izvršiti verifikaciju koristeći drugi naveden način iznad: kreira datoteku na određenoj putanji na web serveru `http://example.com`. Agent takodje potpisuje svoj privatni ključ. Nakon što agent izvrši ove korake, obaveštava sertifikaciono telo (CA) da je spreman za potpunu proveru.
@@ -36,7 +37,8 @@ Nakon toga, posao sertifikacionog tela (CA) jeste da proveri da li su uslovi i v
Ako je potpis dobar, a verifikacija validna, tada je agent koji je identifikovan javnim ključem ovlašćen za upravljanje sertifikatom za domen `example.com`.
@@ -52,12 +54,14 @@ Kada Let's Encrypt sertifikaciono telo (CA) primi zahtev, ono onda verifiku
Poništavanje sertifikata funkcioniše na sličan način. Agent potpisuje zahtev za poništavanje sertifikata svojim javnim ključem za domen `example.com`, gde nakon toga Let's Encrypt sertifikaciono telo (CA) verifikuje da je zahtev legitiman i odobren. Ukoliko da, onda objavljuje informaciju o poništavanju sertifikata putem standardnih kanala (primer. OCSP), tako da zavisni partneri budu obavešteni o tome kao što su web pretraživači u cilju kako bih znali da više ne prihvataju taj konkretan sertifikat kao validan.
diff --git a/content/sv/certificates.md b/content/sv/certificates.md
index 5d6d8dcb93..c3e61abbee 100644
--- a/content/sv/certificates.md
+++ b/content/sv/certificates.md
@@ -85,7 +85,7 @@ sömlöst.
Följande bild förklarar visuellt förhållandena mellan våra certifikat:
-
+
# Certifikat för OCSP-signering
diff --git a/content/sv/how-it-works.md b/content/sv/how-it-works.md
index 44095dab90..9bcc55b356 100644
--- a/content/sv/how-it-works.md
+++ b/content/sv/how-it-works.md
@@ -45,7 +45,8 @@ kontrollerar nyckelparet.
Agentmjukvaran utför en av de givna utmaningarna. Låt oss anta att den kan
@@ -60,7 +61,8 @@ filen från webbservern och säkerställa att den har det förväntade innehåll
Om engångsvärdets signatur är korrekt och utmaningarna överensstämmer är
@@ -89,7 +91,8 @@ nyckeln från CSR:en och skickar tillbaka det till agenten.
Återkallande fungerar på ett liknande sätt. Agenten signerar en begäran om
@@ -101,5 +104,6 @@ det återkallade certifikatet.
diff --git a/content/zh-cn/certificates.md b/content/zh-cn/certificates.md
index 32a92efa5e..e95e4c12bb 100644
--- a/content/zh-cn/certificates.md
+++ b/content/zh-cn/certificates.md
@@ -55,7 +55,7 @@ IdenTrust已对我们的中间证书进行了交叉签名，以提高兼容性
下图用视觉方式诠释了证书之间的关系：
-
+
# OCSP 签名证书
diff --git a/content/zh-cn/how-it-works.md b/content/zh-cn/how-it-works.md
index 945d8f3d46..86b410d27f 100644
--- a/content/zh-cn/how-it-works.md
+++ b/content/zh-cn/how-it-works.md
@@ -26,7 +26,8 @@ Let's Encrypt 通过公钥识别服务器管理员。证书管理软件首次与
证书管理软件需要完其中一项提供的验证请求。假设它能够完成上面的第二个任务：它在 `https://example.com` 站点的指定路径上创建了一个文件。证书管理软件还使用其私钥对提供的 nonce（一次性数字）进行签名。完成这些步骤后，证书管理软件会通知 CA 它已准备好完成验证。
@@ -35,7 +36,8 @@ Let's Encrypt 通过公钥识别服务器管理员。证书管理软件首次与
如果 nonce 上的签名有效，并且验证也成功完成，那么由公钥代表的证书管理软件将被授权对 `example.com` 进行证书管理。 我们将证书管理软件使用的密钥对称为 `example.com` 的“授权密钥对”。
@@ -51,12 +53,14 @@ Let's Encrypt 通过公钥识别服务器管理员。证书管理软件首次与
申请吊销证书的流程类似。证书管理软件使用 `example.com` 的授权私钥签署一个吊销请求，Let's Encrypt CA 将验证该请求是否已被授权。如果已授权，则将吊销信息发布到正常的吊销通道（即 OCSP）中，以便浏览器等依赖方知道他们不应该接受这个已被吊销的证书。
diff --git a/content/zh-cn/trademarks.md b/content/zh-cn/trademarks.md
index e9af864159..36f702fae7 100644
--- a/content/zh-cn/trademarks.md
+++ b/content/zh-cn/trademarks.md
@@ -102,19 +102,19 @@ ISRG 的许多软件产品都是在开源的基础上提供的，这意味着您
我们的标准版 logo 和文字。除少数例外情况外，这是默认的、首选的版本。
-
+
EPS SVG PNG
### Let's Encrypt 加宽版
我们的 logo 和文字的加宽版本。在垂直空间有限的情况下可以使用这个版本。
-
+
EPS SVG PNG
### Let's Encrypt 无文字版本
只有我们的 logo 的无文字版本。仅当“Let's Encrypt”文字标志在页面或设计中的其他位置清晰可见或被公认时，才能使用此版本。（如有疑问，请使用其他版本。）
-
-EPS SVG PNG
\ No newline at end of file
+
+EPS SVG PNG
diff --git a/content/zh-tw/certificates.md b/content/zh-tw/certificates.md
index 4aaef1eff2..151e040915 100644
--- a/content/zh-tw/certificates.md
+++ b/content/zh-tw/certificates.md
@@ -56,7 +56,7 @@ IdenTrust 和我們交互簽名 (Cross-Sign) 了中間憑證，這樣可以確
下圖表示憑證之間的關係：
-
+
# OCSP 憑證
diff --git a/content/zh-tw/how-it-works.md b/content/zh-tw/how-it-works.md
index cebd315355..a8444f00ac 100644
--- a/content/zh-tw/how-it-works.md
+++ b/content/zh-tw/how-it-works.md
@@ -26,7 +26,8 @@ Let's Encrypt 透過公鑰辨識伺服器。當憑證管理軟體首次向 Let's
讓我們假設，憑證管理軟體想要完成上文所提到的第二個任務。憑證管理軟體會建立一個文件並放在 `http://example.com` 網站上指定的位置，並使用私鑰對隨機數進行簽名。動作完成後，它會告知 CA 它已經準備好以進行驗證了。
@@ -35,7 +36,8 @@ Let's Encrypt 透過公鑰辨識伺服器。當憑證管理軟體首次向 Let's
如果對隨機數的簽名驗證通過，則這個考驗就算完成。這表示以公鑰作為識別的憑證管理軟體，有權管理 `example.com`。通常我們稱這個，由憑證管理軟體所使用，用來進行驗證的公私金鑰對為“授權金鑰對”。
@@ -51,12 +53,14 @@ Let's Encrypt 透過公鑰辨識伺服器。當憑證管理軟體首次向 Let's
註銷憑證的流程與申請流程類似。憑證管理軟體使用 `example.com` 的授權金鑰對替註銷請求簽名，接著 Let's Encrypt 會驗證該請求，如果請求通過驗證，它會將註銷訊息發佈到 OCSP (Online Certificate Status Protocol) 伺服器，以便讓瀏覽器等有關程式知道，他們不該信任已被註銷的憑證。
diff --git a/layouts/index.html b/layouts/index.html
index 4cb7a7f413..25e9b4f6c2 100644
--- a/layouts/index.html
+++ b/layouts/index.html
@@ -51,13 +51,13 @@
diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html
index 8289f325d2..53092d48a4 100644
--- a/layouts/partials/footer.html
+++ b/layouts/partials/footer.html
@@ -48,7 +48,7 @@ {{ i18n "footer_support_us" }}
-
+
{{ i18n "platinum" }}
{{ range $.Site.Data.sponsors.platinum }}
-
+
{{ end }}
{{ i18n "platinum" }}
{{ i18n "gold" }}
{{ range $.Site.Data.sponsors.gold }}
-
+
{{ end }}
{{ i18n "gold" }}
{{ i18n "silver" }}
{{ range $.Site.Data.sponsors.silver }}
-
+
{{ end }}
+ src="/images/howitworks_challenge.png"
+ loading="lazy"/>
+ src="/images/howitworks_authorization.png"
+ loading="lazy"/>
+ src="/images/howitworks_certificate.png"
+ loading="lazy"/>
+ src="/images/howitworks_revocation.png"
+ loading="lazy"/>
+ 
+ 
