letsencrypt · ludekjanda · Aug 7, 2026 · Aug 7, 2026
diff --git a/content/cs/docs/faq.md b/content/cs/docs/faq.md
@@ -117,6 +117,6 @@ Jakmile úspěšně dokončíte výzvy pro doménu, výsledná autorizace se ulo
 
 ## Kde se mohu dozvědět více o TLS/SSL a PKI obecně?
 
-Dlouholetý bezpečnostní výzkumník a odborník Ivan Ristić vydal průvodce konfigurací s užitečnými informacemi o tom, co je třeba zvážit při <a href="https://www.feistyduck.com/library/bulletproof-tls-guide/online/" target="_blank" rel="noopener noreferer">nastavování TLS</a>.
+Dlouholetý bezpečnostní výzkumník a odborník Ivan Ristić vydal průvodce konfigurací s užitečnými informacemi o tom, co je třeba zvážit při <a href="https://www.feistyduck.com/library/bulletproof-tls-guide/online/" target="_blank" rel="noopener noreferrer">nastavování TLS</a>.
 
-Pro rozsáhlejší úvod a podrobnější informace doporučujeme knihu <a href="https://www.feistyduck.com/books/bulletproof-tls-and-pki/" target="_blank" rel="noopener noreferer">Bulletproof TLS and PKI</a>, jejímž autorem je rovněž Ristić.
+Pro rozsáhlejší úvod a podrobnější informace doporučujeme knihu <a href="https://www.feistyduck.com/books/bulletproof-tls-and-pki/" target="_blank" rel="noopener noreferrer">Bulletproof TLS and PKI</a>, jejímž autorem je rovněž Ristić.
diff --git a/content/cs/docs/ipv6.md b/content/cs/docs/ipv6.md
@@ -1,7 +1,7 @@
 ---
 title: Podpora IPv6
 slug: ipv6-support
-lastmod: 2020-02-07
+lastmod: 2026-08-04
 show_lastmod: 1
 ---
 
@@ -24,7 +24,7 @@ Správným řešením je ve většině případů změnit adresu IPv6 tak, aby v
 
 Po neúspěchu přes IPv6 se požadavek zopakuje přes IPv4 pouze tehdy, když vyprší časový limit připojení. U jiných typů chyb se neopakuje.
 
-Například ve výše popsané situaci z oddílu „Časté problémy“ se požadavek nezopakuje, pokud na adrese IPv6 naslouchá webový server, který však není připraven odpovědět na výzvu ACME. Při přístupu na adresu IPv6 v takovém případě nevyprší časový limit připojení. Server vrátí nesprávnou odpověď, výzva selže a požadavek se nezopakuje.
+Například ve výše popsané situaci se požadavek nezopakuje, pokud na adrese IPv6 naslouchá webový server, který však není připraven odpovědět na výzvu ACME. Při přístupu na adresu IPv6 v takovém případě nevyprší časový limit připojení. Výzva selže bez opakování požadavku, protože server vrátil nesprávnou odpověď.
 
 Aby software naší certifikační autority zůstal jednoduchý, opakujeme z IPv6 přes IPv4 pouze první požadavek při ověřování výzvy „http-01“. Na požadavky následující po přesměrování se tento postup nevztahuje.
 

diff --git a/content/cs/docs/rate-limits.md b/content/cs/docs/rate-limits.md
@@ -1,7 +1,7 @@
 ---
 title: Limity četnosti požadavků
 slug: rate-limits
-lastmod: 2025-06-12
+lastmod: 2026-08-05
 show_lastmod: true
 ---
 
@@ -52,7 +52,7 @@ Následující limity platí, když odběratelé žádají o nový certifikát p
 ## Nové objednávky na účet
 
 Při každé žádosti o certifikát od Let's Encrypt vznikne nová objednávka.
-Jeden certifikát může obsahovat až 100 identifikátorů (názvů DNS nebo IP adres). Kvůli výkonu je lepší používat méně identifikátorů na certifikát, kdykoliv je to možné.
+Jeden certifikát může obsahovat až 100 identifikátorů (názvů DNS nebo IP adres) v závislosti na zvoleném [profilu certifikátu](/docs/profiles/). Kvůli výkonu je lepší používat méně identifikátorů na certifikát, kdykoliv je to možné.
 
 ### Limit
 
