diff --git a/.github/workflows/test.yaml b/.github/workflows/test.yaml index 64b39712e4..98732f737e 100644 --- a/.github/workflows/test.yaml +++ b/.github/workflows/test.yaml @@ -35,4 +35,3 @@ jobs: - run: npm install - run: npm run build - run: npm test - - run: html5validator --root public --blacklist documents a-warm-welcome-to-asn1-and-der donate --also-check-css --format text diff --git a/content/de/how-it-works.md b/content/de/how-it-works.md index 1d9201212c..d99ecc2218 100644 --- a/content/de/how-it-works.md +++ b/content/de/how-it-works.md @@ -25,19 +25,13 @@ Um den Prozess zu starten, fragt der Agent die Let's Encrypt-Zertifizierungsstel Neben den Herausforderungen bietet die Let's Encrypt-Zertifizierungsstelle auch eine Nonce, die der Agent mit seinem privaten Schlüsselpaar signieren muss, um zu beweisen, dass er das Schlüsselpaar kontrolliert. -
-Aufforderung zur Validierung von example.com stellen -
+![Aufforderung zur Validierung von example.com stellen](/images/howitworks_challenge.png) 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 außerdem mit seinem privaten Schlüssel. Nachdem der Agent diese Schritte ausgeführt hat, benachrichtigt er die Zertifizierungsstelle, dass sie zur Validierung bereit ist. Dann ist es die Aufgabe der Zertifizierungsstelle, zu überprüfen, ob die Aufforderungen erfüllt sind. Die Zertifizierungsstelle überprüft die Signatur auf der Nonce und versucht, die Datei vom Webserver herunterzuladen und sicherzustellen, dass sie den erwarteten Inhalt hat. -
-Erfordert Autorisierung um für example.com zu agieren -
+![Erfordert Autorisierung um für example.com zu agieren](/images/howitworks_authorization.png) 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. @@ -50,17 +44,8 @@ Um ein Zertifikat für die Domain zu erhalten, erstellt der Agent eine PKCS#10-A Wenn die Let's Encrypt-Zertifizierungsstelle die Anforderung erhält, werden beide Signaturen überprüft. Wenn alles gut aussieht, wird ein Zertifikat für `example.com` mit dem öffentlichen Schlüssel aus dem CSR ausgestellt und an den Agenten zurückgegeben. -
-Anfordern eines Zertifikats für example.com -
+![Anfordern eines Zertifikats für example.com](/images/howitworks_certificate.png) 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. -
-Anfrage zum Widerruf eines Zertifikats für example.com -
- - - +![Anfrage zum Widerruf eines Zertifikats für example.com](/images/howitworks_revocation.png) diff --git a/content/en/how-it-works.md b/content/en/how-it-works.md index 5d5bcd1287..4127d2babc 100644 --- a/content/en/how-it-works.md +++ b/content/en/how-it-works.md @@ -25,19 +25,13 @@ To kick off the process, the agent asks the Let's Encrypt CA what it needs to do Along with the challenges, the Let's Encrypt CA also provides a nonce that the agent must sign with its private key pair to prove that it controls the key pair. -
-Requesting challenges to validate example.com -
+![Requesting challenges to validate example.com](/images/howitworks_challenge.png) 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. Then, it's the CA's job to check that the challenges have been satisfied. The CA verifies the signature on the nonce, and it attempts to download the file from the web server and make sure it has the expected content. -
-Requesting authorization to act for example.com -
+![Requesting authorization to act for example.com](/images/howitworks_authorization.png) 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`. @@ -50,15 +44,8 @@ To obtain a certificate for the domain, the agent constructs a PKCS#10 [Certific When the Let's Encrypt CA receives the request, it verifies both signatures. If everything looks good, it issues a certificate for `example.com` with the public key from the CSR and returns it to the agent. -
-Requesting a certificate for example.com -
+![Requesting a certificate for example.com](/images/howitworks_certificate.png) 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. -
-Requesting revocation of a certificate for example.com -
- +![Requesting a revocation for example.com](/images/howitworks_revocation.png) 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..7daf021163 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. -

Issuance as of April 10, 2016

+![Issuance as of April 10, 2016](/images/Issuance-April-10-2016.png) 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..ee2103c1ac 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. -

Issuance as of June 22, 2016

+![Issuance as of June 22, 2016](/images/le-certs-issued-june-22-2016.png) 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..fa90c0d5a9 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

+![Chain of trust between Firefox and Let's Encrypt certificates.](/images/le-firefox-chain-of-trust.png "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..e577ba3751 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/). -

Let's Encrypt certificate issuance statistics.

+![Let's Encrypt certificate issuance statistics.](/images/Jan-6-2017-Cert-Stats.png) 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..1332546271 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: -

Percentage of HTTPS Page Loads in Firefox.

+![Percentage of HTTPS Page Loads in Firefox.](/images/2017.06.28-https-percentage.png) 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/post/2020-12-21-extending-android-compatibility.md b/content/en/post/2020-12-21-extending-android-compatibility.md index 8acc067bc0..80f20b7e3b 100644 --- a/content/en/post/2020-12-21-extending-android-compatibility.md +++ b/content/en/post/2020-12-21-extending-android-compatibility.md @@ -20,7 +20,7 @@ As such, we will be able to provide subscribers with a chain which contains both We will not be performing our previously-planned chain switch on January 11th, 2021. Instead, we will be switching to provide this new chain by default in late January or early February. The transition should have no impact on Let’s Encrypt subscribers, much like our switch to our R3 intermediate earlier this month. -

Let's Encrypt Issuance Chains

+![Let's Encrypt Issuance Chains](/images/2020.12.21-android-compat-cert-chain.png) Some additional technical details follow. 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 dadb49edb3..6288c171e3 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 @@ -46,10 +46,7 @@ The previous generation of database hardware was powerful but it was regularly b -
-Dell PowerEdge R7525 Chassis -
Dell PowerEdge R7525 internals. The two silver rectangles in the middle are the CPUs. The RAM sticks, each 64GB, are above and below the CPUs. The 24x NVMe drives are in the front of the server, on the far left.
-
+![Dell PowerEdge R7525 Chassis](/images/2021.01.21-next-gen-db-chassis.jpg "Dell PowerEdge R7525 internals. The two silver rectangles in the middle are the CPUs. The RAM sticks, each 64GB, are above and below the CPUs. The 24x NVMe drives are in the front of the server, on the far left.") By going with AMD EPYC, we were able to get 64 physical CPU cores while keeping clock speeds high: 2.9GHz base with 3.4GHz boost. More importantly, EPYC provides 128 PCIe v4.0 lanes, which allows us to put 24 NVMe drives in a single machine. NVMe is incredibly fast (\~5.7x faster than the SATA SSDs in our previous-gen database servers) because it uses PCIe instead of SATA. However, PCIe lanes are typically very limited: modern consumer chips typically have only 16 lanes, and Intel’s Xeon chips have 48. By providing 128 PCI lanes per chip (v4.0, no less), AMD EPYC has made it possible to pack large numbers of NVMe drives into a single machine. We’ll talk more about NVMe later. @@ -57,23 +54,23 @@ By going with AMD EPYC, we were able to get 64 physical CPU cores while keeping We’ll start by looking at our median time to process a request because it best reflects subscribers’ experience. Before the upgrade, we turned around the median API request in \~90 ms. The upgrade decimated that metric to \~9 ms! -

API Latency

+![API Latency](/images/2021.01.21-next-gen-db-api-latency.png) We can clearly see how our old CPUs were reaching their limit. In the week before we upgraded our primary database server, its CPU usage (from /proc/stat) averaged over 90%: -

CPU Usage Before Upgrade

+![CPU Usage Before Upgrade](/images/2021.01.21-next-gen-db-cpu-before.png) The new AMD EPYC CPUs sit at about 25%. You can see in this graph where we promoted the new database server from replica (read-only) to primary (read/write) on September 15. -

CPU Usage After Upgrade

+![CPU Usage After Upgrade](/images/2021.01.21-next-gen-db-cpu-after.png) The upgrade greatly reduced our overall database latency. The average query response time (from INFORMATION_SCHEMA) used to be \~0.45ms. -

Database Latency Before Upgrade

+![Database Latency Before Upgrade](/images/2021.01.21-next-gen-db-db-latency-before.png) Queries now average *three times faster*, about 0.15ms. -

Database Latency After Upgrade

+![Database Latency After Upgrade](/images/2021.01.21-next-gen-db-db-latency-after.png) ## OpenZFS and NVMe 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 5c99156156..a61bcf5732 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 @@ -11,7 +11,7 @@ OVHcloud, the largest hosting provider in Europe, has used Let’s Encrypt for T 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. -

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

+![Schematic of how OVHcloud automatically and simply gets Let's Encrypt certificates](/images/2021.10.28-OVHcloud-schematic.png) Getting a TLS certificate is on the critical path to onboarding a shared hosting client, so monitoring is a big part of OVHcloud’s success with Let’s Encrypt. They set up monitoring at every step in the delivery process: requesting the certificate, asking for challenges, waiting for validation, and requesting certificate creation. They also keep an eye on how long it takes to get a certificate (“it’s really fast”). OVHcloud also monitors our [status page](https://letsencrypt.status.io/) to stay apprised of our operational status. diff --git a/content/es/how-it-works.md b/content/es/how-it-works.md index 56d3d621e8..79e857cd05 100644 --- a/content/es/how-it-works.md +++ b/content/es/how-it-works.md @@ -25,19 +25,13 @@ Para iniciar el proceso, el agente le pregunta al Let's Encrypt CA lo que h Junto con los retos, el Let's Encrypt CA también provee un `nonce` que el agente debe firmar con su par de llave privada para demostrar que controla el par de llaves. -
-Solicitando retos para validar example.com -
+![Solicitando retos para validar example.com](/images/howitworks_challenge.png) El software de agente completa uno de los conjuntos de retos provistos. 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` provisto con su llave privada. Una vez el agente ha completado estos pasos, notifica la AC que está listo para completar la validación. Luego, es el trabajo de la AC verificar los que retos han sido satisfechos. La AC verifica la firma en el `nonce`, e intenta descargar un archivo del servidor web y hacerce seguro que recibió el contenido esperado. -
-Solicitando autorización para actuar por example.com -
+![Solicitando autorización para actuar por example.com](/images/howitworks_authorization.png) 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`. @@ -50,15 +44,9 @@ Para obtener un certificado para un dominio, el agente construye un PKCS#10 [Cer Cuando el Let's Encrypt CA recibe una solicitud, verifica ambas firmas. Si todo se ve bien, emite un certificado para `example.com` con la llave pública del CSR y lo devuelve al agente. -
-Solicitando un certificado para example.com -
+![Solicitando un certificado para example.com](/images/howitworks_certificate.png) La revocación funciona de una manera similar. El agente 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 revocado. -
-Solicitando revocación del certifiado para example.com -
+![Solicitando revocación del certifiado para example.com](/images/howitworks_revocation.png) diff --git a/content/fr/how-it-works.md b/content/fr/how-it-works.md index def63f2c84..534e0f746f 100644 --- a/content/fr/how-it-works.md +++ b/content/fr/how-it-works.md @@ -25,19 +25,13 @@ Pour lancer le processus, l'agent demande à l'AC Let's Encrypt ce qu'il doit fa En plus des défis, l'AC Let's Encrypt fournit également un nonce ("Number used ONCE ") que l'agent doit signer avec sa clef privée pour prouver qu'il contrôle la paire de clef. -
-Demander des défis pour valider example.com -
+![Demander des défis pour valider example.com](/images/howitworks_challenge.png) 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. Ensuite, le travail de l'AC consiste à vérifier que les défis ont été relevés. L'autorité de certification vérifie la signature sur le nonce et tente de télécharger le fichier sur le serveur Web et contrôler qu'il contient le contenu attendu. -
-Demander l'autorisation d'agir pour example.com -
+![Demander l'autorisation d'agir pour example.com](/images/howitworks_authorization.png) 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`. @@ -49,14 +43,8 @@ Pour obtenir un certificat pour le domaine, l'agent construit une PKCS#10 [Certi Lorsque l'AC Let's Encrypt reçoit la demande, elle vérifie les deux signatures. Si tout semble correct, elle délivre un certificat pour `example.com` avec la clef publique du CSR et le renvoie à l'agent. -
-Demander un certificat pour example.com -
+![Demander un certificat pour example.com](/images/howitworks_certificate.png) 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é. -
-Demander la révocation d'un certificat de example.com -
+![Demander la révocation d'un certificat de example.com](/images/howitworks_revocation.png) diff --git a/content/he/how-it-works.md b/content/he/how-it-works.md index cc15e8f991..85002932c7 100644 --- a/content/he/how-it-works.md +++ b/content/he/how-it-works.md @@ -25,19 +25,13 @@ Let's Encrypt מזהה את מנהל השרת באמצעות מפתח צי בנוסף לאתגרים, רשות האישורים Let's Encrypt מספקת אסימון מוצפן שעל הסוכן לחתום עליו עם המפתח הפרטי שלו כדי להוכיח שיש לו שליטה על צמד המפתחות. -
-בקשת אתגרים לתיקוף example.com -
+![בקשת אתגרים לתיקוף example.com](/images/howitworks_challenge.png) תכנית הסוכן משלימה את אחת מסדרות האתגרים שסופקו. נניח שהוא מצליח להשלים את המשימה השנייה שלעיל: הסוכן יוצר קובץ תחת נתיב מסוים באתר `http://example.com`. הסוכן גם חותם על האסימון המוצפן עם המפתח הפרטי שלו. לאחר שהסוכן השלים את הצעדים האלה, הוא מודיע לרשות האישורים שהוא מוכן להשלים את התיקוף. מכאן, זה תפקידה של רשות האישורים לבדוק שהאתגרים נענו כראוי. רשות האישורים מאמתת את החתימות על האסימון המוצפון ומנסה להוריד את הקובץ מהשרת ולוודא שיש בו את התוכן שאמור להיות בו. -
-בקשת הרשאה כדי לפעול עבור example.com -
+![בקשת הרשאה כדי לפעול עבור example.com](/images/howitworks_authorization.png) אם החתימה על האסימון המוצפן תקפה והאתגרים הושלמו אז הסוכן שמזוהה באמצעות המפתח הציבורי מורשה לנהל אישורים עבור `example.com`. אנו קוראים לצמד המפתחות בהם משתמש הסוכן „צמד מפתחות מורשה” עבור `example.com`. @@ -50,17 +44,11 @@ Let's Encrypt מזהה את מנהל השרת באמצעות מפתח צי כאשר רשות האישורים Let's Encrypt מקבלת את האישור, היא מאמתת את שתי החתימות. אם הכול נראה טוב, היא מנפיקה אישור עבור `example.com` עם המפתח הציבורי מתוך בקשת חתימת האישור (CSR) ומחזירה אותו אל הסוכן. -
-בקשת אישור עבור example.com -
+![בקשת אישור עבור example.com](/images/howitworks_certificate.png) השלילה עובדת באופן דומה. הסוכן חותם על בקשת שלילה עם צמד המפתחות שמורשים עבור `example.com`, ורשות האישורים Let's Encrypt מוודאה שהבקשה מורשית. אם תהליך זה צלח, פרטי השלילה מפורסמים לערוצי השלילה הרגילים (למשל: OCSP), כדי שהגופים הנסמכים כגון דפדפנים יוכלו לדעת שאין עליהם לסמוך על אישורים שנשללו. -
-בקשת שלילת אישור עבור example.com -
+![בקשת שלילת אישור עבור example.com](/images/howitworks_revocation.png) diff --git a/content/ja/how-it-works.md b/content/ja/how-it-works.md index 4a30d28e92..2be5ac0b44 100644 --- a/content/ja/how-it-works.md +++ b/content/ja/how-it-works.md @@ -23,19 +23,13 @@ Let's Encrypt はサーバーの管理者を公開鍵で特定します。 チャレンジの間に、Let's Encrypt CA はエージェントに対してノンスを与えます。エージェントは秘密鍵を使ってこのノンスに署名する必要があります。これにより、エージェントがキーペアをコントロールしていることも証明します。 -
-example.com を検証するためのチャレンジのリクエスト -
+![example.com を検証するためのチャレンジのリクエスト](/images/howitworks_challenge.png) エージェント・ソフトウェアは、提示されたチャレンジのうちの1つをクリアします。今、上の例で提示された2つ目のチャレンジをエージェントがクリアできるとしましょう。このとき、エージェントは `http://example.com` のサイト上の特定のパスにファイルを1つ生成します。また、エージェントは提示されたノンスに秘密鍵を使って署名します。エージェントがこれらのステップをクリアしたら、CA に検証の準備ができたことを伝えます。 すると、CA は、チャレンジが正しく行われたかをチェックします。CA はノンスの署名が正しいことを検証し、ウェブサーバーからファイルをダウンロードし、その中に期待どおりのコンテンツが含まれているかどうかを確認します。 -
-example.com の代表として振る舞うための認証リクエスト -
+![example.com の代表として振る舞うための認証リクエスト](/images/howitworks_authorization.png) もし、ノンスに書かれた署名が有効であり、チャレンジがクリアされたならば、公開鍵を持つエージェントは `example.com` に対する証明書の管理を行うことを認証されたことになります。私たちは、このエージェントが使用するキーペアのことを、`example.com` に対して「認証されたキーペア」と呼びます。 @@ -47,14 +41,8 @@ Let's Encrypt はサーバーの管理者を公開鍵で特定します。 Let's Encrypt CA がこのリクエストを受け取ると、両方の署名を検証します。すべてが問題なければ、`example.com` の証明書を発行し、CSR に同梱されていた公開鍵で暗号化してエージェントへ送り返します。 -
-example.com に対する証明書のリクエスト -
+![example.com に対する証明書のリクエスト](/images/howitworks_certificate.png) 無効化の作業も同じ方法で行われます。エージェントは無効化リクエストを作り、`example.com` に対して認証されたキーペアで署名をして送ります。Let's Encrypt CA はリクエストが認証されているかどうかを検証します。もし認証されていれば、証明書の無効化の情報を一般の無効化チャンネル (たとえば、OCSP) に公開します。その結果、このチャンネルを使用しているブラウザなどは、無効化された証明書を受け入れてはいけないことを知ることができます。 -
-example.com に対する証明書の無効化リクエスト -
+![example.com に対する証明書の無効化リクエスト](/images/howitworks_revocation.png) diff --git a/content/ko/how-it-works.md b/content/ko/how-it-works.md index ffc451538a..7331cfa958 100644 --- a/content/ko/how-it-works.md +++ b/content/ko/how-it-works.md @@ -25,19 +25,13 @@ Let’s Encrypt는 공개키로 서버 관리자를 확인합니다. 에이전 이 과제와 더불어, Let’s Encrypt CA는 또한 한 쌍의 키를 통제하는 것을 증명하기 위해 한 쌍의 개인 키로 서명해야 하는 임시 값을 제공합니다. -
-example.com을 검증하기 위해 과제를 요구한다 -
+![example.com을 검증하기 위해 과제를 요구한다](/images/howitworks_challenge.png) 해당 에이전트 소프트웨어는 제공된 도전 중 하나를 완료합니다. 두 번째 작업을 수행할 수 있다고 가정해 보십시오: `http://example.com` 웹 사이트의 특정한 경로에 파일을 생성합니다. 에이전트는 개인 키로 제공된 임시 값에 서명합니다. 에이전트가 이 단계들을 완료하면, 에이전트는 타당성 검증을 완료할 준비가 되었음을 CA에게 통지합니다. 그 후, 과제가 충족되었는지 검사하는 것이 CA의 일입니다. CA는 임시 값에서 서명을 검증하고, 웹 서버에서 파일을 내려 받으려고 시도하며, 예상된 내용이 있는지 확인합니다. -
-example.com을 활동 허가를 요청하기 -
+![example.com을 활동 허가를 요청하기](/images/howitworks_authorization.png) 임시 값에 대한 서명이 타당하고, 과제는 사실로 확인되면, 공개 키에 의해 확인된 에이전트는 `example.com` 인증서 관리를 하기 위해 권한이 부여됩니다. 에이전트가 `example.com`을 위해 사용했던 키의 쌍을 “권한을 부여 받은 키의 쌍”이라고 부릅니다. @@ -49,14 +43,8 @@ Let’s Encrypt는 공개키로 서버 관리자를 확인합니다. 에이전 Let’s Encrypt CA가 요청을 받을 때, 두 서명을 모두 검증합니다. 모든 것이 좋아 보인다면, CSR로부터의 공개키로 `example.com`의 증명서를 발행해 에이전트에 돌려줍니다. -
-example.com 자격증 요청 -
+![example.com 자격증 요청](/images/howitworks_certificate.png) 해지는 비슷한 방식으로 작동합니다. 에이전트가 `example.com`의 인증된 한 쌍의 키로 해지 요청에 서명하고, Let’s Encrypt CA가 그 요청이 권한이 있는지 검증합니다. 권한이 있다면, 브라우저와 같은 의존적인 당사자가 해지된 인증서를 받아들이면 안 된다는 것을 알 수 있도록 일반적인 해지 채널(예: OCSP)에 해지 정보를 게시합니다. -
-example.com에 대한 인증서 해지 요청 -
+![example.com에 대한 인증서 해지 요청](/images/howitworks_revocation.png) diff --git a/content/pt-br/how-it-works.md b/content/pt-br/how-it-works.md index 56abdec8d9..d47d6da20e 100644 --- a/content/pt-br/how-it-works.md +++ b/content/pt-br/how-it-works.md @@ -25,19 +25,13 @@ Para iniciar o processo o agente pergunta à AC Let's Encrypt o que ele pre Juntamente com os desafios, a AC Let's Encrypt também provê um pacote de dados que o agente precisa assinar com sua chave privada para provar que ele controla o par de chaves. -
-Requesting challenges to validate example.com -
+![Requesting challenges to validate example.com](/images/howitworks_challenge.png) 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. Agora é responsabilidade da AC verificar que os desafios foram completados. A AC verifica a assinatura no pacote de dados e tenta fazer o download do arquivo especificado no servidor web e se certifica de que ele possui o conteúdo esperado. -
-Requesting authorization to act for example.com -
+![Requesting authorization to act for example.com](/images/howitworks_authorization.png) 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. @@ -49,15 +43,9 @@ Para obter um certificado para o domínio, o agente constroi um PKCS#10 [Solicit Quando a Let's Encrypt recebe a solicitação ambas as assinaturas são validadas. Se tudo estiver certo, ele emite um certificado para `example.com` com a chave pública da SAC e o devolve ao agente. -
-Requesting a certificate for example.com -
+![Requesting a certificate for example.com](/images/howitworks_certificate.png) 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. -
-Requesting revocation of a certificate for example.com -
+![Requesting revocation of a certificate for example.com](/images/howitworks_revocation.png) diff --git a/content/ru/how-it-works.md b/content/ru/how-it-works.md index 8e1ef3fdbe..d4caa3a81d 100644 --- a/content/ru/how-it-works.md +++ b/content/ru/how-it-works.md @@ -25,19 +25,13 @@ Let's Encrypt идентифицирует web-сервер с запуще Одновременно с тестированием прав администратора на домен, Let's Encrypt проверяет права агента на открытый и закрытый ключи. Let's Encrypt отправляет агенту одноразовый пароль, который агент должен подписать закрытым ключом и отослать обратно. -
-Requesting challenges to validate example.com -
+![Requesting challenges to validate example.com](/images/howitworks_challenge.png) Агент пытается выполнить серию тестов для проверки прав на домен. Допустим, успешно выполнено задание по созданию HTTP-ресурса - создан файл по определённому пути внутри `http://example.com`. Кроме того, агентом получен одноразовый пароль, который был подписан закрытым ключом и отправлен обратно в Let's Encrypt. Как только эти пункты выполнены - агент уведомляет Центр Сертификации о завершении проверки. Далее, Центр Сертификации проверяет, всё ли было сделано верно: корректную цифровую подпись на одноразовом пароле, возможность скачать созданный файл по URI, а также его содержимое. -
-Requesting authorization to act for example.com -
+![Requesting authorization to act for example.com](/images/howitworks_authorization.png) Если цифровая подпись верна, и все тесты пройдены - агенту выдаются права на управление сертификатами для домена `example.com`. Ключевая пара (открытый и закрытый ключи), используемая при проверке прав на домен, называется "авторизованной ключевой парой" для `example.com`. @@ -49,14 +43,8 @@ Let's Encrypt идентифицирует web-сервер с запуще При получении CSR, ЦС Let's Encrypt проверяет подписи ключевой пары. Если всё в порядке, Центр Сертификации выпускает сертификат для `example.com` с открытым ключом из CSR, и отправляет его агенту. -
-Requesting a certificate for example.com -
+![Requesting a certificate for example.com](/images/howitworks_certificate.png) Отзыв сертификата происходит аналогично. Агент подписывает запрос об отзыве ключевой парой, авторизованной для `example.com`. Как только ЦС Let's Encrypt подтверждает цифровые подписи запроса, он публикует информацию об отзыве сертификата, используя [OSCP](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol). Таким образом браузеры, полагаясь на данные из OSCP, не будут принимать отозванные сертификаты. -
-Requesting revocation of a certificate for example.com -
+![Requesting revocation of a certificate for example.com](/images/howitworks_revocation.png) diff --git a/content/sr/how-it-works.md b/content/sr/how-it-works.md index b5a168ddf0..934485fa82 100644 --- a/content/sr/how-it-works.md +++ b/content/sr/how-it-works.md @@ -25,19 +25,13 @@ Kako bih otpočeo sam proces, agent pita Let's Encrypt sertifikaciono telo (CA) Uz dostupne načine verifikacije, Let's Encrypt sertifikaciono telo (CA) takođe daje naznaku da agent mora potpisati sa svojim privatnim parom ključeva kako bi dokazao da kontroliše par javnih ključeva. -
-Requesting challenges to validate example.com -
+![Requesting challenges to validate example.com](/images/howitworks_challenge.png) 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. Nakon toga, posao sertifikacionog tela (CA) jeste da proveri da li su uslovi i verifikacija zadovoljena. Sertifikaciono telo (CA) proverava potpis bez prijave i pokušava da preuzme prethodno kreiranu datoteku s web servera i uveriti se da ima očekivani sadržaj. -
-Requesting authorization to act for example.com -
+![Requesting authorization to act for example.com](/images/howitworks_authorization.png) 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`. @@ -50,14 +44,8 @@ Kako bi dobili sertifikat za domen, agent pravi PKCS#10 [Certificate Signing Req Kada Let's Encrypt sertifikaciono telo (CA) primi zahtev, ono onda verifikuje oba potpisa. Ukoliko sve deluje u redu, sertifikaciono telo izdaje sertifikat za `example.com` zajedno sa javnim ključem (public key) od CSR-a i dostavlja sertifikat agentu. -
-Requesting a certificate for example.com -
+![Requesting a certificate for example.com](/images/howitworks_certificate.png) 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. -
-Requesting revocation of a certificate for example.com -
+![Requesting revocation of a certificate for example.com](/images/howitworks_revocation.png) diff --git a/content/sv/how-it-works.md b/content/sv/how-it-works.md index ae898d83f3..3f898b9c79 100644 --- a/content/sv/how-it-works.md +++ b/content/sv/how-it-works.md @@ -43,10 +43,7 @@ Tillsammans med utmaningen tillhandahåller Let's Encrypt-CA:n ett engångsvärd som agenten måste signera med sin privata nyckel för att bevisa att den kontrollerar nyckelparet. -
-Begäran om utmaningar för att validera example.com -
+![Begäran om utmaningar för att validera example.com](/images/howitworks_challenge.png) Agentmjukvaran utför en av de givna utmaningarna. Låt oss anta att den kan genomföra den andra uppgiften ovan: den skapar en fil på en efterfrågad sökväg @@ -58,10 +55,7 @@ Sen är det CA:ns jobb att kontrollera att utmaningarna har blivit tillfredsställda. CA:n verifierar engångsvärdets signatur och försöker ladda ner filen från webbservern och säkerställa att den har det förväntade innehållet. -
-Begäran av behörighet att agera för example.com -
+![Begäran av behörighet att agera för example.com](/images/howitworks_authorization.png) Om engångsvärdets signatur är korrekt och utmaningarna överensstämmer är agenten, som är identifierad med den publika nyckeln, godkänd att utföra @@ -87,10 +81,7 @@ När Let's Encrypt-CA:n tar emot förfrågan verifierar den båda signature Om allt ser bra ut utfärdar den ett certifikat för `example.com` med den publika nyckeln från CSR:en och skickar tillbaka det till agenten. -
-Begäran av certifikat för example.com -
+![Begäran av certifikat för example.com](/images/howitworks_certificate.png) Återkallande fungerar på ett liknande sätt. Agenten signerar en begäran om återkallelse med det behöriga nyckelparet för `example.com` och @@ -99,7 +90,4 @@ den återkallelseinformation i de vanliga kanalerna för detta (såsom OCSP), s att de beroende parterna som webbläsare får reda på att de inte ska acceptera det återkallade certifikatet. -
-Begäran av återkallande av certifikat för example.com -
+![Begäran av återkallande av certifikat för example.com](/images/howitworks_revocation.png) diff --git a/content/uk/how-it-works.md b/content/uk/how-it-works.md index 3b679b5c8e..0761d0d552 100644 --- a/content/uk/how-it-works.md +++ b/content/uk/how-it-works.md @@ -25,19 +25,13 @@ Let's Encrypt ідентифікує адміністратора серв Поряд із перевірками, ЦС Let's Encrypt також надає одноразовий пароль, який агент має підписати своїм приватним ключем, підтверджуючи контроль над парою ключів. -
-Запит перевірок для домену example.com -
+![Запит перевірок для домену example.com](/images/howitworks_challenge.png) Програмне забезпечення агента виконує одну із запропонованих перевірок. Скажімо, він може виконати друге завдання зазначене вище, створивши файл на вказаному шляху на сайті `http://example.com`. Агент також підписує наданий одноразовий пароль своїми приватними ключами. Виконавши ці кроки, агент повідомляє ЦС про готовність до завершення перевірки. Наступне завдання ЦС – перевірити, чи перевірка пройшла успішно. ЦС звіряє правильність підпису одноразового пароля, намагаючись завантажити файл з веб-сервера та перевірити, чи містить він очікуваний вміст. -
-Запит авторизації для дій від імені example.com -
+![Запит авторизації для дій від імені example.com](/images/howitworks_authorization.png) Якщо цей підпис правильний, і усі перевірки здійснені, то агент, ідентифікований відкритим ключем, має право керувати сертифікатами для домена` example.com `. Пара ключів (відкритий і приватний), що використовувалася агентом при перевірці прав на домен, називається "авторизованою парою ключів" для `example.com`. @@ -50,17 +44,11 @@ Let's Encrypt ідентифікує адміністратора серв Після отримання запиту, ЦС Let's Encrypt перевіряє обидва підписи. Якщо все добре, ЦС видає сертифікат для `example.com` з публічним ключем з CSR і повертає його агентові. -
-Запит сертифікату для example.com -
+![Запит сертифікату для example.com](/images/howitworks_certificate.png) Процес відкликання сертифікату працює аналогічно. Агент підписує запит на відкликання за допомогою авторизованої пари ключів для `example.com` і ЦС Let's Encrypt підтверджує авторизацію запиту. Якщо автентифікація пройшла успішно, інформація про відкликання публікується у звичайні канали відкликання (тобто OCSP), щоб відповідні сторони, такі як браузери, могли знати, що вони не повинні приймати відкликаний сертифікат. -
-Запит на відкликання сертифікату для example.com -
+![Запит на відкликання сертифікату для example.com](/images/howitworks_revocation.png) diff --git a/content/zh-cn/how-it-works.md b/content/zh-cn/how-it-works.md index 3b3e337a71..2d3cab3419 100644 --- a/content/zh-cn/how-it-works.md +++ b/content/zh-cn/how-it-works.md @@ -24,19 +24,13 @@ Let's Encrypt 通过公钥识别服务器管理员。证书管理软件首次与 除了验证请求之外，Let's Encrypt CA 还会提供一个 nonce（一次性数字）要求证书管理软件使用私钥对它签名，以证明其对密钥对的控制权。 -
-请求验证 example.com 的控制权 -
+![请求验证 example.com 的控制权](/images/howitworks_challenge.png) 证书管理软件需要完成其中一项提供的验证请求。假设它能够完成上面的第二个任务：它在 `https://example.com` 站点的指定路径上创建了一个文件。证书管理软件还使用其私钥对提供的 nonce（一次性数字）进行签名。完成这些步骤后，证书管理软件会通知 CA 它已准备好完成验证。 然后，CA 的工作就是检查验证是否已经完成。CA 会验证 nonce 上的签名，并尝试从 Web 服务器下载该文件，并确保其具有 CA 需要的内容。 -
-请求代表 example.com 进行操作的授权 -
+![请求代表 example.com 进行操作的授权](/images/howitworks_authorization.png) 如果 nonce 上的签名有效，并且验证也成功完成，那么由公钥代表的证书管理软件将被授权对 `example.com` 进行证书管理。 我们将证书管理软件使用的密钥对称为 `example.com` 的“授权密钥对”。 @@ -49,14 +43,8 @@ Let's Encrypt 通过公钥识别服务器管理员。证书管理软件首次与 当 Let's Encrypt CA 收到请求时，它会验证这两个签名。如果一切正常，CA 将为 CSR 中的公钥颁发 `example.com` 的证书，并将文件发送回证书管理软件。 -
-为 example.com 申请证书 -
+![为 example.com 申请证书](/images/howitworks_certificate.png) 申请吊销证书的流程类似。证书管理软件使用 `example.com` 的授权私钥签署一个吊销请求，Let's Encrypt CA 将验证该请求是否已被授权。如果已授权，则将吊销信息发布到正常的吊销通道（即 OCSP）中，以便浏览器等依赖方知道他们不应该接受这个已被吊销的证书。 -
-申请吊销 example.com 的证书的流程 -
+![申请吊销 example.com 的证书的流程](/images/howitworks_revocation.png) diff --git a/content/zh-tw/how-it-works.md b/content/zh-tw/how-it-works.md index 4a9dad2de7..9557c9d1fa 100644 --- a/content/zh-tw/how-it-works.md +++ b/content/zh-tw/how-it-works.md @@ -24,19 +24,13 @@ Let's Encrypt 透過公鑰辨識伺服器。當憑證管理軟體首次向 Let's 此外，在驗證考驗中，Let's Encrypt 還提供了一個隨機數 (nonce)，要求憑證管理軟體必須用它所產生的私鑰，對隨機數進行簽名，以證明憑證管理軟體擁有這組金鑰對。 -
-Requesting challenges to validate example.com -
+![Requesting challenges to validate example.com](/images/howitworks_challenge.png) 讓我們假設，憑證管理軟體想要完成上文所提到的第二個任務。憑證管理軟體會建立一個文件並放在 `http://example.com` 網站上指定的位置，並使用私鑰對隨機數進行簽名。動作完成後，它會告知 CA 它已經準備好以進行驗證了。 接著 CA 要驗證伺服器是否通過這個考驗。CA 會檢查隨機數上的簽名，並且下載在放網頁伺服器上的文件，以確認文件內容。 -
-替 example.com 請求授權所需要的工作 -
+![替 example.com 請求授權所需要的工作](/images/howitworks_authorization.png) 如果對隨機數的簽名驗證通過，則這個考驗就算完成。這表示以公鑰作為識別的憑證管理軟體，有權管理 `example.com`。通常我們稱這個，由憑證管理軟體所使用，用來進行驗證的公私金鑰對為“授權金鑰對”。 @@ -49,14 +43,8 @@ Let's Encrypt 透過公鑰辨識伺服器。當憑證管理軟體首次向 Let's 當 Let's Encrypt 接收到請求後，它會驗證這兩個簽名。如果驗證成功，CA 會使用 CSR 中的公鑰替 `example.com` 的憑證簽名，再將文件回傳給憑證管理軟體。 -
-替 example.com 申請憑證 -
+![替 example.com 申請憑證](/images/howitworks_certificate.png) 註銷憑證的流程與申請流程類似。憑證管理軟體使用 `example.com` 的授權金鑰對替註銷請求簽名，接著 Let's Encrypt 會驗證該請求，如果請求通過驗證，它會將註銷訊息發佈到 OCSP (Online Certificate Status Protocol) 伺服器，以便讓瀏覽器等有關程式知道，他們不該信任已被註銷的憑證。 -
-註銷 example.com 憑證的流程 -
+![註銷 example.com 憑證的流程](/images/howitworks_revocation.png) diff --git a/layouts/_default/_markup/render-image.html b/layouts/_default/_markup/render-image.html new file mode 100644 index 0000000000..0f0e755764 --- /dev/null +++ b/layouts/_default/_markup/render-image.html @@ -0,0 +1,29 @@ +{{- if $ressource := resources.Get (substr .Destination 1) -}} + {{- if .Title -}} +

{{/* Each markdown line is in a "p" tag, and "figure" must be outside "p" */}} +
+ {{- end -}} + {{- if eq $ressource.MediaType.SubType "svg" -}} + + {{ .Text | safeHTML }} + + {{- else -}} + {{- $resize := printf "%dx%d q100 webp" $ressource.Width $ressource.Height -}} + {{- $webp := $ressource.Resize $resize -}} + {{- $webp1920x := $ressource.Resize "1920x q100 webp" -}} + {{- $webp1366x := $ressource.Resize "1366x q100 webp" -}} + {{- $webp360x := $ressource.Resize "360x q100 webp" -}} + {{ $srcset := printf "%s 360w, %s 1366w, %s 1920w, %s %dw" $webp360x.RelPermalink $webp1366x.RelPermalink $webp1920x.RelPermalink $webp.RelPermalink $webp.Width }} + + + {{ .Text | safeHTML }} + + {{- end -}} + {{- if .Title -}} +
{{ .Title }}
+
+

+ {{- end -}} +{{- else -}} + {{ errorf "Image not found: %q" .Destination }} +{{- end -}} diff --git a/layouts/_default/single.html b/layouts/_default/single.html index 9c9b0c5c26..3757c8caa1 100644 --- a/layouts/_default/single.html +++ b/layouts/_default/single.html @@ -9,7 +9,7 @@ {{- else -}} {{- partial "hero" . -}} {{- end -}} -

+
{{- partial "langs" . -}} diff --git a/layouts/post/baseof.html b/layouts/post/baseof.html index c3f29fe543..1137c9a52d 100644 --- a/layouts/post/baseof.html +++ b/layouts/post/baseof.html @@ -6,7 +6,7 @@ {{ if .IsNode }} {{ partial "hero" . }} {{ end }} -
+
{{ block "main" . }}{{ end }}
diff --git a/package.json b/package.json index 8f6029e5e2..3917bd563a 100644 --- a/package.json +++ b/package.json @@ -9,8 +9,10 @@ "scripts": { "test:htmllint": "htmlhint 'content/**/*.html'", "test:eslint": "eslint static/js --ext .js", - "test": "npm run test:htmllint && npm run test:eslint", - "build": "hugo -d public" + "test:html5validator": "html5validator --root public --blacklist documents a-warm-welcome-to-asn1-and-der donate --also-check-css --format text", + "test": "npm run test:htmllint && npm run test:eslint && npm run test:html5validator", + "build": "hugo -d public", + "clean": "rm -rf public" }, "repository": { "type": "git", diff --git a/src/css/_layout.scss b/src/css/_layout.scss index 1f96496959..29c5388154 100644 --- a/src/css/_layout.scss +++ b/src/css/_layout.scss @@ -431,18 +431,21 @@ html[dir="rtl"] .social-media-list { } } -/* - * Images in How It Works - */ -.howitworks-figure { - text-align: center; +.page-content img[width][height] { + max-width: 100%; + height: auto; } -.howitworks-figure img { - width: 600px; - padding: 10px; +.center-images img { + display: block; + margin-left: auto; + margin-right: auto; } +.center-images figcaption { + text-align: center; +} + .well { background-color: rgba(234,234,234,0.7); border: 1px solid rgba(234,234,234,0.85); diff --git a/src/images/2017.06.28-https-percentage.png b/src/images/2017.06.28-https-percentage.png new file mode 100644 index 0000000000..a5a9f12a78 Binary files /dev/null and b/src/images/2017.06.28-https-percentage.png differ diff --git a/src/images/2019-11-20-ct-architecture.png b/src/images/2019-11-20-ct-architecture.png new file mode 100644 index 0000000000..fb2d90dd9f Binary files /dev/null and b/src/images/2019-11-20-ct-architecture.png differ diff --git a/src/images/2020-02-19-multiple-perspective-validation.png b/src/images/2020-02-19-multiple-perspective-validation.png new file mode 100644 index 0000000000..1851f5562d Binary files /dev/null and b/src/images/2020-02-19-multiple-perspective-validation.png differ diff --git a/src/images/2020-02-19-single-perspective-validation.png b/src/images/2020-02-19-single-perspective-validation.png new file mode 100644 index 0000000000..0607262236 Binary files /dev/null and b/src/images/2020-02-19-single-perspective-validation.png differ diff --git a/src/images/2020-09-17-hierarchy-post-sept-2020.png b/src/images/2020-09-17-hierarchy-post-sept-2020.png new file mode 100644 index 0000000000..427f849077 Binary files /dev/null and b/src/images/2020-09-17-hierarchy-post-sept-2020.png differ diff --git a/src/images/2020-09-17-hierarchy-pre-sept-2020.png b/src/images/2020-09-17-hierarchy-pre-sept-2020.png new file mode 100644 index 0000000000..858191dd76 Binary files /dev/null and b/src/images/2020-09-17-hierarchy-pre-sept-2020.png differ diff --git a/src/images/2020.11.06-android-version-distribution.png b/src/images/2020.11.06-android-version-distribution.png new file mode 100644 index 0000000000..f16572bb91 Binary files /dev/null and b/src/images/2020.11.06-android-version-distribution.png differ diff --git a/src/images/2020.12.21-android-compat-cert-chain.png b/src/images/2020.12.21-android-compat-cert-chain.png new file mode 100644 index 0000000000..a28080e3e0 Binary files /dev/null and b/src/images/2020.12.21-android-compat-cert-chain.png differ diff --git a/src/images/2021.01.21-next-gen-db-api-latency.png b/src/images/2021.01.21-next-gen-db-api-latency.png new file mode 100644 index 0000000000..ccc4c3088a Binary files /dev/null and b/src/images/2021.01.21-next-gen-db-api-latency.png differ diff --git a/src/images/2021.01.21-next-gen-db-chassis.jpg b/src/images/2021.01.21-next-gen-db-chassis.jpg new file mode 100644 index 0000000000..cc611bb300 Binary files /dev/null and b/src/images/2021.01.21-next-gen-db-chassis.jpg differ diff --git a/src/images/2021.01.21-next-gen-db-cpu-after.png b/src/images/2021.01.21-next-gen-db-cpu-after.png new file mode 100644 index 0000000000..5416ba06a3 Binary files /dev/null and b/src/images/2021.01.21-next-gen-db-cpu-after.png differ diff --git a/src/images/2021.01.21-next-gen-db-cpu-before.png b/src/images/2021.01.21-next-gen-db-cpu-before.png new file mode 100644 index 0000000000..c555af1696 Binary files /dev/null and b/src/images/2021.01.21-next-gen-db-cpu-before.png differ diff --git a/src/images/2021.01.21-next-gen-db-db-latency-after.png b/src/images/2021.01.21-next-gen-db-db-latency-after.png new file mode 100644 index 0000000000..0248a6d172 Binary files /dev/null and b/src/images/2021.01.21-next-gen-db-db-latency-after.png differ diff --git a/src/images/2021.01.21-next-gen-db-db-latency-before.png b/src/images/2021.01.21-next-gen-db-db-latency-before.png new file mode 100644 index 0000000000..964a65591d Binary files /dev/null and b/src/images/2021.01.21-next-gen-db-db-latency-before.png differ diff --git a/src/images/2021.10.28-OVHcloud-schematic.png b/src/images/2021.10.28-OVHcloud-schematic.png new file mode 100644 index 0000000000..9b7e174968 Binary files /dev/null and b/src/images/2021.10.28-OVHcloud-schematic.png differ diff --git a/src/images/HTTPS-Growth-Rate-April-2016.png b/src/images/HTTPS-Growth-Rate-April-2016.png new file mode 100644 index 0000000000..5c9af25ae3 Binary files /dev/null and b/src/images/HTTPS-Growth-Rate-April-2016.png differ diff --git a/src/images/HTTPS-Growth-Rate-March-2016.png b/src/images/HTTPS-Growth-Rate-March-2016.png new file mode 100644 index 0000000000..bc6c0ba85e Binary files /dev/null and b/src/images/HTTPS-Growth-Rate-March-2016.png differ diff --git a/src/images/Issuance-April-10-2016.png b/src/images/Issuance-April-10-2016.png new file mode 100644 index 0000000000..40d056951f Binary files /dev/null and b/src/images/Issuance-April-10-2016.png differ diff --git a/src/images/Jan-6-2017-Cert-Stats.png b/src/images/Jan-6-2017-Cert-Stats.png new file mode 100644 index 0000000000..d9e704c087 Binary files /dev/null and b/src/images/Jan-6-2017-Cert-Stats.png differ diff --git a/src/images/howitworks_authorization.png b/src/images/howitworks_authorization.png new file mode 100644 index 0000000000..d61ba00931 Binary files /dev/null and b/src/images/howitworks_authorization.png differ diff --git a/src/images/howitworks_certificate.png b/src/images/howitworks_certificate.png new file mode 100644 index 0000000000..471532ba08 Binary files /dev/null and b/src/images/howitworks_certificate.png differ diff --git a/src/images/howitworks_challenge.png b/src/images/howitworks_challenge.png new file mode 100644 index 0000000000..7baa996a73 Binary files /dev/null and b/src/images/howitworks_challenge.png differ diff --git a/src/images/howitworks_revocation.png b/src/images/howitworks_revocation.png new file mode 100644 index 0000000000..d9d153dba0 Binary files /dev/null and b/src/images/howitworks_revocation.png differ diff --git a/src/images/isrg-hierarchy.png b/src/images/isrg-hierarchy.png new file mode 100644 index 0000000000..967fe9da7d Binary files /dev/null and b/src/images/isrg-hierarchy.png differ diff --git a/src/images/isrg-keys-2.png b/src/images/isrg-keys-2.png new file mode 100644 index 0000000000..efb6ee94f3 Binary files /dev/null and b/src/images/isrg-keys-2.png differ diff --git a/src/images/isrg-keys.png b/src/images/isrg-keys.png new file mode 100644 index 0000000000..759f2871fa Binary files /dev/null and b/src/images/isrg-keys.png differ diff --git a/src/images/le-certs-issued-june-22-2016.png b/src/images/le-certs-issued-june-22-2016.png new file mode 100644 index 0000000000..dc5185f521 Binary files /dev/null and b/src/images/le-certs-issued-june-22-2016.png differ diff --git a/src/images/le-firefox-chain-of-trust.png b/src/images/le-firefox-chain-of-trust.png new file mode 100644 index 0000000000..f3edfee5f3 Binary files /dev/null and b/src/images/le-firefox-chain-of-trust.png differ