letsencrypt · tdelmas · Dec 4, 2021 · Dec 4, 2021 · Dec 4, 2021 · Dec 5, 2021
diff --git 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
@@ -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.
 
-<div class="howitworks-figure">
-<img alt="Aufforderung zur Validierung von example.com stellen"
-   src="/images/howitworks_challenge.png"/>
-</div>
+![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.
 
-<div class="howitworks-figure">
-<img alt="Erfordert Autorisierung um für example.com zu agieren"
-   src="/images/howitworks_authorization.png"/>
-</div>
+![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&nbsp;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.
 
-<div class="howitworks-figure">
-<img alt="Anfordern eines Zertifikats für example.com"
-   src="/images/howitworks_certificate.png"/>
-</div>
+![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&nbsp;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.
 
-<div class="howitworks-figure">
-<img alt="Anfrage zum Widerruf eines Zertifikats für example.com"
-   src="/images/howitworks_revocation.png"/>
-</div>
-
-
-
+![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
@@ -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.
 
-<div class="howitworks-figure">
-<img alt="Requesting challenges to validate example.com"
-     src="/images/howitworks_challenge.png"/>
-</div>
+![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.
 
-<div class="howitworks-figure">
-<img alt="Requesting authorization to act for example.com"
-     src="/images/howitworks_authorization.png"/>
-</div>
+![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&nbsp;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.
 
-<div class="howitworks-figure">
-<img alt="Requesting a certificate for example.com"
-     src="/images/howitworks_certificate.png"/>
-</div>
+![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&nbsp;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.
 
-<div class="howitworks-figure">
-<img alt="Requesting revocation of a certificate for example.com"
-     src="/images/howitworks_revocation.png"/>
-</div>
-
+![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
@@ -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.
 
-<p class="text-center"><img src="/images/Issuance-April-10-2016.png" alt="Issuance as of April 10, 2016" style="width: 650px; margin-bottom: 17px;"/></p>
+![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
@@ -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.
 
-<p class="text-center"><img src="/images/le-certs-issued-june-22-2016.png" alt="Issuance as of June 22, 2016" style="width: 650px; margin-bottom: 17px;"/></p>
+![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
@@ -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.
 
-<p class="text-center"><img src="/images/le-firefox-chain-of-trust.png" alt="Chain of trust between Firefox and Let's Encrypt certificates." style="width: 650px; margin-bottom: 17px;"/><br><em>Chain of Trust Between Firefox and Let's Encrypt Certificates</em></p>
+![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
@@ -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/).
 
-<p class="text-center"><img src="/images/Jan-6-2017-Cert-Stats.png" alt="Let's Encrypt certificate issuance statistics." style="width: 650px; margin-bottom: 17px;"/></p>
+![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
@@ -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:
 
-<p class="text-center"><img src="/images/2017.06.28-https-percentage.png" alt="Percentage of HTTPS Page Loads in Firefox." style="width: 650px; margin-bottom: 17px;"/></p>
+![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
@@ -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.
 
-<p class="text-center"><img src="/images/2020.12.21-android-compat-cert-chain.png" alt="Let's Encrypt Issuance Chains" width="600"></p>
+![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
@@ -46,34 +46,31 @@ The previous generation of database hardware was powerful but it was regularly b
 </table>
 </div>
 
-<figure style="display: flex; flex-direction: column; align-items: center; text-align: center">
-<img src="/images/2021.01.21-next-gen-db-chassis.jpg" width="600" alt="Dell PowerEdge R7525 Chassis">
-<figcaption>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.</figcaption>
-</figure>
+![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.
 
 ## Performance Impact
 
 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!
 
-<p class="text-center"><img src="/images/2021.01.21-next-gen-db-api-latency.png" alt="API Latency"></p>
+![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%:
 
-<p class="text-center"><img src="/images/2021.01.21-next-gen-db-cpu-before.png" alt="CPU Usage Before Upgrade"></p>
+![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.
 
-<p class="text-center"><img src="/images/2021.01.21-next-gen-db-cpu-after.png" alt="CPU Usage After Upgrade"></p>
+![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.
 
-<p class="text-center"><img src="/images/2021.01.21-next-gen-db-db-latency-before.png" alt="Database Latency Before Upgrade"></p>
+![Database Latency Before Upgrade](/images/2021.01.21-next-gen-db-db-latency-before.png)
 
 Queries now average *three times faster*, about 0.15ms.
 
-<p class="text-center"><img src="/images/2021.01.21-next-gen-db-db-latency-after.png" alt="Database Latency After Upgrade"></p>
+![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
@@ -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. 
 
-<p class="text-center"><img src="/images/2021.10.28-OVHcloud-schematic.png" alt="Schematic of how OVHcloud automatically and simply gets Let's Encrypt certificates"></p>
+![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
@@ -25,19 +25,13 @@ Para iniciar el proceso, el agente le pregunta al Let's&nbsp;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.
 
-<div class="howitworks-figure">
-<img alt="Solicitando retos para validar example.com"
-     src="/images/howitworks_challenge.png"/>
-</div>
+![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.
 
-<div class="howitworks-figure">
-<img alt="Solicitando autorización para actuar por example.com"
-     src="/images/howitworks_authorization.png"/>
-</div>
+![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.
 
-<div class="howitworks-figure">
-<img alt="Solicitando un certificado para example.com"
-     src="/images/howitworks_certificate.png"/>
-</div>
+![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.
 
-<div class="howitworks-figure">
-<img alt="Solicitando revocación del certifiado para example.com"
-     src="/images/howitworks_revocation.png"/>
-</div>
+![Solicitando revocación del certifiado para example.com](/images/howitworks_revocation.png)