@@ -71,6 +71,8 @@ Registrovaná doména je obecně ta část domény, kterou jste zakoupili od reg
 
 Pokud žádáte o certifikát pro IP adresu, snažíme se za „registrovanou doménu“ považovat také nejběžnější přidělovaný rozsah, který obvykle získáte od poskytovatele připojení nebo hostingu. U adres IPv4 považujeme za registrovanou doménu konkrétní adresu. U adres IPv6 považujeme za registrovanou doménu rozsah /64, do kterého adresa patří.
 
+Seznam certifikátů vydaných pro vaši registrovanou doménu najdete pomocí služeb [crt.sh](https://crt.sh/) nebo [Censys](https://search.censys.io/#), které využívají veřejné logy [transparentnosti certifikátů](https://www.certificate-transparency.org/).
+
 ### Limit
 
 Až 50 certifikátů lze pro jednu registrovanou doménu (nebo adresu IPv4 či rozsah IPv6 /64) vydat každých 7 dní. Jde o globální limit, do kterého se započítávají všechny nové objednávky bez ohledu na účet, ze kterého byly odeslány.
@@ -210,8 +212,6 @@ Po uvedeném datu a čase by mělo být možné stejný požadavek úspěšně z
 
 Ve všech chybových odpovědích souvisejících s limity uvádíme hlavičku `Retry-After`, která určuje, jak dlouho má klient před dalším pokusem čekat.
 
-Seznam certifikátů vydaných pro vaši registrovanou doménu najdete pomocí služeb [crt.sh](https://crt.sh/) nebo [Censys](https://search.censys.io/#), které využívají veřejné logy [transparentnosti certifikátů](https://www.certificate-transparency.org/).
-
 # Žádost o navýšení limitu
 
 Velcí poskytovatelé hostingu a organizace, které integrují Let's Encrypt, mohou o vyšší limity požádat prostřednictvím [formuláře pro navýšení limitů](https://isrg.formstack.com/forms/rate_limit_adjustment_request). Vyřízení žádosti trvá několik týdnů. Formulář proto není vhodný, pokud potřebujete limit pouze vynulovat dříve, než se sám obnoví.
diff --git a/content/cs/docs/why-all-https.md b/content/cs/docs/why-all-https.md
@@ -1,4 +1,24 @@
 ---
+title: Proč by všechny weby měly používat HTTPS
 slug: why-all-https
-untranslated: 1
+lastmod: 2025-08-03
+show_lastmod: 1
 ---
+
+Někteří provozovatelé serverů v minulosti tvrdili, že jejich web neobsahuje nic citlivého, a ochranu soukromí proto nepotřebují. Tento argument však není přesvědčivý. Jsme přesvědčeni, že všechny weby by měly používat HTTPS, a to z následujících důvodů:
+
+## Provoz přes HTTP lze během přenosu sledovat
+
+Nešifrovaný provoz lze během přenosu sledovat. To znamená, že jakýkoli subjekt na síťové trase může vidět veškerý obsah přenášený oběma směry, včetně citlivých údajů. Jde o zjevný problém z hlediska soukromí, podobný posílání dopisů bez obálky.
+
+I když se provozovatel serveru domnívá, že jeho web neobsahuje nic citlivého, lidé se někdy mýlí. Možná by se žádné citlivé informace přenášet _neměly_, to však neznamená, že se přenášet nebudou. HTTPS pomáhá zajistit, aby chyby nevedly k narušení soukromí.
+
+Provozovatel serveru navíc nemá kontrolu nad veškerým provozem směřujícím na jeho web a z něj. Nemůže zabránit tomu, aby návštěvníci v požadavku omylem _odeslali_ citlivé informace, například prostřednictvím formuláře nebo kvůli nesprávnému nastavení klientského softwaru. Očekávat, že to návštěvníci nikdy neudělají, je zcela nereálné.
+
+Citlivou informací může být i samotná návštěva určitého webu, zejména pro lidi žijící v represivních režimech. HTTPS podporuje rozšíření [Encrypted Client Hello (ECH)](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello), které může tuto informaci skrýt. Weby používající HTTP však tuto další vrstvu ochrany využít nemohou.
+
+## Provoz přes HTTP lze během přenosu měnit
+
+Ještě horší je, že nešifrovaný provoz lze během přenosu také měnit. Nikdo si proto nemůže být jistý, že v kterémkoli směru dorazilo přesně to, co bylo odesláno. Spojení tak postrádá nejen soukromí, ale i _integritu_.
+
+Běžným příkladem je vkládání reklam nebo škodlivého softwaru do odpovědí serveru. Web, který nepoužívá HTTPS, vystavuje své návštěvníky tomuto riziku bez ohledu na svůj skutečný obsah.
diff --git a/content/da/privacy.md b/content/da/privacy.md
@@ -1,7 +1,7 @@
 ---
-title: Politik om beskyttelse af personlige oplysninger
+title: Let's Encrypt Privatlivspolitik
 slug: privacy
-lastmod: 2025-01-15
+lastmod: 2026-07-06
 english_is_canonical: 1
 show_lastmod: 1
 ---
@@ -30,7 +30,7 @@ Det kan være nødvendigt at downloade klientsoftware fra et depot såsom Debian
 
 ## Besøgende
 
-Når du som besøgende gennemser ISRG hjemmeside, har du mulighed for at lave en donation. Donationer behandles af vores betroede betalingspartnere, herunder DonorBox, Stripe, Shopify, og PayPal, afhængigt af den valgte betalingsmetode og opbevares i ISRG's Salesforce database og Sage Intacct som nødvendigt. Vi indsamler dit navn og din e-mailadresse, og hvis du angiver det, din postadresse, når du donerer. Når du donerer, vil vi bruge dine oplysninger til vores legitime interesse i at behandle og administrere dit bidrag, herunder fundraising påmindelser og fornyelser. Dine interaktioner med [DonorBox](https://donorbox.org/privacy), [Stripe](https://stripe.com/privacy/), [PayPal](https://www.paypal.com/us/webapps/mpp/ua/privacy-full), [Shopify](https://www.shopify.com/legal/privacy), [The Giving Block](https://thegivingblock.com/about/privacy-policy/), [Salesforce](https://www.salesforce.com/company/privacy/), [Printful](https://www.printful.com/policies/privacy), [Formstack](https://www.formstack.com/legal), [Sage Intacct](https://www.sageintacct.com/privacy_policy_website) er underlagt deres respektive privatlivspolitikker. Vi indsamler eller opbevarer ikke kreditkort eller bankoplysninger relateret til donationer.
+Når du som besøgende gennemser ISRG hjemmeside, har du mulighed for at lave en donation. Donationer behandles af vores betroede betalingspartnere, herunder DonorBox, The Giving Block, Stripe, Shopify og PayPal, afhængigt af den valgte betalingsmetode og opbevares i ISRG's Salesforce database og Sage Intacct som nødvendigt. Vi indsamler dit navn og din e-mailadresse, når du donerer. Afhængigt af din gave, kan vi også indsamle merchandise præferencer (såsom t-shirt størrelse) til at opfylde donor fordele. Når du donerer, vil vi bruge dine oplysninger til vores legitime interesse i at behandle og administrere dit bidrag, herunder fundraising påmindelser og fornyelser. Vi kan også bruge din mailingadresse til at identificere og konsolidere duplikerede donorposter for at bevare nøjagtigheden af vores donordatabase. Dine interaktioner med Your interactions with [DonorBox](https://donorbox.org/privacy), [Stripe](https://stripe.com/privacy/), [PayPal](https://www.paypal.com/us/webapps/mpp/ua/privacy-full), [Shopify](https://www.shopify.com/legal/privacy), [The Giving Block](https://thegivingblock.com/about/privacy-policy/), [Salesforce](https://www.salesforce.com/company/privacy/), [Monday Merch](https://www.mondaymerch.com/us/legal/privacy-policy?utm_source=google&utm_medium=cpc&utm_content=617104787162&utm_term=merch+monday&utm_campaign=16492171655&gclid=Cj0KCQjwrs7RBhDuARIsAIVfBD2DPUD-_BNhjV74wtBSJ2fKpvd10ZW6UT_JkqRkL0IRmY3G9_I6ljMaAovwEALw_wcB&gbraid=0AAAAAoJDcr6lwITSXqZ0UkPgmXyJpGp8e), [Formstack](https://www.formstack.com/legal), [BoldSign](https://boldsign.com/privacy-policy/) og [Sage Intacct](https://www.sageintacct.com/privacy_policy_website) er underlagt deres respektive privatlivspolitikker. Vi indsamler eller opbevarer ikke kreditkort eller bankoplysninger relateret til donationer.
 
 Du kan have mulighed for at give din e-mail-adresse til at modtage meddelelser i forbindelse med ISRG-projekter gennem en tilmelding på en ISRG hjemmeside og via andre markedsføringsmaterialer. Enhver kommunikation leveret via Salesforce og dine interaktioner med [Salesforce](https://www.salesforce.com/company/privacy/) er underlagt deres privatlivspolitikker. Vi kan lejlighedsvis bruge din e-mail-adresse til at sende personlige meddelelser relateret til ISRG og dets projekter. Du kan anmode om at få din e-mailadresse fjernet ved at fravælge via sidefoden af vores e-mails eller sende os en e-mail på press@abetterinternet.org.
 
@@ -81,7 +81,7 @@ Vi behandler personoplysninger som beskrevet i denne politik. Formålet med og r
 
 **Lov grundlag:** Legitime interesser
 
-**Yderligere oplysninger:** Vi indsamler og behandler oplysninger for at behandle og understøtte donationer.
+**Yderligere oplysninger:** Vi indsamler og behandler oplysninger for at behandle og støtte donationer, opfylde donor fordele, og vedligeholde nøjagtigheden af vores donor optegnelser.
 
 **Formål:** Juridiske forpligtelser og formildende omstændigheder
 

diff --git a/content/fr/docs/faq.md b/content/fr/docs/faq.md
@@ -117,6 +117,6 @@ Nous demandons aux clients [ACME d'effectuer les renouvellements de routine à d
 
 ## Où puis-je en savoir plus sur TLS/SSL et PKI en général ?
 
-Ivan Ristić, chercheur et praticien de la sécurité de longue date, a publié un guide de configuration qui fournit des informations utiles sur ce que vous devez prendre en compte lors de la <a href="https://www.feistyduck.com/library/bulletproof-tls-guide/online/" target="_blank" rel="noopener noreferer">mise en place de votre configuration TLS</a>.
+Ivan Ristić, chercheur et praticien de la sécurité de longue date, a publié un guide de configuration qui fournit des informations utiles sur ce que vous devez prendre en compte lors de la <a href="https://www.feistyduck.com/library/bulletproof-tls-guide/online/" target="_blank" rel="noopener noreferrer">mise en place de votre configuration TLS</a>.
 
-Pour un contenu plus complet et plus détaillé, nous recommandons <a href="https://www.feistyduck.com/books/bulletproof-tls-and-pki/" target="_blank" rel="noopener noreferer">Bulletproof TLS and PKI</a>, également écrit par Ristić.
+Pour un aperçu plus complet et des informations plus détaillées, nous vous recommandons l'ouvrage <a href="https://www.feistyduck.com/books/bulletproof-tls-and-pki/" target="_blank" rel="noopener noreferrer">Bulletproof TLS and PKI</a>, également rédigé par Ristić.
diff --git a/content/fr/docs/integration-guide.md b/content/fr/docs/integration-guide.md
@@ -45,9 +45,9 @@ Toutefois, pour la plupart des grands hébergeurs, nous recommandons d'utiliser
 
 # Certificats multi-domaines (SAN)
 
-Notre [politique d'émission](/docs/rate-limits) autorise jusqu'à 100 noms par certificat. Il vous appartient d'utiliser un certificat distinct pour chaque nom d'hôte ou de regrouper plusieurs noms d'hôtes sur un petit nombre de certificats.
+Nous autorisons jusqu'à 100 noms par certificat en fonction du [profil de certificat](/docs/profiles/) sélectionné. Il vous appartient d'utiliser un certificat distinct pour chaque nom d'hôte ou de regrouper plusieurs noms d'hôtes sur un petit nombre de certificats.
 
-L'utilisation de certificats distincts par nom d'hôte signifie qu'il faut moins de démarches pour ajouter et retirer des domaines, lorsqu'ils sont attribués et retirés. Des certificats séparés réduisent également la taille des certificats, ce qui peut accélérer les échanges HTTPS sur les réseaux à faible débit.
+L'utilisation de certificats distincts par nom d'hôte signifie qu'il faut moins de démarches pour ajouter et retirer des domaines, lorsqu'ils sont attribués et retirés. Des certificats séparés réduisent également la taille des certificats, ce qui peut accélérer les échanges HTTPS sur les réseaux à faible débit. Vérifiez notre [débit limite](/docs/rate-limits) pour vous assurer que vous pouvez obtenir autant de certificats que nécessaire.
 
 D'autre part, l'utilisation de gros certificats avec de nombreux noms d'hôtes vous permet de gérer globalement moins de certificats. Si vous devez prendre en charge des clients plus anciens comme Windows XP qui ne prennent pas en charge l'indication de nom de serveur TLS ([SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)), vous aurez besoin d'une adresse IP unique pour chaque certificat, de ce fait, mettre plus de noms sur chaque certificat réduit le nombre d'adresses IP dont vous aurez besoin.
 

diff --git a/content/fr/docs/ipv6.md b/content/fr/docs/ipv6.md
@@ -1,7 +1,7 @@
 ---
 title: Support IPv6
 slug: ipv6-support
-lastmod: 2020-02-07
+lastmod: 2026-08-04
 show_lastmod: 1
 ---
 
@@ -24,7 +24,7 @@ Dans la plupart des cas, la correction consiste à mettre à jour l'adresse IPv6
 
 La tentative d'IPv6 à IPv4 n'a lieu que lorsque les délais de connexion sont dépassés, et non pour d'autres types d'erreurs.
 
-Par exemple, dans le scénario "Pièges communs" ("Common Pitfalls") ci-dessus, une nouvelle tentative ne se produira pas si un serveur web écoute l'adresse IPv6, mais que ce serveur n'est pas prêt à relever le challenge ACME. Dans ce cas, il n'y aurait pas de délai de connexion pour accéder à l'adresse IPv6 et le challenge échouera sans nouvelle tentative parce qu'une réponse incorrecte a été renvoyée.
+Par exemple, dans le scénario ci-dessus, une nouvelle tentative ne se produira pas si un serveur web écoute l'adresse IPv6, mais que ce serveur n'est pas prêt à relever le défi ACME. Dans ce cas, il n'y aurait pas de délai de connexion pour accéder à l'adresse IPv6 et le défi échouera sans nouvelle tentative parce qu'une réponse incorrecte a été renvoyée.
 
 Pour que notre logiciel d'AC reste simple, nous n'effectuons qu'une nouvelle tentative IPv6 à IPv4 à la première demande lors de la validation des challenges "http-01". Si vous utilisez des redirections, les redirections n'obtiendront pas de nouveau traitement.
 

diff --git a/content/zh-cn/docs/faq.md b/content/zh-cn/docs/faq.md
@@ -117,6 +117,6 @@ Let's Encrypt 颁发的是标准的域名验证型证书，凡是有域名的服
 
 ## 在哪里可以深入了解 TLS/SSL 与 PKI 的相关知识？
 
-资深网络安全学者 Ivan Ristić 曾发表过一篇配置指南，列举了<a href="https://www.feistyduck.com/library/bulletproof-tls-guide/online/" target="_blank" rel="noopener noreferer">设置 TLS 应注意的事项</a>，参考价值很高。
+资深网络安全学者 Ivan Ristić 曾发表过一篇配置指南，列举了<a href="https://www.feistyduck.com/library/bulletproof-tls-guide/online/" target="_blank" rel="noopener noreferrer">设置 TLS 应注意的事项</a>，参考价值很高。
 
-如果要更广泛、更深入地学习相关背景知识，推荐 Ristić 的另一部著作 <a href="https://www.feistyduck.com/books/bulletproof-tls-and-pki/" target="_blank" rel="noopener noreferer">Bulletproof TLS and PKI</a>。
+如果要更广泛、更深入地学习相关背景知识，推荐 Ristić 的另一部著作 <a href="https://www.feistyduck.com/books/bulletproof-tls-and-pki/" target="_blank" rel="noopener noreferrer">Bulletproof TLS and PKI</a>。