diff --git a/content/da/docs/expiration-emails.md b/content/da/docs/expiration-emails.md
index 9cbc4d6d3c..4e144e8214 100644
--- a/content/da/docs/expiration-emails.md
+++ b/content/da/docs/expiration-emails.md
@@ -3,18 +3,18 @@ title: Udløbs E-Mail
slug: expiration-emails
top_graphic: 1
date: 2016-07-02
-lastmod: 2021-09-25
+lastmod: 2023-01-09
show_lastmod: 1
---
# Abonnér
-Hvis du angiver en e-mailadresse til Let's Encrypt når du opretter din konto, vil vi automatisk sende dig udløbs varsler, når dit certifikat snart skal fornyes. Vi sender den første besked 20 dage før dit certifikat udløber, og flere beskeder ved 10 dage og 1 dag før det udløber. Vi anbefaler, at du stoler på din ACME-klient til automatisk at forny dine certifikater, og brug kun disse udløbsmeddelelser som en advarsel til at tjekke din automatisering.
+Hvis du angiver en e-mailadresse til Let's Encrypt når du opretter din konto, vil vi automatisk sende dig udløbs varsler, når dit certifikat snart skal fornyes. Vi forsøger at sende den første meddelelse 20 dage før dit certifikat udløber, og den anden og sidste meddelelse 7 dage før det udløber. Vi anbefaler, at du stoler på din ACME-klient til automatisk at forny dine certifikater, og brug kun disse udløbsmeddelelser som en advarsel til at tjekke din automatisering.
# Når du får en udløbs e-mail
-Hvis dit certifikat allerede er fornyet, sender vi ikke en udløbsbesked. Vi anser et certifikat for at blive fornyet, hvis der er et nyere certifikat med det nøjagtige samme sæt navne, uanset hvilken konto der har oprettet den. Hvis du har udstedt et nyt certifikat, der tilføjer eller fjerner et navn i forhold til dit gamle certifikat, vil du få udløbs-e-mail om dit gamle certifikat. Hvis du tjekker certifikatet, der aktuelt kører på din hjemmeside, og det viser den korrekte dato, er der ikke behov for yderligere handling.
+Hvis dit certifikat allerede er fornyet, sender vi ikke en udløbsbesked. Vi anser et certifikat for at blive fornyet, hvis der er et nyere certifikat med det nøjagtige samme sæt navne, uanset hvilken konto der har oprettet den. Hvis du har udstedt et nyt certifikat, der tilføjer eller fjerner et navn i forhold til dit gamle certifikat, vil du få udløbs-e-mail om dit gamle certifikat. Hvis du tjekker certifikatet, der aktuelt kører på din hjemmeside, og det viser den korrekte dato, er der ikke behov for yderligere handling. For at se en historik af udstedte certifikater for dit domæne, du kan søge efter dit domæne på certifikatgennemsigtighed log overvågere såsom [crt.sh](https://crt.sh/).
# Afmeld abonnement
diff --git a/content/da/docs/lencr-org.md b/content/da/docs/lencr-org.md
index 006341f12d..3fc03a97af 100644
--- a/content/da/docs/lencr-org.md
+++ b/content/da/docs/lencr-org.md
@@ -2,17 +2,43 @@
title: lencr.org
slug: lencr.org
top_graphic: 1
-date: 2020-12-04
-lastmod: 2020-12-04
+date: 2021-11-30
+lastmod: 2022-09-30
show_lastmod: 1
---
-# Hvad er lencr.org?
+# Hvad er `lencr.org`?
-`lencr.org` er et domæne ejet af Let's Encrypt. Vi bruger det til at være vært for OCSP, CRL'er, og udstedercertifikater: alle de webadresser, der vises i certifikater.
+`lencr.org` er et domæne ejet af Let's Encrypt. Vi bruger den til at være vært for data, der refereres til inde i de certifikater, vi udsteder.
+
+# Hvorfor henter min computer disse oplysninger? Er det skadeligt?
+
+Nej, oplysningerne på `lencr.org` er aldrig skadelige. Når en enhed forbinder til `lencr. rg`, det er fordi klientsoftware på denne enhed (som en webbrowser eller en app) forbundet til et andet websted, så at det var et Let's Encrypt certifikat, og forsøger at bekræfte, at det er gyldigt. Dette sker rutinemæssigt i mange klienter.
+
+Vi kan ikke tale med, om *det andet site* er forbundet er skadeligt. Hvis du undersøger netværksaktivitet, der synes usædvanligt, så vil du måske gerne fokusere på den forbindelse, der startede lige før forbindelsen til `lencr. rg`.
+
+Mønstret for kundernes forbindelser til `lencr.org` kan se usædvanligt ud eller intermitterende. Klienter henter muligvis aldrig disse data; henter kun delsæt af det eller "cache" nogle data for effektivitet, så de kun får adgang til det nogle gange (første gang de har brug for det, og når oplysningerne kan være udløbet).
+
+# Hvad skal disse data præcist bruges til?
+
+Når klientsoftware (som en webbrowser eller en app) forbinder til et websted, og dette websted præsenterer et certifikat, bør klienten kontrollere, at certifikatet er autentisk og gyldigt. Disse data hjælper klienterne med at gøre det på flere måder.
+
+* På `o.lencr.org`leverer vi data om Online Certificate Status Protocol (OCSP). En klient kan bruge disse data til at bekræfte, om et individuelt certifikat, som vi har udstedt, stadig er gyldigt eller er blevet tilbagekaldt. (Dette er kun for "end-entity" eller "leaf" certifikater, som vi har udstedt til abonnenter fra en af vores mellemliggende certifikater.)
+
+* Under `c.lencr.org`leverer vi certifikattilbagekaldelseslister (CRL) med lister af alle de ikke udløbne certifikater, som vi udstedte og senere har tilbagekaldt.
+
+* Under `i.lencr.org`, vi leverer kopier af vores mellemliggende "udsteder" certifikater, som enten er underskrevet af et af vores rodcertifikater eller "krydssigneret" af en anden certifikatautoritet (CA). En klient kan bruge disse data til at bekræfte "tillidskæden" fra slutenheds-certifikatet, som det er verificeret via et eller flere mellemliggende trin til et root-CA-certifikat, som det genkender og stoler på.
+
+# Hvorfor er forbindelser til `o.lencr.org` over usikker HTTP?
+
+OCSP-svar serveres altid over HTTP. Hvis de blev serveret over HTTPS, ville der være et "uendeligt løkke" problem: for at verificere OCSP-serverens certifikat, kunden skal bruge OCSP.
+
+OCSP-svaret selv er tidsstemplet og kryptografisk underskrevet, så anti-manipulation egenskaber af TLS er ikke nødvendige i dette tilfælde.
+
+# Hvad er `lencr.org`"?
Vi plejede at bruge længere URL'er som `http://ocsp.int-x3.letsencrypt.org/`. Men da vi udstedte vores [nye rod- og intermediate certifikater][1], ønskede vi at gøre dem så korte som muligt. Hver HTTPS-forbindelse på nettet (milliarder pr. dag) skal sende en kopi af et certifikat, så hver byte betyder noget. Vi valgte `lencr.org` på grund af dens lighed med vores navn: **L**et's **ENCR**ypt. Vi udtaler det meget ligesom den fiktive region [Lancre][] i Terry Pratchett's _Discworld_ romaner.
[1]: https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html
-[Lancre]: https://discworld.fandom.com/wiki/Lancre
+[Lancre]: https://wiki.lspace.org/Lancre
diff --git a/content/da/docs/too-many-registrations-for-this-ip.md b/content/da/docs/too-many-registrations-for-this-ip.md
index 6907a5e187..27c985bede 100644
--- a/content/da/docs/too-many-registrations-for-this-ip.md
+++ b/content/da/docs/too-many-registrations-for-this-ip.md
@@ -19,7 +19,7 @@ De »registreringer«, denne fejl henviser til, er anmodninger, der sendes fra d
# Almindelige Årsager
-Abonnenter, der rammer grænsen for fejlvalidering, gør det ofte på grund af en fejlkonfiguration i deres miljø.
+Abonnenter, der rammer grænsen for registreringer per IP, gør det ofte på grund af en fejlopsætning i deres miljø.
## Gentagne Udrulninger
diff --git a/content/da/donate.html b/content/da/donate.html
index 7b3b4e06a9..8a01cce9f2 100644
--- a/content/da/donate.html
+++ b/content/da/donate.html
@@ -4,7 +4,7 @@
slug: donate
top_graphic: 3
no_donate_footer: true
-lastmod: 2019-09-18
+lastmod: 2023-08-08
menu:
main:
weight: 30
@@ -13,25 +13,105 @@
-
-
Vi gør det muligt for alle at opleve et internet, der er sikkert og med respekt for privatlivets fred. Vi gør det nemt at få certifikater til HTTPS, fordi brugervenlighed er afgørende for udbredelsen. Vi leverer certifikater gratis, fordi omkostningerne udelukker personer. Vores certifikater er tilgængelige i alle lande i verden, fordi et sikkert Web er for alle. Vi stræber efter at være åbne og gennemsigtige, fordi disse værdier er afgørende for tillid.
+
Er du fra en organisation, der ønsker at støtter vores arbejde? At blive en sponsor kan være en bedre egnet for dig. Læs mere.
+
+ Vi gør det muligt for alle at opleve et internet, der er sikkert og med respekt for privatlivets fred.
+ Vi gør det enkelt at få certifikater til HTTPS gennem brugervenlig adgang er afgørende for udbredelsen. Vi leverer certifikater gratis, fordi omkostningerne udelukker personer. Vores certifikater er tilgængelige i alle lande i verden, fordi et sikkert Web er for alle. Vi stræber efter at være åbne og gennemsigtige, fordi disse værdier er afgørende for tillid.
+
{{% fundraiser %}}
- {{< donorbox >}}
-
-
-
Vi er i stand til at modtage Bitcoin donationer svarende til $ 1.000 USD eller større. Send venligst donate@letsencrypt.org til fakturering.
+
+
+
Donations Formular
+
+
+ {{< donorbox>}}
+
+
+
Værdipapir donationer
+
+
+
+ Værdsatte værdipapirer eller andele i investeringsforeninger, som du har ejet i mere end et år, kan være fremragende velgørende gaver.
+
+
+
+
Købsmæglerfirma:
+
Vanguard
+
+
+
Kontonavn:
+
Internet Security Research Group
+
+
+
ISRG Konto Nummer:
+
44865458
+
+
+
DTC #:
+
0062
+
+
+
US Skatte ID #:
+
46-3344200
+
+
+
+ Lad os venligst vide, om du overfører værdipapirer på
+ sponsor@abetterinternet.org. Du vil muligvis også ønske at e-maile brevet af autorisation fra din mægler.
+
+
-
-
Alternativt kan du anvende PayPal:
-
{{< paypal >}}
+
+
+
Kryptovaluta Gaver
+
+
+
+ Vi kan acceptere de fleste kryptovaluta donationer
+ her.
+
+
-
-
Internet Security Research Group er den offentlige ydelsesorganisation 501(c)(3) bag Let's Encrypt. Vores EIN-kode er: 46-3344200.
+
+
+
Donorforvaltede Fonde
+
+
+
+ Anbefal en donation til Internet Security Research Group (vores forælder
+ org) fra din gavefond. 100% af din donation vil gå til at støtte en sikker og beskyttelse af privatlivets fred på internettet.
+
+
+
+
+
+
Via din arbejdsplads
+
+
+
Vi anbefaler, at din arbejdsgiver støtter vores arbejde gennem Sponsorat.
+
+
+ Mange organisationer matcher donationer til nonprofit foretaget af medarbejdere.
+ Tjek om din organisation har et matchende program, der kan fordoble din donation!
+
+ {{< double_donation >}}
+
+
+
+
+
+ Internet Security Research Group er den offentlige almennyttige organisation 501(c)(3) bag Let's Encrypt. Vores EIN-kode er: 46-3344200.
+
diff --git a/content/da/thankyou.md b/content/da/thankyou.md
index 9950898a59..51af85d265 100644
--- a/content/da/thankyou.md
+++ b/content/da/thankyou.md
@@ -1,10 +1,4 @@
---
-title: Tak for dit bidrag til ISRG
slug: thankyou
-top_graphic: 2
-date: 2018-04-12
+untranslated: 1
---
-
-Tak fordi du støtter et mere sikkert og privatlivs respekterende internet for os alle. Følg os på [Twitter @letsencrypt](https://twitter.com/letsencrypt) for at holde dig opdateret om vores udvikling.
-
-Din transaktion er fuldført, og en kvittering for dit bidrag er blevet sendt via email til dig. Du kan logge ind på din konto på [www.paypal.com/us](https://www.paypal.com/us) for at se detaljer for denne transaktion.
diff --git a/content/pl/docs/staging-environment.md b/content/pl/docs/staging-environment.md
index 2eab875f48..85304d345b 100644
--- a/content/pl/docs/staging-environment.md
+++ b/content/pl/docs/staging-environment.md
@@ -8,7 +8,7 @@ show_lastmod: 1
---
-Stanowczo zalecamy przeprowadzenie testów z naszym środowiskiem testowym przez użyciem naszego oficjalnego środowiska. Pozwoli to na sprawdzenie poprawności przed wydaniem zaufanych certyfikatów oraz zmniejszy szansę na osiągnięcie limitów przesyłu.
+Stanowczo zalecamy przeprowadzenie testów z naszym środowiskiem testowym przed użyciem naszego oficjalnego środowiska. Pozwoli to na sprawdzenie poprawności przed wydaniem zaufanych certyfikatów oraz zmniejszy szansę na osiągnięcie limitów przesyłu.
Adres URL ACME dla naszego [środowiska testowego ACME v2](https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605) to:
@@ -42,10 +42,10 @@ Wydawanie ECDSA zostało [włączone dla testowania](https://community.letsencry
# Przejrzystość certyfikatów
-Środowisko testowe przesyła wstępne certyfikaty do dzienników testów CT Let's Encrypt Sapling i Google testtube i uwzględnia zwrócone SCT w wystawionych certyfikatach.
+Środowisko testowe przesyła wstępne certyfikaty do dzienników testów CT Let's Encrypt [Sapling](/docs/ct-logs) i Google [testtube](http://www.certificate-transparency.org/known-logs#TOC-Test-Logs) i uwzględnia zwrócone SCT w wystawionych certyfikatach.
# Ciągła Integracja / Testowanie Rozwojowe
Środowisko testowe generuje limity szybkości, aby umożliwić testowanie, ale nie sprzyja to integracji ze środowiskami programistycznymi lub ciągłej integracji (CI). Wysyłanie żądań sieciowych do serwerów zewnętrznych może spowodować niestabilność, a środowisko testowe nie pozwala na „sfałszowanie” DNS ani zakwestionowanie powodzenia walidacji, co powoduje bardziej skomplikowane konfiguracje testów.
-Oprócz środowiska testowego Let's Encrypt oferuje mały serwer ACME zbudowany specjalnie dla CI i środowisk programistycznych o nazwie Pebble. Uruchamianie Pebble na komputerze programistycznym lub w środowisku CI jest szybkie i łatwe.
+Oprócz środowiska testowego Let's Encrypt oferuje mały serwer ACME zbudowany specjalnie dla CI i środowisk programistycznych o nazwie [Pebble](https://github.com/letsencrypt/pebble). Uruchamianie Pebble na komputerze programistycznym lub w środowisku CI jest [szybkie i łatwe](https://github.com/letsencrypt/pebble#docker).
diff --git a/content/uk/about.md b/content/uk/about.md
index d99e18d8be..f3269e1ed9 100644
--- a/content/uk/about.md
+++ b/content/uk/about.md
@@ -14,15 +14,15 @@ Let's Encrypt це безкоштовний, повністю автоматиз
Ми даємо людям цифрові сертифікати, потрібні щоб їх сайти працювали через HTTPS (SSL/TLS), безкоштовно, у найбільш зручний спосіб. Ми робимо це, тому що хочемо створити більш захищений і конфіденційний Інтернет.
-Дізнайтесь про нашу роботу минулого року, завантаживши [річний звіт](https://abetterinternet.org/documents/2020-ISRG-Annual-Report.pdf).
+Дізнайтесь про нашу роботу минулого року, завантаживши [річний звіт](https://www.abetterinternet.org/annual-reports/).
Ключові принципи Let's Encrypt:
-* Безкоштовно: Кожен, хто володіє доменним іменем, може скористатися Let's Encrypt, щоб отримати надійний сертифікат не витрачаючи ні копійки.
-* Автоматично: Програмне забезпечення, що працює на веб-сервері, може отримати сертифікат від Let's Encrypt, надійно його налаштовувати та автоматично оновлювати.
-* Безпечно: Let's Encrypt служитиме платформою використовуючи кращі практики безпеки TLS. Створюючи безпечний ЦС та для допомагаючи власникам сайтів належним чином захищати свої сервери.
-* Прозоро: Всі видані та відкликані сертифікати, фіксуються та є доступними для перевірки будь-ким.
-* Доступно: Протокол видачі та оновлення сертифікатів [опублікований](https://tools.ietf.org/html/rfc8555) як відкритий стандарт, який будь-то може використовувати.
-* Колективно: На зразок інших Інтернет-протоколів, Let's Encrypt це спільні зусилля на користь спільноти та поза контролем будь-якої організації.
+* **Безкоштовно:** Кожен, хто володіє доменним іменем, може скористатися Let's Encrypt, щоб отримати надійний сертифікат не витрачаючи ні копійки.
+* **Автоматично:** Програмне забезпечення, що працює на веб-сервері, може отримати сертифікат від Let's Encrypt, надійно його налаштовувати та автоматично оновлювати.
+* **Безпечно:** Let's Encrypt служитиме платформою використовуючи кращі практики безпеки TLS. Створюючи безпечний ЦС та для допомагаючи власникам сайтів належним чином захищати свої сервери.
+* **Прозоро:** Всі видані та відкликані сертифікати, фіксуються та є доступними для перевірки будь-ким.
+* **Доступно:** Протокол видачі та оновлення сертифікатів [опублікований](https://tools.ietf.org/html/rfc8555) як відкритий стандарт, який будь-то може використовувати.
+* **Колективно:** На зразок інших Інтернет-протоколів, Let's Encrypt це спільні зусилля на користь спільноти та поза контролем будь-якої організації.
У нас є сторінка з детальнішим описом [як працює ЦС Let's Encrypt](/how-it-works).
diff --git a/content/uk/contact.md b/content/uk/contact.md
index 322e16f1f7..54ccc98547 100644
--- a/content/uk/contact.md
+++ b/content/uk/contact.md
@@ -3,7 +3,7 @@ title: Контакти
slug: contact
description: Як з нами зв'язатися
top_graphic: 1
-lastmod: 2021-08-31
+lastmod: 2023-09-26
menu:
main:
weight: 90
@@ -20,9 +20,13 @@ menu:
Електронна пошта: [sponsor@letsencrypt.org](mailto:sponsor@letsencrypt.org)
-## Розсилка
+## Підписуйтеся на наші новини
-Щоб підписатися на нашу розсилку, [натисніть тут.](https://mailchi.mp/letsencrypt.org/fjp6ha1gad)
+
+
+## Приватність
+
+Електронна пошта: [privacy@abetterinternet.org](mailto:privacy@abetterinternet.org)
## Безпека
diff --git a/content/uk/docs/challenge-types.md b/content/uk/docs/challenge-types.md
index 0f42453548..f5b9f7be26 100644
--- a/content/uk/docs/challenge-types.md
+++ b/content/uk/docs/challenge-types.md
@@ -3,7 +3,7 @@ title: Типи викликів
slug: challenge-types
top_graphic: 1
date: 2019-02-25
-lastmod: 2020-12-08
+lastmod: 2023-02-13
show_lastmod: 1
---
@@ -34,13 +34,13 @@ show_lastmod: 1
Така перевірка вимагає у вас підтвердження прав на домен за допомогою спеціального значення в TXT-записі для цього доменного імені. Це складніше налаштувавати, ніж HTTP-01, але вона покриває сценарії, що не підлягають HTTP-01 перевірці. Дозволяє видачу wildcard-сертифікатів. Після того, як Let’s Encrypt видає ACME-клієнтові токен, клієнт створює TXT-запис на основі цього токена та ключа облікового запису, і записує його в`_acme-challenge.`. Далі, Let’s Encrypt створює запит йього запису в DNS-системі. Якщо значення співпадають - ви можете переходити до видачі сертифікату!
-Вкрай важливо автоматизувати процеси випуску та поновлення сертифікатів, тому є сенс використовувати перевірку DNS-01, якщо ваш DNS-провайдер надає API для автоматичних оновлень. Наша спільнота має [список таких DNS-провайдерів тут ](https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438). DNS-провайдером може бути реєстратор (компанія, у якої ви придбали доменне ім'я), або стороння організація. Якщо ви хочете змінити свого DNS-провайдера, то потрібно зробити деякі незначні зміни у вашому реєстраторі доменів. При цьому очікувати закінчення терміну дії домену не потрібно.
+Вкрай важливо автоматизувати процеси випуску та поновлення сертифікатів, тому є сенс використовувати перевірку DNS-01, якщо ваш DNS-провайдер надає API для автоматичних оновлень. Наша спільнота має [список таких DNS-провайдерів тут ][dns-api-providers]. DNS-провайдером може бути реєстратор (компанія, у якої ви придбали доменне ім'я), або стороння організація. Якщо ви хочете змінити свого DNS-провайдера, то потрібно зробити деякі незначні зміни у вашому реєстраторі доменів. При цьому очікувати закінчення терміну дії домену не потрібно.
-Зверніть увагу, що розміщення повної інформації про облікові записи для DNS API на веб-серверах значно збільшує шкоду у випадку взлому цього веб-сервера. Краще використовувати [обліковий запис із обмеженими можливостями](https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation), або здійснювати DNS перевірку на окремому сервері з подальщим копіюванням сертифікатів на ваш веб-сервер.
+Зверніть увагу, що розміщення повної інформації про облікові записи для DNS API на веб-серверах значно збільшує шкоду у випадку взлому цього веб-сервера. Краще використовувати [обліковий запис із обмеженими можливостями][securing-dns-credentials], або здійснювати DNS перевірку на окремому сервері з подальщим копіюванням сертифікатів на ваш веб-сервер.
-Оскільки Let’s Encrypt притримується стандартів DNS для пошуку TXT-записів при перевірці DNS-01, використовуйте записи CNAME або NS для делегування відповідей за перевірку на інші DNS-зони. Для спеціального серверу або зони валідації налаштуйте [делегування `_acme-перевірки` субдомену](https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation). Ви також можете використати це делегування якщо ваш DNS-провайдер повільно оновлюється і ви хочете використати сервер, що оновлюється швидше.
+Оскільки Let’s Encrypt притримується стандартів DNS для пошуку TXT-записів при перевірці DNS-01, використовуйте записи CNAME або NS для делегування відповідей за перевірку на інші DNS-зони. Для спеціального серверу або зони валідації налаштуйте [делегування `_acme-перевірки` субдомену][securing-dns-credentials]. Ви також можете використати це делегування якщо ваш DNS-провайдер повільно оновлюється і ви хочете використати сервер, що оновлюється швидше.
-Більшість DNS-провайдерів мають "період обробки даних", що визначає скільки часу пройде пройде з моменту оновлення запису DNS, доки він стане доступним для всіх серверах. Цей час складно виміряти, оскільки вони часто використовують [anycast](https://en.wikipedia.org/wiki/Anycast). Це означає, що декілька серверів можуть мати однакову IP-адресу, і, в залежності від місця вашого перебування, ви та Let’s Encrypt можете взаємодіяти з різними серверами (і отримувати різні результати). Найкращі DNS API автоматично сповістять про повне оновлення записів. Якщо DNS-провайдер такої інформації не надає, потрібно налаштувати вашого клієнта на тривале очікування (приблизно годину) запуску валідації для забезпечення повного оновлення.
+Більшість DNS-провайдерів мають "період обробки даних", що визначає скільки часу пройде пройде з моменту оновлення запису DNS, доки він стане доступним для всіх серверах. Цей час складно виміряти, оскільки вони часто використовують [anycast][]. Це означає, що декілька серверів можуть мати однакову IP-адресу, і, в залежності від місця вашого перебування, ви та Let’s Encrypt можете взаємодіяти з різними серверами (і отримувати різні результати). Найкращі DNS API автоматично сповістять про повне оновлення записів. Якщо DNS-провайдер такої інформації не надає, потрібно налаштувати вашого клієнта на тривале очікування (приблизно годину) запуску валідації для забезпечення повного оновлення.
Ви можете мати декілька TXT-записів для одного імені. Наприклад, при потребі виконати перевірку для wildcard-сертифікату та для простого сертифікату водночас. Видаляйте застарілі TXT-записи, оскільки через великий розмір відповіді, Let’s Encrypt може відхиляти перевірку.
@@ -57,13 +57,13 @@ show_lastmod: 1
# TLS-SNI-01
-Ця перевірка визначена в чорновій версії ACME. Виконується TLS handshake на порті 443 і надсилається спеціальний [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) заголовок для пошуку сертифікату, що містить токен. [була відключена у березні 2019 року](https://community.letsencrypt.org/t/march-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209) через недостатню безпечність.
+Ця перевірка визначена в чорновій версії ACME. Виконується TLS handshake на порті 443 і надсилається спеціальний [SNI][] заголовок для пошуку сертифікату, що містить токен. [була відключена у березні 2019 року][tls-sni-disablement] через недостатню безпечність.
# TLS-ALPN-01
-Ця перевірка розроблена як [окремий стандарт](https://tools.ietf.org/html/rfc8737) після визнання TLS-SNI-01 застарілою. Як і TLS-SNI-01, перевірка виконується через TLS на порті 443. Але при цьому використовується протокол ALPN, щоб на запити валідації відповідали тільки сервери, які знають про такий тип перевірки. Крім того, запити валідації для цього типу перевірки можуть використовувати SNI-поле, що збігається з доменним ім'ям, для якого проводиться валідація з метою збільшення надійності перевірки.
+Ця перевірка розроблена як [окремий стандарт][tls-alpn] після визнання TLS-SNI-01 застарілою. Як і TLS-SNI-01, перевірка виконується через TLS на порті 443. Але при цьому використовується протокол ALPN, щоб на запити валідації відповідали тільки сервери, які знають про такий тип перевірки. Крім того, запити валідації для цього типу перевірки можуть використовувати SNI-поле, що збігається з доменним ім'ям, для якого проводиться валідація з метою збільшення надійності перевірки.
-Ця перевірка не підходить для більшості людей. Швидше, вона призначена для власників TLS-кінцевих зворотних проксі-серверів для виконання перевірки типу HTTP-01, але всередині шару TLS для поділу відповідальності. Здебільшого це стосується великих хостинг-провайдерів, але розповсюджені веб-сервери як Apache та Nginx можуть колись це реалізувати (і [Caddy вже реалізував](https://caddy.community/t/caddy-supports-the-acme-tls-alpn-challenge/4860)).
+Ця перевірка не підходить для більшості людей. Швидше, вона призначена для власників TLS-кінцевих зворотних проксі-серверів для виконання перевірки типу HTTP-01, але всередині шару TLS для поділу відповідальності. Здебільшого це стосується великих хостинг-провайдерів, але розповсюджені веб-сервери як Apache та Nginx можуть колись це реалізувати (і [Caddy вже реалізував][caddy-tls-alpn]).
Переваги:
@@ -75,3 +75,12 @@ show_lastmod: 1
- Не підтримується Apache, Nginx, або Certbot, і, ймовірно не буде найближчим часом.
- Як і за перевірки HTTP-01, при наявності декількох серверів, всі вони мають відповідати однаковим вмістом.
- Метод не може використовуватись для валідації wildcard-доменів.
+
+[dns-api-providers]: https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438
+[securing-dns-credentials]: https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation
+[securing-dns-credentials]: https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation
+[anycast]: https://en.wikipedia.org/wiki/Anycast
+[SNI]: https://en.wikipedia.org/wiki/Server_Name_Indication
+[tls-sni-disablement]: https://community.letsencrypt.org/t/march-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209
+[tls-alpn]: https://tools.ietf.org/html/rfc8737
+[caddy-tls-alpn]: https://caddy.community/t/caddy-supports-the-acme-tls-alpn-challenge/4860
diff --git a/content/uk/docs/godaddy.md b/content/uk/docs/godaddy.md
index 2183f1c498..cd23e521e0 100644
--- a/content/uk/docs/godaddy.md
+++ b/content/uk/docs/godaddy.md
@@ -8,10 +8,14 @@ show_lastmod: 1
---
-Ми отримуємо багато запитань про те, як використовувати Let's Encrypt на GoDaddy. Якщо ви використовуєте Спільний веб -хостинг GoDaddy, наразі встановити Let’s дуже складно. Зашифруйте сертифікат, тому наразі не рекомендуємо використовувати наші сертифікати разом із GoDaddy. Це тому, що GoDaddy не підтримує [ протокол ACME ](https://tools.ietf.org/html/rfc8555) для автоматизованої видачі та поновлення. Натомість GoDaddy пропонує автоматичне оновлення за допомогою власних сертифікатів, які є [ функцією додаткової вартості ](https://www.godaddy.com/web-security/ssl-certificate).
+Ми отримуємо багато запитань про те, як використовувати Let's Encrypt на GoDaddy. Якщо ви використовуєте Спільний веб -хостинг GoDaddy, наразі встановити Let’s дуже складно. Зашифруйте сертифікат, тому наразі не рекомендуємо використовувати наші сертифікати разом із GoDaddy. Це тому, що GoDaddy не підтримує [ протокол ACME ][1] для автоматизованої видачі та поновлення. Натомість GoDaddy пропонує автоматичне оновлення за допомогою власних сертифікатів, які є [ функцією додаткової вартості ][2].
Ми не рекомендуємо використовувати сертифікати Let’s Encrypt для провайдерів хостингу, що не застосовують безпосередньо протокол ACME, тому що це означає, що ви не можете повністю автоматизувати поновлення. Ми вважаємо, що автоматичне поновлення є дуже важливою частиною використання сертифікатів. Використання програмного забезпечення для автоматизації оновлення робить найменш ймовірним те, що термін дії вашого сертифіката закінчиться без поновлення. Якщо ваш сертифікат закінчується, це дуже засмучує ваших користувачів, оскільки вони не мають доступу до вашого сайту.
Оскільки ми настільки сильно віримо в автоматичне оновлення, то ми розробляємо наші сертифікати для використання з автоматизацією ACME. Це має бути сертифікат Let’s Encrypt автоматично поновлюється через 60 днів і припиняє роботу через 90 днів, якщо не оновлюється.
-Якщо, переглянувши вищевказані проблеми, ви вирішили, що хочете спробувати ведення сертифіката Let’s Encrypt на спільному хостингу GoDaddy, GoDaddy [ забезпечить інструкціями ](https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023). Майте на увазі, що слідувати цим інструкціям займає багато часу, і ви повинні це робити кожні 60 днів (а не кожні 90 днів, як описано на сторінці з посиланням).
+Якщо, переглянувши вищевказані проблеми, ви вирішили, що хочете спробувати ведення сертифіката Let’s Encrypt на спільному хостингу GoDaddy, GoDaddy [ забезпечить інструкціями ][3]. Майте на увазі, що слідувати цим інструкціям займає багато часу, і ви повинні це робити кожні 60 днів (а не кожні 90 днів, як описано на сторінці з посиланням).
+
+[1]: https://tools.ietf.org/html/rfc8555
+[2]: https://www.godaddy.com/web-security/ssl-certificate
+[3]: https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023
diff --git a/content/uk/getinvolved.md b/content/uk/getinvolved.md
index 8429c417c7..3ec344c415 100644
--- a/content/uk/getinvolved.md
+++ b/content/uk/getinvolved.md
@@ -25,7 +25,7 @@ show_lastmod: 1
### Програмне забезпечення на сервері ЦС
-[Boulder](https://github.com/letsencrypt/boulder) - це реалізація Let's Encrypt Центром сертифікації. Вона заснована на [ACME](https://tools.ietf.org/html/rfc8555) протоколі і переважно написана у Go. Найкраще розпочати зі списку ['help wanted' issues](https://github.com/letsencrypt/boulder/labels/help%20wanted) та [contributors guide](https://github.com/letsencrypt/boulder/blob/master/CONTRIBUTING.md).
+[Boulder](https://github.com/letsencrypt/boulder) - це реалізація Let's Encrypt Центром сертифікації. Вона заснована на [ACME](https://tools.ietf.org/html/rfc8555) протоколі і переважно написана у Go. Найкраще розпочати зі списку ['help wanted' issues](https://github.com/letsencrypt/boulder/labels/help%20wanted) та [contributors guide](https://github.com/letsencrypt/boulder/blob/main/docs/CONTRIBUTING.md).
### letsencrypt.org
diff --git a/content/uk/getting-started.md b/content/uk/getting-started.md
index 5ce2ced97c..0c358e9281 100644
--- a/content/uk/getting-started.md
+++ b/content/uk/getting-started.md
@@ -11,9 +11,9 @@ date: 2020-02-11
# З наявністю Shell Access
-Ми радимо всім, з shell access, використовувати [Certbot](https://certbot.eff.org/ "Certbot") ACME-клієнт. Аби марно не витрачати час, на Certbot є можливість автоматизувати видачу та встановлення сертифікатів. Для тих, хто не хоче мати автоматичні налаштування, є режим "експерта". Він дуже легкий у використанні, підтримується багатьма операційними системами та має чудову документацію. [Перейдіть на сайт Certbot](https://certbot.eff.org/ "Certbot") для того, щоб отримати налаштовані інструкції для вашої операційної системи та веб-сервера.
+Ми радимо всім, з shell access, використовувати [Certbot][] ACME-клієнт. Аби марно не витрачати час, на Certbot є можливість автоматизувати видачу та встановлення сертифікатів. Для тих, хто не хоче мати автоматичні налаштування, є режим "експерта". Він дуже легкий у використанні, підтримується багатьма операційними системами та має чудову документацію. [Перейдіть на сайт Certbot][Certbot] для того, щоб отримати налаштовані інструкції для вашої операційної системи та веб-сервера.
-Якщо [Certbot](https://certbot.eff.org/ "Certbot") не відповідає вашим потребам, або ви хочете спробувати щось інше, є [багатий вибір інших ACME-клієнтів](/docs/client-options). Як тільки ви обрали клієнтське програмне забезпечення ACME, перегляньте документацію, аби продовжити роботу.
+Якщо [Certbot][] не відповідає вашим потребам, або ви хочете спробувати щось інше, є [багатий вибір інших ACME-клієнтів](/docs/client-options). Як тільки ви обрали клієнтське програмне забезпечення ACME, перегляньте документацію, аби продовжити роботу.
Якщо ви експериментуєте з різними ACME-клієнтами, використовуйте наше [тестове середовище](/docs/staging-environment) для того, щоб уникнути [обмеження швидкості ](/docs/rate-limits).
@@ -30,3 +30,7 @@ date: 2020-02-11
# Допомога
Якщо у Вас є питання щодо вибору ACME-клієнта, використання одного з них, або будь-чого іншого пов'язаного з Let's Encrypt, будь ласка, спробуйте звернутися до [форумів спільнот з корисною інформацією](https://community.letsencrypt.org/).
+
+[Certbot]: https://certbot.eff.org/ "Certbot"
+
+[Certbot]: https://certbot.eff.org/ "Certbot"
diff --git a/content/uk/sponsors.html b/content/uk/sponsors.html
index 3f100534be..b3fb33b1a5 100644
--- a/content/uk/sponsors.html
+++ b/content/uk/sponsors.html
@@ -2,7 +2,7 @@
title: Спонсори та фонди
slug: sponsors
top_graphic: 1
-date: 2018-06-22
+date: 2023-07-12
menu:
main:
weight: 50
diff --git a/content/uk/thankyou.html b/content/uk/thankyou.html
new file mode 100644
index 0000000000..846d6c5341
--- /dev/null
+++ b/content/uk/thankyou.html
@@ -0,0 +1,21 @@
+---
+title: Дякуємо
+slug: thankyou
+top_graphic: 2
+date: 2022-12-02
+aliases:
+ - /thank-you
+---
+
+
+
+
+
Дякуємо за ваш внесок
+
Від імені всіх в ISRG, дякуємо вам за ваш внесок в підтримку нашої роботи.
+
На вашу електронну адресу було надіслано квитанцію про отримання пожертви. Internet Security Research Group є неприбутковою організацією 501(c)(3). Наш ідентифікаційний код (EIN): 46-3344200.
+
Подвойте вашу пожертву
+
Багато організацій подвоюють пожертви зроблені їх працівниками. Перевірте, чи ваша організація має такі програми і чи може подвоїти ваш вплив!
+
+ {{< double_donation >}}
+
+
diff --git a/content/uk/thankyou.md b/content/uk/thankyou.md
index 09561fd267..51af85d265 100644
--- a/content/uk/thankyou.md
+++ b/content/uk/thankyou.md
@@ -1,10 +1,4 @@
---
-title: Дякуємо вам за підтримку ISRG
slug: thankyou
-top_graphic: 2
-date: 2018-04-12
+untranslated: 1
---
-
-Дякуємо за підтримку більш безпечної та приватної павутини для всіх нас. Підпишіться на наш [Twitter @letsencrypt](https://twitter.com/letsencrypt) щоб бути вкурсі наших останніх оновлень.
-
-Транзакція була успішною, чек про оплату був надісланий вам електронною поштою. Ви можете увійти до свого облікового запису на [www.paypal.com/us](https://www.paypal.com/us) щоб переглянути деталі.
diff --git a/content/uk/trademarks.md b/content/uk/trademarks.md
index 299e35ea4e..2fcb3ce397 100644
--- a/content/uk/trademarks.md
+++ b/content/uk/trademarks.md
@@ -1,4 +1,10 @@
---
+title: Політика щодо товарних знаків
slug: trademarks
-untranslated: 1
+top_graphic: 1
+lastmod: 2021-08-11
+english_is_canonical: 1
+show_lastmod: 1
---
+
+Посилання на торгову марку змінилося. Будь ласка відвідайте: [https://www.abetterinternet.org/trademarks](https://www.abetterinternet.org/trademarks)
diff --git a/content/uk/upcoming-features.md b/content/uk/upcoming-features.md
index b0dc38a3ff..6a43313b86 100644
--- a/content/uk/upcoming-features.md
+++ b/content/uk/upcoming-features.md
@@ -2,20 +2,22 @@
title: Майбутні можливості
slug: upcoming-features
top_graphic: 1
-lastmod: 2021-09-16
+lastmod: 2023-06-20
show_lastmod: 1
---
-## Інформація про оновлення системи ACME (ARI)
-
-Ми працюємо над системою, яка дозволить нам повідомляти передплатників через API, коли потрібно буде відновити. Ця система дозволить нам сигналізувати підписникам, що вони потребують поновлення до цього, наприклад, події відкликання.
-
## Корінь та проміжні ланки ECDSA
Ми випускаємо сертифікати з нашого виробничого проміжного ECDSA-сертифіката для [акаунтів, занесених до списку дозволених](https://community.letsencrypt.org/t/ecdsa-availability-in-production-environment/150679). Запланована дата видалення списку дозволу відсутня.
# Виконані можливості
+## Інформація про оновлення системи ACME (ARI)
+
+* Увімкнено: 23 березня 2023 року
+
+Ми запустили [ARI](https://letsencrypt.org/2023/03/23/improving-resliiency-and-reliability-with-ari.html), систему, яка дозволяє повідомляти користувачів через API, коли вони виконати оновлення.
+
## Багатоперспективна валідація
* Увімкнено: 19 лютого 2020 року
diff --git a/content/zh-cn/docs/a-warm-welcome-to-asn1-and-der.md b/content/zh-cn/docs/a-warm-welcome-to-asn1-and-der.md
index 603d215517..bc88d67b41 100644
--- a/content/zh-cn/docs/a-warm-welcome-to-asn1-and-der.md
+++ b/content/zh-cn/docs/a-warm-welcome-to-asn1-and-der.md
@@ -56,7 +56,7 @@ DER 格式的证书通常会进一步转换成 PEM 格式,这一过程采用 [
INTEGER
-------
-就是老生常谈的整数。 可以是正数,也可以是负数。 ASN.1 的 INTEGER 类型最为特别之处在于大小不限。 int64 不够大? 小事一桩。 这对于表示 RSA 模数之类远超 int64 范围的整数(比如 22048)尤为有用。 严格说来 DER 格式的整数范围是有上限的,但上限极高:任何 DER 字段的长度必须能够用 126 个字节来表示。 因此,DER 能表示的最大的 INTEGER 数值是 256(2\*\*1008)−1。真正无限大的 INTEGER 必须用 BER 编码,因为 BER 对字段长度没有限制。
+就是老生常谈的整数。 可以是正数,也可以是负数。 ASN.1 的 INTEGER 类型最为特别之处在于大小不限。 int64 不够大? 小事一桩。 这对于表示 RSA 模数之类远超 int64 范围的整数(比如 22048)尤为有用。 严格说来 DER 格式的整数范围是有上限的,但上限极高:任何 DER 字段的长度必须能够用 126 个字节来表示。 因此,DER 能表示的最大的 INTEGER 数值是 256(2\*\*1008)−1。 真正无限大的 INTEGER 必须用 BER 编码,因为 BER 对字段长度没有限制。
字符串
-------
diff --git a/content/zh-cn/docs/expiration-emails.md b/content/zh-cn/docs/expiration-emails.md
index 84979882cb..96d5ffaffe 100644
--- a/content/zh-cn/docs/expiration-emails.md
+++ b/content/zh-cn/docs/expiration-emails.md
@@ -3,18 +3,18 @@ title: 过期提醒邮件
slug: expiration-emails
top_graphic: 1
date: 2016-07-02
-lastmod: 2021-09-25
+lastmod: 2023-01-09
show_lastmod: 1
---
# 订阅邮件提醒
-如果您在创建帐户时向 Let's Encrypt 提供电子邮件地址,我们将尽最大努力在您的证书即将更新时自动向您发送到期通知。 我们会在您的证书到期前 20 天发送第一个通知,并在其到期前 10 天和 1 天发送更多通知。 我们建议您设置 ACME 客户端自动更新您的证书,并且仅使用这些到期通知作为检查您的自动化的警告。
+如果您在创建帐户时向 Let's Encrypt 提供电子邮件地址,我们将尽最大努力在您的证书即将更新时自动向您发送到期通知。 我们会在证书到期前 20 天向您发送第一次通知,并在到期前 7 天发送第二次(也是最后一次)通知。 我们建议您设置 ACME 客户端自动更新您的证书,并且仅使用这些到期通知作为检查您的自动化的警告。
# 当您收到过期提醒邮件时
-如果您的证书已经续期,我们将不会发送到期通知。 如果有具有完全相同域名列表的新证书,无论是哪个账户创建了该证书,我们都会将其认定为续期证书。 如果您在旧证书的域名列表中添加或删除了域名后颁发了新证书,您仍将收到有关旧证书的过期提醒邮件。 如果当前在您的网站上使用的证书的日期正确,则无需进一步操作。
+如果您的证书已经续期,我们将不会发送到期通知。 如果有具有完全相同域名列表的新证书,无论是哪个账户创建了该证书,我们都会将其认定为续期证书。 如果您在旧证书的域名列表中添加或删除了域名后颁发了新证书,您仍将收到有关旧证书的过期提醒邮件。 如果当前在您的网站上使用的证书的日期正确,则无需进一步操作。 如需查看您的域名证书颁发记录,可以在监控证书透明度日志的网站(例如 [crt.sh](https://crt.sh/))中查询您的域名。
# 退订邮件提醒
diff --git a/content/zh-cn/docs/glossary.md b/content/zh-cn/docs/glossary.md
index 8b6686fe61..bdc2557f1e 100644
--- a/content/zh-cn/docs/glossary.md
+++ b/content/zh-cn/docs/glossary.md
@@ -57,7 +57,7 @@ Note for translators:
{{% def id="CPS" name="证书实践声明" english="Certification Practice Statement" abbr="CPS" %}} 证书颁发机构对证书进行颁发、管理、吊销、续期、更换密钥时所采用的实践的声明。 [ISRG 证书实践声明](/repository#isrg-certification-practice-statement) - [RFC 3647 3.4 节](https://tools.ietf.org/html/rfc3647#section-3.4) [维基百科条目](https://en.wikipedia.org/wiki/Certification_Practice_Statement){{% /def %}}
-{{% def id="critical" name="关键扩展" english="Critical extension" %}} 证书中可以包含被标记为“关键”的[扩展](#def-extension)。这意味着软件如果不知道如何处理该扩展,就必须拒绝该证书。 这使得引入对于安全性十分重要的新扩展时不在较老的软件上造成风险成为可能。 {{% /def %}}
+{{% def id="critical" name="关键扩展" %}} 证书中的[扩展](#def-extension)可以标记为“关键”扩展, 如果软件不知道如何处理此扩展,就必须拒绝使用该证书。 这使得引入对于安全性十分重要的新扩展时不在较老的软件上造成风险成为可能。 {{% /def %}}
{{% def id="CRL" name="证书吊销列表" english="Certificate Revocation List" abbr="CRL" %}} 通知[用户代理](#def-user-agent)[证书](#def-leaf)的[吊销](#def-revocation)状态的方法。 这是一个由 CA 签名的,包含了所有已被该 CA 吊销的证书的序列号的列表。 [维基百科条目](https://en.wikipedia.org/wiki/Certificate_revocation_list){{% /def %}}
@@ -81,13 +81,13 @@ Note for translators:
{{% def id="DV" name="域名验证型证书" english="Domain-validated certificate" %}} 申请者仅证明了其对域名(而非申请的组织)的控制权的[证书](#def-leaf)。 [Let's Encrypt](#def-LE)仅提供 DV 证书,不提供 [OV](#def-OV)或 [EV](#def-EV)证书:[常见问题]](/docs/faq) - [维基百科条目](https://en.wikipedia.org/wiki/Domain-validated_certificate){{% /def %}}
-{{% def id="ECDSA" name="椭圆曲线数字签名算法" english="Elliptic Curve Digital Signature Algorithm" abbr="ECDSA" abbr_first="1" %}} 使用椭圆曲线加密的数字签名算法(DSA)的变体。 \[维基百科条目\](https://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E6%95%B0%E5%AD%97%E7%AD%BE%E5%90%8D%E7%AE%97%E6%B3%95)。 \[Let's Encrypt\](#def-LE) 支持使用 ECDSA 的\[叶证书(终端实体证书)\](#def-leaf),但没有全部使用 ECDSA 的完整\[证书链\](#def-chain):\[/upcoming-features\](/upcoming-features) {{% /def %}}
+{{% def id="ECDSA" name="椭圆曲线数字签名算法" english="Elliptic Curve Digital Signature Algorithm" abbr="ECDSA" abbr_first="1" %}} 使用椭圆曲线加密的数字签名算法(DSA)的变体。 参见[维基百科条目](https://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E6%95%B0%E5%AD%97%E7%AD%BE%E5%90%8D%E7%AE%97%E6%B3%95)。 [Let's Encrypt](#def-LE) 支持在[叶证书(最终实体证书)](#def-leaf)中使用 ECDSA,但暂时没有完整的 ECDSA [证书链](#def-chain)。参见[即将推出的功能](/upcoming-features)。{{% /def %}}
-{{% def id="Ed25519" english="Ed25519" %}} 一种特殊类型的 \[EdDSA\](#def-EdDSA),类似的还有 Ed448。 {{% /def %}}
+{{% def id="Ed25519" name="Ed25519" %}} [EdDSA](#def-EdDSA) 的一种类型,类似的还有 Ed448。 {{% /def %}}
-{{% def id="EdDSA" name="爱德华兹曲线数字签名算法" english="Edwards-curve Digital Signature Algorithm" abbr="EdDSA" abbr_first="1" %}} 基于椭圆曲线的现代公钥签名系统。它是为了解决一些常见的椭圆曲线加密的\[实现问题\](https://ed25519.cr.yp.to/)而被设计出来的。 \[Let's Encrypt\](#def-LE) 等证书颁发机构暂时还不能提供 EdDSA 证书。 \[维基百科条目\](https://en.wikipedia.org/wiki/EdDSA) {{% /def %}}
+{{% def id="EdDSA" name="爱德华兹曲线数字签名算法" english="Edwards-curve Digital Signature Algorithm" abbr="EdDSA" abbr_first="1" %}} 基于椭圆曲线的现代公钥签名系统,其设计旨在解决椭圆曲线密码的一些常见[实现问题](https://ed25519.cr.yp.to/)。 [Let's Encrypt](#def-LE) 这样的证书颁发机构暂时还不能提供 EdDSA 证书。 参见[维基百科条目](https://en.wikipedia.org/wiki/EdDSA)。{{% /def %}}
-{{% def id="ECC" name="椭圆曲线加密" english="Elliptic Curve Cryptography" abbr="ECC" %}} 基于椭圆曲线的公钥密码学。 相较于非椭圆曲线的加密方式,ECC 在提供同等的安全性的前提下使用更小的密钥。 \[Cloudflare\](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/) - \[维基百科条目\](https://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6) {{% /def %}}
+{{% def id="ECC" name="椭圆曲线加密" english="Elliptic Curve Cryptography" abbr="ECC" %}} 基于椭圆曲线的公钥密码学。 相较于非椭圆曲线的加密方式,ECC 在提供同等的安全性的前提下使用更小的密钥。 参见 [Cloudflare](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/) 和[维基百科条目](https://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6)。{{% /def %}}
{{% def id="EV" name="扩展验证" english="Extended Validation" abbr="EV" %}} \[CA\](#def-CA) 验证对网站有控制权的法律实体的证书验证方式。 此类证书包含有该实体的相关信息。 \[CA\](#def-CA) 对此类证书的控制比 \[OV\](#def-OV) 证书要更严格。 \[Let's Encrypt\](#def-LE) 不提供 EV 证书。 \[维基百科条目\](https://zh.wikipedia.org/wiki/%E6%89%A9%E5%B1%95%E9%AA%8C%E8%AF%81%E8%AF%81%E4%B9%A6) {{% /def %}}
@@ -165,7 +165,7 @@ Note for translators:
{{% def id="UCC" name="统一通信证书" english="Unified Communications Certificate" abbr="UCC" %}} 包含多个\[主体备用名称(SAN)\](#def-SAN)的证书。 {{% /def %}}
-{{% def id="web-browser" name="网页浏览器" english="Web Browser" %}} 用于显示网页的\[用户代理\](#def-user-agent)。 例如: *Mozilla Firefox* , *Google Chrome* 和 *Internet Explorer* 。 \[维基百科条目\](https://zh.wikipedia.org/wiki/%E7%BD%91%E9%A1%B5%E6%B5%8F%E8%A7%88%E5%99%A8) {{% /def %}}
+{{% def id="web-browser" name="网页浏览器" %}} 一类用于显示网页内容的[用户代理](#def-user-agent), 例如 *Mozilla Firefox*、*Google Chrome* 和 *Safari*。 参见[维基百科条目](https://zh.wikipedia.org/wiki/%E7%BD%91%E9%A1%B5%E6%B5%8F%E8%A7%88%E5%99%A8)。{{% /def %}}
{{% def id="user-agent" name="用户代理" english="User Agent" %}} 能够与\[Web 服务器\](#def-web-server)通信的软件。 例如:\[网页浏览器\](#def-web-browser)和 \[cURL\](https://zh.wikipedia.org/wiki/CURL)。 {{% /def %}}
@@ -177,6 +177,5 @@ Note for translators:
{{% renderglossary %}}
-
+
-
diff --git a/content/zh-cn/docs/lencr-org.md b/content/zh-cn/docs/lencr-org.md
index 247d05dfbb..51e17536d5 100644
--- a/content/zh-cn/docs/lencr-org.md
+++ b/content/zh-cn/docs/lencr-org.md
@@ -2,17 +2,43 @@
title: lencr.org
slug: lencr.org
top_graphic: 1
-date: 2020-12-04
-lastmod: 2020-12-04
+date: 2021-11-30
+lastmod: 2022-09-30
show_lastmod: 1
---
-# 什么是 `lencr.org`?
+# `lencr.org` 是什么?
-`lencr.org` 是由 Let's Encrypt 拥有的一个域名。 我们使用它来托管我们颁发的证书中引用的数据。
+`lencr.org` 是 Let's Encrypt 旗下的一个域名。 我们颁发的证书中有部分数据指向该域名。
-我们曾经使用较长的 URL,例如 `http://ocsp.int-x3.letsensencrypt.org/`。 然而, 当我们在发布 [新的根证书和中间证书][1]时,我们想要 使它们尽可能小一些。 Web 上的每个HTTPS连接 (每天数十亿) 必须发送证书副本,因此每个字节都很重要。 我们选择 `lencr.org` 因为它与我们的名称相似: **L**et's **ENCR**ypt。 它的发音很像 Terry Pratchett 的 _Discworld_ 小说中名为 [Lancle][] 的虚构区域。
+# 我的电脑为什么会从这个网站获取数据? 这是恶意的吗?
+
+不,`lencr.org` 网站上没有任何恶意数据。 设备会连接到 `lencr.org` 是因为设备上的软件(比如浏览器或应用)连接了另外一个使用 Let's Encrypt 证书的网站,正在核实证书是否有效。 这是很多客户端的正常流程。
+
+我们无法断言上述的*另外一个网站*是否存在风险, 如果您正在调查异常的网络活动,或许应该关注与 `lencr.org` 紧邻的上一条连接。
+
+客户端与 `lencr.org` 之间的连接模式可能较为反常,没有规律可循。 有些客户端从来不会从该网站获取数据,有些则只下载部分数据,或者出于性能考虑缓存了部分数据,因此只会偶尔(首次下载以及数据过期后)建立连接。
+
+# 数据内容究竟是什么?
+
+客户端程序(比如浏览器或应用)连接网站并收到一份证书时,需要核实证书是否真实有效。 以下数据可以从各个角度帮助客户端达成这一目的。
+
+* `o.lencr.org` 提供了证书状态(OCSP)信息。 客户端可以通过此信息确认我们颁发的某一份未过期的证书是否有效,或已被提前吊销。 (只适用于“最终实体证书”,或称“叶证书”,即由我们的中间证书颁发给用户的证书。)
+
+* `c.lencr.org` 提供了证书吊销列表(CRL),包含我们颁发后未过期就被提前吊销的所有证书。
+
+* `i.lencr.org` 提供了我们的“颁发者”中间证书,经过我们的根证书签名,或是由其他证书颁发机构(CA)“交叉签名”。 客户端可以依据此信息通过一份或多份中间证书追溯至其认可的根证书,从而确认待核实的证书的“信任链”。
+
+# 为什么连接 `o.lencr.org` 使用的是不安全的 HTTP 协议?
+
+OCSP 数据都是通过 HTTP 协议明文传输的。 如果要用 HTTPS,客户端就必须再通过 OCSP 协议验证 OCSP 服务器的证书,导致无限循环。
+
+OCSP 服务器响应的数据本身就含有时间戳,并且经过数字签名,所以这种情况下不需要 TLS 的防篡改机制。
+
+# 为什么用 "`lencr.org`"?
+
+我们也用过更长的网址,比如 `http://ocsp.int-x3.letsencrypt.org/`。 但在颁发[新的根证书和中间证书][1]时,我们决定尽可能缩短网址的长度。 每天有数十亿 HTTPS 连接在互联网上建立,每条连接都要传输一份证书,因此证书的每个字节都举足轻重。 我们选择 `lencr.org` 因为它与我们的名称相似: **L**et's **ENCR**ypt。 其读法类似 Terry Pratchett 所著小说《碟形世界》中名为 [Lancre][] 的虚构地区。
[1]: https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html
-[Lancle]: https://wiki.lspace.org/Lancre
+[Lancre]: https://wiki.lspace.org/Lancre
diff --git a/content/zh-cn/docs/rate-limits.md b/content/zh-cn/docs/rate-limits.md
index 4533f9f4f9..8684a3b83a 100644
--- a/content/zh-cn/docs/rate-limits.md
+++ b/content/zh-cn/docs/rate-limits.md
@@ -27,14 +27,14 @@ id="new-orders">**订单**。 每次向 Boulder CA 申请证书都会创建
**请求吊销证书不会重设速率限制**,因为申请证书所使用的资源已经被消耗了。
-There is a!!crwdBlockTags_34_sgaTkcolBdwrc!![**Failed Validation**](/docs/failed-validation-limit) limit of 5 failures per account, per hostname, per hour. 这个限制在我们的[测试环境](/docs/staging-environment)中更高,因此您可以使用它来调试连接性问题。 超出验证失败限制将会得到 `too many failed authorizations recently` 的报错信息。
+[**验证失败**](/docs/failed-validation-limit)的限制为每个账户、每个域名、每小时 5 次。 这个限制在我们的[测试环境](/docs/staging-environment)中更高,因此您可以使用它来调试连接性问题。 超出验证失败限制将会得到 `too many failed authorizations recently` 的报错信息。
API 的"new-nonce"、"new-account"、"new-order"和"revoke-cert"接口**总请求数**限制为每秒 20 次。 "/directory"端点和"/acme"目录及其子目录的总请求数限制为每秒 40 次。
此外还有两个您不太可能遇到的限制。
-您在3小时之内每个IP地址最多可以创建10个**账户**。 **每个 IPv6 /48 地址段**每 3 小时最多可以创建 500 个账户。 达到这两个账户限制是十分罕见的,我们建议我们建议大型集成商[使用一个帐户为多个客户提供服务](/docs/integration-guide)。 超过这些限制的请求,将会得到 `too many registrations for this IP` 或者 `too many registrations for this IP range`的报错信息。
+[**每个 IP 地址**](/docs/too-many-registrations-for-this-ip)每 3 个小时最多可创建 10 个账户。 **每个 IPv6 /48 地址段**每 3 小时最多可以创建 500 个账户。 达到这两个账户限制是十分罕见的,我们建议我们建议大型集成商[使用一个帐户为多个客户提供服务](/docs/integration-guide)。 超过这些限制的请求,将会得到 `too many registrations for this IP` 或者 `too many registrations for this IP range`的报错信息。
您的帐户最多可以有 300 个**待验证授权**。 达到此速率限制很少见,并且通常在开发 ACME 客户端时发生。 到达此限制通常意味着您的客户正在创建授权但没有验证授权。 如果您正在开发 ACME 客户端,请使用我们的[测试环境](/docs/staging-environment)。 超出待验证授权数量限制的请求,将会得到 `too many currently pending authorizations`的报错信息。
@@ -42,7 +42,7 @@ id="overall-requests">**总请求数**限制为每秒 20 次。 "/directory"
如果您达到了速率限制,我们没有办法帮助您暂时重置它。 您需要等待一周,直到这些速率限制过期。 我们使用了滑动窗口的方式,因此如果你在周一申请签发了25张证书,并且在周五又申请签发了25张证书,那么下周一起你将可以再次申请签发证书。 你可以在利用公开[证书透明度](https://www.certificate-transparency.org)记录的 [ crt.sh ](https://crt.sh) 网站上搜索获取你已经申请签发的证书列表。
-如果您是需要集成 Let's Encrypt 的大型托管服务提供商或组织,您可以使用[速率限制表单](https://goo.gl/forms/plqRgFVnZbdGhE9n1)请求更高的速率限制。 处理请求需要几周时间。因此,如果您只是不想等待一周,想要提前进行速率限制重置,请不要使用该表单。
+如果您是需要集成 Let's Encrypt 的大型托管服务提供商或组织,您可以使用[速率限制表单](https://isrg.formstack.com/forms/rate_limit_adjustment_request)请求更高的速率限制。 处理请求需要几周时间。因此,如果您只是不想等待一周,想要提前进行速率限制重置,请不要使用该表单。
# 清除待验证的授权
diff --git a/content/zh-cn/stats.html b/content/zh-cn/stats.html
index a9e84782af..f6bddc6c2e 100644
--- a/content/zh-cn/stats.html
+++ b/content/zh-cn/stats.html
@@ -4,7 +4,7 @@
slug: stats
top_graphic: 3
excerpt: Let's Encrypt 统计数据。
-lastmod: 2019-08-22
+lastmod: 2023-02-28
menu:
main:
weight: 70
@@ -12,6 +12,8 @@
---
+