From a58253a9e44dda2116a4d353dd71aac7e6db59a3 Mon Sep 17 00:00:00 2001 From: Ludek Janda Date: Wed, 7 Oct 2026 09:55:41 +0200 Subject: [PATCH] Udpates in CS,DA,FR,JA,RU,SV,ZH-CN --- config/_default/languages.cs.toml | 4 +- config/_default/languages.zh-cn.toml | 4 +- content/cs/docs/caa.md | 2 +- content/cs/docs/glossary.md | 2 +- content/cs/docs/profiles.md | 2 +- content/da/docs/faq.md | 2 +- content/da/docs/profiles.md | 2 +- content/fr/docs/faq.md | 2 +- content/ja/about.md | 4 +- content/ja/docs/account-id.md | 6 +- content/ja/docs/acme-protocol-updates.md | 4 +- content/ja/docs/allow-port-80.md | 8 +- content/ja/docs/certificates-for-localhost.md | 26 +-- content/ja/thankyou.md | 4 +- content/ru/docs/faq.md | 2 +- content/sv/docs/glossary.md | 2 +- content/sv/docs/profiles.md | 2 +- content/zh-cn/about.md | 4 +- content/zh-cn/certificates.md | 18 +- .../docs/a-warm-welcome-to-asn1-and-der.md | 178 +++++++++--------- content/zh-cn/docs/account-id.md | 4 +- content/zh-cn/docs/acme-protocol-updates.md | 6 +- content/zh-cn/docs/allow-port-80.md | 8 +- content/zh-cn/docs/caa.md | 44 ++--- content/zh-cn/docs/cert-compat.md | 4 +- content/zh-cn/docs/cert-lifetimes.md | 10 +- .../zh-cn/docs/certificates-for-localhost.md | 26 +-- content/zh-cn/docs/challenge-types.md | 26 +-- content/zh-cn/docs/client-options.md | 8 +- content/zh-cn/docs/ct-logs.html | 16 +- ...st-root-ca-x3-expiration-september-2021.md | 14 +- content/zh-cn/docs/faq.md | 40 ++-- content/zh-cn/docs/glossary.md | 126 ++++++------- content/zh-cn/docs/godaddy.md | 6 +- content/zh-cn/docs/integration-guide.md | 64 +++---- content/zh-cn/docs/ipv6.md | 12 +- content/zh-cn/docs/lencr-org.md | 16 +- content/zh-cn/docs/monitoring-options.md | 6 +- content/zh-cn/docs/oids.md | 72 +++---- content/zh-cn/docs/profiles.md | 41 ++-- content/zh-cn/docs/rate-limits.md | 68 ++++--- content/zh-cn/docs/revoking.md | 20 +- content/zh-cn/docs/staging-environment.md | 18 +- content/zh-cn/docs/why-all-https.md | 12 +- content/zh-cn/getinvolved.md | 4 +- content/zh-cn/getting-started.md | 8 +- content/zh-cn/how-it-works.md | 18 +- content/zh-cn/privacy.md | 40 ++-- content/zh-cn/thankyou.md | 4 +- content/zh-cn/trademarks.md | 2 +- content/zh-cn/upcoming-features.md | 12 +- content/zh-tw/about.md | 4 +- content/zh-tw/docs/account-id.md | 4 +- content/zh-tw/docs/allow-port-80.md | 8 +- content/zh-tw/docs/lencr-org.md | 16 +- i18n/cs.toml | 2 +- i18n/zh-cn.toml | 2 +- 57 files changed, 530 insertions(+), 539 deletions(-) diff --git a/config/_default/languages.cs.toml b/config/_default/languages.cs.toml index 65421b239c..bf596113a2 100644 --- a/config/_default/languages.cs.toml +++ b/config/_default/languages.cs.toml @@ -6,9 +6,7 @@ weight = 150 [params] beforeColon = "" -description = """ -Let's Encrypt je bezplatná, automatizovaná a otevřená certifikační autorita, kterou vám přináší nezisková organizace Internet Security Research Group (ISRG). Vše o naší letošní neziskové práci si můžete přečíst v naší výroční zprávě za rok 2025. -""" +description = "Let's Encrypt je bezplatná, automatizovaná a otevřená certifikační autorita provozovaná neziskovou organizací Internet Security Research Group (ISRG). O naší práci se dočtete ve výroční zprávě." paypalDonateImage = "https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif" paypalCountry = "US" numberFormat = "-|,| " diff --git a/config/_default/languages.zh-cn.toml b/config/_default/languages.zh-cn.toml index 39f3a71169..89d9db6131 100644 --- a/config/_default/languages.zh-cn.toml +++ b/config/_default/languages.zh-cn.toml @@ -6,9 +6,7 @@ weight = 900 [params] beforeColon = "" -description = """ -Let's Encrypt 是一家免费、开放、自动化的证书颁发机构，由非营利组织互联网安全研究组 (ISRG) 运作。我们这一年来的非营利工作详情可在 2025 年度报告中查阅。 -""" +description = "Let's Encrypt 是一家免费、开放、自动化的证书颁发机构，由非营利组织互联网安全研究组 (ISRG) 运作。我们的各类工作开展情况均可在年度报告中查阅。" paypalDonateImage = "https://www.paypalobjects.com/zh_CN/i/btn/btn_donateCC_LG.gif" paypalCountry = "US" numberFormat = "-|.|" diff --git a/content/cs/docs/caa.md b/content/cs/docs/caa.md index 65d5d90ab6..b7978b68ad 100644 --- a/content/cs/docs/caa.md +++ b/content/cs/docs/caa.md @@ -1,7 +1,7 @@ --- title: Autorizace certifikační autority (CAA) slug: caa -lastmod: 2023-08-16 +lastmod: 2026-10-04 show_lastmod: 1 --- diff --git a/content/cs/docs/glossary.md b/content/cs/docs/glossary.md index e13476c2b7..698eb36031 100644 --- a/content/cs/docs/glossary.md +++ b/content/cs/docs/glossary.md @@ -1,7 +1,7 @@ --- title: Slovník pojmů slug: glossary -lastmod: 2026-09-08 +lastmod: 2026-10-04 show_lastmod: 1 description: "Slovník pojmů souvisejících s certifikáty SSL/TLS, protokolem HTTPS a zabezpečením webu, které používá Let's Encrypt." --- diff --git a/content/cs/docs/profiles.md b/content/cs/docs/profiles.md index 448da44631..1cbbde0391 100644 --- a/content/cs/docs/profiles.md +++ b/content/cs/docs/profiles.md @@ -1,7 +1,7 @@ --- title: Profily slug: profiles -lastmod: 2026-09-08 +lastmod: 2026-10-04 show_lastmod: false --- diff --git a/content/da/docs/faq.md b/content/da/docs/faq.md index 232245c5a4..3f99ca114c 100644 --- a/content/da/docs/faq.md +++ b/content/da/docs/faq.md @@ -44,7 +44,7 @@ Her er en [video, vi kan lide](https://www.youtube.com/watch?v=Xe1TZaElTAs) om s ## En hjemmeside der anvender Let's Encrypt er involveret i Phishing/Malware /? -Vi anbefaler, at sådanne websteder rapporteres til Google Safe Browsing og Microsoft Smart Screen program, som er i stand til mere effektivt at beskytte brugerne. Her er de rapporterings webadresserne: +Vi anbefaler, at sådanne websteder rapporteres til Google Safe Browsing og Microsoft SmartScreen program, som er i stand til mere effektivt at beskytte brugerne. Her er de rapporterings webadresserne: - [https://safebrowsing.google.com/safebrowsing/report_badware/](https://safebrowsing.google.com/safebrowsing/report_badware/) - [https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site-guest](https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site-guest) diff --git a/content/da/docs/profiles.md b/content/da/docs/profiles.md index cb8f8d5acf..3eee4c51b9 100644 --- a/content/da/docs/profiles.md +++ b/content/da/docs/profiles.md @@ -1,7 +1,7 @@ --- title: Profiler slug: profiles -lastmod: 2026-09-08 +lastmod: 2026-10-04 show_lastmod: false --- diff --git a/content/fr/docs/faq.md b/content/fr/docs/faq.md index 201e36cd29..a833aed14c 100644 --- a/content/fr/docs/faq.md +++ b/content/fr/docs/faq.md @@ -44,7 +44,7 @@ Voici une [vidéo que nous aimons](https://www.youtube.com/watch?v=Xe1TZaElTAs) ## Un site web utilisant Let's Encrypt se livre à des activités d'hameçonnage/de malveillance/d'escroquerie/... que dois-je faire ? -Nous recommandons de signaler ces sites à Google Safe Browsing et au programme Microsoft Smart Screen, qui sont en mesure de protéger plus efficacement les utilisateurs. Voici les URL de rapport : +Nous recommandons de signaler ces sites à Google Safe Browsing et au programme Microsoft SmartScreen, qui sont en mesure de protéger plus efficacement les utilisateurs. Voici les URL de rapport : - [https://safebrowsing.google.com/safebrowsing/report_badware/](https://safebrowsing.google.com/safebrowsing/report_badware/) - [https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site-guest](https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site-guest) diff --git a/content/ja/about.md b/content/ja/about.md index 13153a9aa7..0c2bf1d010 100644 --- a/content/ja/about.md +++ b/content/ja/about.md @@ -9,9 +9,9 @@ menu: parent: about --- -Let's Encrypt は、公共の利益のために運営されている、フリーで自動化されたオープンな認証局 (certificate authority; CA) です。 [インターネット・セキュリティ・研究グループ (Internet Security Research Group; ISRG)](https://www.abetterinternet.org/) がサービスを提供しています。 +Let's Encrypt は、公共の利益のために運営されている、フリーで自動化されたオープンな認証局 (certificate authority; CA) です。[インターネット・セキュリティ・研究グループ (Internet Security Research Group; ISRG)](https://www.abetterinternet.org/) がサービスを提供しています。 -私たちは人々のために、ウェブサイトで HTTPS (SSL/TLS) を有効にするために必要なデジタル証明書を、無料で、私たちにできる最もユーザーフレンドリーな方法で発行しています。 私たちがこのようなことをする理由は、よりセキュアでプライバシーを尊重するウェブを作りたいと願っているからです。 +私たちは人々のために、ウェブサイトで HTTPS (SSL/TLS) を有効にするために必要なデジタル証明書を、無料で、私たちにできる最もユーザーフレンドリーな方法で発行しています。私たちがこのようなことをする理由は、よりセキュアでプライバシーを尊重するウェブを作りたいと願っているからです。 Let's Encrypt の最新のレビューについては、[年次レポート](https://www.abetterinternet.org/annual-reports/)を読んでください。 diff --git a/content/ja/docs/account-id.md b/content/ja/docs/account-id.md index 552f4d1149..3ae79dd331 100644 --- a/content/ja/docs/account-id.md +++ b/content/ja/docs/account-id.md @@ -6,10 +6,10 @@ show_lastmod: 1 --- -問題を報告する場合は、Let's Encrypt のアカウント ID を提供できると大変役に立ちます。 ほとんどの場合、ACME クライアントソフトウェアにより自動的にアカウントを作成する処理が行われます。そして、あなたが複数のサーバー上で ACME クライアントを実行している場合には、複数のアカウントが設定されている可能性もあります。 +問題を報告する場合は、Let's Encrypt のアカウント ID を提供できると大変役に立ちます。ほとんどの場合、ACME クライアントソフトウェアにより自動的にアカウントを作成する処理が行われます。そして、あなたが複数のサーバー上で ACME クライアントを実行している場合には、複数のアカウントが設定されている可能性もあります。 あなたのアカウント ID は、`https://acme-v02.api.letsencrypt.org/acme/acct/12345678` という形式の URL で表されます。 -[Certbot](https://certbot.eff.org/) のバージョン 1.23.0 以上を使用している場合、`certbot show_account` サブコマンドを実行してください。 バージョン 1.23.0 未満の Certbot を使用している場合、アカウント ID は`/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/regr.json` ファイル内の "uri" フィールドを見ると確認できます。 +[Certbot](https://certbot.eff.org/) のバージョン 1.23.0 以上を使用している場合、`certbot show_account` サブコマンドを実行してください。バージョン 1.23.0 未満の Certbot を使用している場合、アカウント ID は`/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/regr.json` ファイル内の "uri" フィールドを見ると確認できます。 -その他の ACME クライアントを使用している場合は、確認するために必要な操作はクライアントに依存します。 上記の形式の URL を log から探してみてください。 ACME クライアントがアカウント ID を記録していない場合でも、同一のキーを使用して新規登録リクエストを送信することで ID を取得できます。 詳しくは、[ ACME の仕様](https://tools.ietf.org/html/rfc8555#section-7.3)を読んでください。 ACME クライアントが生成する各 POST に対するレスポンスの中の Boulder-Requester ヘッダでも、数値形式の ID が確認できます。 +その他の ACME クライアントを使用している場合は、確認するために必要な操作はクライアントに依存します。上記の形式の URL を log から探してみてください。 ACME クライアントがアカウント ID を記録していない場合でも、同一のキーを使用して新規登録リクエストを送信することで ID を取得できます。詳しくは、[ ACME の仕様](https://tools.ietf.org/html/rfc8555#section-7.3)を読んでください。 ACME クライアントが生成する各 POST に対するレスポンスの中の Boulder-Requester ヘッダでも、数値形式の ID が確認できます。 diff --git a/content/ja/docs/acme-protocol-updates.md b/content/ja/docs/acme-protocol-updates.md index 0b9dbc8f1f..83ff17633b 100644 --- a/content/ja/docs/acme-protocol-updates.md +++ b/content/ja/docs/acme-protocol-updates.md @@ -17,10 +17,10 @@ show_lastmod: 1 # 新しい後方互換の ACME の機能 -将来、Let's Encrypt は新しい後方互換の機能を既存の API エンドポイントに実装するかもしれません。 新しい後方互換の機能が追加されるのは、典型的には、以前は実装していなかった ACME 仕様の一部を実装することを決定した場合です +将来、Let's Encrypt は新しい後方互換の機能を既存の API エンドポイントに実装するかもしれません。新しい後方互換の機能が追加されるのは、典型的には、以前は実装していなかった ACME 仕様の一部を実装することを決定した場合です 既存の API エンドポイントに新しい機能が追加された場合、その機能は常にパブリックの ACME 仕様に明確に定義されます。それによって、適切に実装されたクライアントの動作が壊れることはありません。 # 破壊的な変更を伴う新しいバージョンの ACME -現在、ACME のサポートに対して破壊的な変更を行う予定はありません。しかし、そのような変更を行うことが重要であると判断した場合には、十分な時間を取ってスムーズな移行が行えるようにし、可能な限り早く情報を公開します。 システム管理者は、破壊的な変更が必要になった場合に備えて、使用している ACME クライアントにすぐに更新を適用できるようにしておく必要があります。 +現在、ACME のサポートに対して破壊的な変更を行う予定はありません。しかし、そのような変更を行うことが重要であると判断した場合には、十分な時間を取ってスムーズな移行が行えるようにし、可能な限り早く情報を公開します。システム管理者は、破壊的な変更が必要になった場合に備えて、使用している ACME クライアントにすぐに更新を適用できるようにしておく必要があります。 diff --git a/content/ja/docs/allow-port-80.md b/content/ja/docs/allow-port-80.md index 25d96eee2d..00f8a0c096 100644 --- a/content/ja/docs/allow-port-80.md +++ b/content/ja/docs/allow-port-80.md @@ -6,12 +6,12 @@ show_lastmod: 1 --- -ウェブサーバーへアクセスする 80 番ポートがファイアウォールでブロックされているため、HTTP-01 タイプのチャレンジを使用している人が問題につまずくという報告をときどき受けます。 私たちがおすすめするのは、一般的なウェブのユースを提供するすべてのサーバーは、HTTP のための 80 番ポートと HTTPS のための 443 番ポートの両方を開放することです。 また、80 番ポートへの HTTP アクセスに対して、443 番ポートの HTTPS へのリダイレクトを送信し、(443 版ポートへのリクエストに対しては) 可能ならば HSTS ヘッダを付与することを推奨しています。 +ウェブサーバーへアクセスする 80 番ポートがファイアウォールでブロックされているため、HTTP-01 タイプのチャレンジを使用している人が問題につまずくという報告をときどき受けます。私たちがおすすめするのは、一般的なウェブのユースを提供するすべてのサーバーは、HTTP のための 80 番ポートと HTTPS のための 443 番ポートの両方を開放することです。また、80 番ポートへの HTTP アクセスに対して、443 番ポートの HTTPS へのリダイレクトを送信し、(443 版ポートへのリクエストに対しては) 可能ならば HSTS ヘッダを付与することを推奨しています。 通常、80 番ポートを開放したことにより、サーバーへの大規模な攻撃を誘発することにはなりません。80 番ポートへのリクエストは、一般的には 443 番ポートに使用されているのと同じソフトウェアでサービスが提供されているからです。 -80 番ポートを閉じることは、ユーザーが HTTP でアクセスするリスクを減らすことにはなりません。 普通の状況では、HTTPS へのリダイレクトを受け取るため、それ以降の通信は保護されます。 もしもそのユーザーがアクティブな MITM (中間者攻撃) の対象となっていた場合でも、MITM は 80 番ポートで応答するため、ウェブサイトのユーザーがサーバーから connection refused (コネクション拒否) を受け取る心配がなくなります。 +80 番ポートを閉じることは、ユーザーが HTTP でアクセスするリスクを減らすことにはなりません。普通の状況では、HTTPS へのリダイレクトを受け取るため、それ以降の通信は保護されます。もしもそのユーザーがアクティブな MITM (中間者攻撃) の対象となっていた場合でも、MITM は 80 番ポートで応答するため、ウェブサイトのユーザーがサーバーから connection refused (コネクション拒否) を受け取る心配がなくなります。 -最後に、リダイレクトを提供するために 80 番ポートを開放しておけば、ユーザーが正しい HTTPS バージョンのウェブサイトにアクセスするのを助けることができます。 たとえば、メールの自動リンク機能が利用された場合や、手動でドメイン名が入力される場合など、あなたにはコントロールできないような状況はたくさんあります。 そういった場合には、単にエラーを表示するのではなく、リダイレクトを提供したほうが良いはずです。 +最後に、リダイレクトを提供するために 80 番ポートを開放しておけば、ユーザーが正しい HTTPS バージョンのウェブサイトにアクセスするのを助けることができます。たとえば、メールの自動リンク機能が利用された場合や、手動でドメイン名が入力される場合など、あなたにはコントロールできないような状況はたくさんあります。そういった場合には、単にエラーを表示するのではなく、リダイレクトを提供したほうが良いはずです。 -残念ながら、あなたのサイトの 80 番ポートをブロックするかどうかを、あなた自身ではコントロールできないような場合もあると思います。 ISP によっては、80 番ポートへのアクセスをブロックしている場合があります。 もしあなたが使用している ISP がブロックを行っている場合でも証明書を取得したい場合には、その他に2つの選択肢があります。DNS-01 チャレンジを使用するか、443番ポートで利用できる [TLS-ALPN-01 チャレンジをサポートしているクライアントの1つ](https://community.letsencrypt.org/t/which-client-support-tls-alpn-challenge/75859/2)を使用することです。 +残念ながら、あなたのサイトの 80 番ポートをブロックするかどうかを、あなた自身ではコントロールできないような場合もあると思います。 ISP によっては、80 番ポートへのアクセスをブロックしている場合があります。もしあなたが使用している ISP がブロックを行っている場合でも証明書を取得したい場合には、その他に2つの選択肢があります。DNS-01 チャレンジを使用するか、443番ポートで利用できる [TLS-ALPN-01 チャレンジをサポートしているクライアントの1つ](https://community.letsencrypt.org/t/which-client-support-tls-alpn-challenge/75859/2)を使用することです。 diff --git a/content/ja/docs/certificates-for-localhost.md b/content/ja/docs/certificates-for-localhost.md index 1c74a74902..b0bb5fa82a 100644 --- a/content/ja/docs/certificates-for-localhost.md +++ b/content/ja/docs/certificates-for-localhost.md @@ -5,33 +5,33 @@ lastmod: 2025-07-31 show_lastmod: 1 --- -ローカルの開発で使用したり、ウェブアプリケーションとの通信が必要なネイティブ・アプリケーションに配布するために、"localhost" というホスト名に対する証明書を発行したい場合もあると思います。 Let's Encrypt は、"localhost" に対する証明書を提供することはできません。理由は、その証明書をユニークに所有することができる主体が存在せず、".com" や ".net" のようなトップレベルのドメインをルートに持つことができないからです。 `127.0.0.1` に解決するドメインを自分自身でセットアップして、DNS チャレンジを使用して証明書を取得することは技術的には可能ではあります。 しかし、これは一般的に悪いアイデアであり、それよりも良い選択肢があります。 +ローカルの開発で使用したり、ウェブアプリケーションとの通信が必要なネイティブ・アプリケーションに配布するために、"localhost" というホスト名に対する証明書を発行したい場合もあると思います。 Let's Encrypt は、"localhost" に対する証明書を提供することはできません。理由は、その証明書をユニークに所有することができる主体が存在せず、".com" や ".net" のようなトップレベルのドメインをルートに持つことができないからです。 `127.0.0.1` に解決するドメインを自分自身でセットアップして、DNS チャレンジを使用して証明書を取得することは技術的には可能ではあります。しかし、これは一般的に悪いアイデアであり、それよりも良い選択肢があります。 # ローカルの開発のための証明書 -ウェブアプリを開発している場合、Apache や Nginx などのローカルのウェブサーバーを実行して、そのウェブアプリにはウェブブラウザから `http://localhost:8000/` でアクセスできるようにすると便利です。 しかし、HTTP と HTTPS のページでは、ブラウザの動作の仕方が微妙に違います。 主な違いは、HTTPS のページでは、HTTP の URL から JavaScript をロードするリクエストがブロックされるという点です。 そのため、HTTP を使ってローカルで開発をする場合、ある script タグが開発用のマシンでは正しく動作するにもかかわらず、HTTPS の本番のサイト環境にデプロイすると不具合が発生するということがありえます。 この種の問題を捉えるには、ローカルのウェブサーバーで HTTPS のセットアップを行うと役に立ちます。 しかし、証明書の警告を毎回見たくはないと思います。 それでは、ローカルでもブラウザ上で緑の鍵マークが見られるように設定するには、どのようにすればよいのでしょうか？ +ウェブアプリを開発している場合、Apache や Nginx などのローカルのウェブサーバーを実行して、そのウェブアプリにはウェブブラウザから `http://localhost:8000/` でアクセスできるようにすると便利です。しかし、HTTP と HTTPS のページでは、ブラウザの動作の仕方が微妙に違います。主な違いは、HTTPS のページでは、HTTP の URL から JavaScript をロードするリクエストがブロックされるという点です。そのため、HTTP を使ってローカルで開発をする場合、ある script タグが開発用のマシンでは正しく動作するにもかかわらず、HTTPS の本番のサイト環境にデプロイすると不具合が発生するということがありえます。この種の問題を捉えるには、ローカルのウェブサーバーで HTTPS のセットアップを行うと役に立ちます。しかし、証明書の警告を毎回見たくはないと思います。それでは、ローカルでもブラウザ上で緑の鍵マークが見られるように設定するには、どのようにすればよいのでしょうか？ -最善の選択は、自分で証明書を発行し、それに自己署名またはローカル環境のルートで署名を行い、オペレーティングシステムのトラストストアでその証明書を信頼する、という方法です。 そして、その証明書をローカルのウェブサーバーで使います。 詳しくは、以下の各セクションを読んでください。 +最善の選択は、自分で証明書を発行し、それに自己署名またはローカル環境のルートで署名を行い、オペレーティングシステムのトラストストアでその証明書を信頼する、という方法です。そして、その証明書をローカルのウェブサーバーで使います。詳しくは、以下の各セクションを読んでください。 # ウェブアプリと通信するネイティブアプリのための証明書 -開発者は、ダウンロード可能なネイティブアプリを提供して、ウェブサイトとともに追加機能を提供したい場合があります。 たとえば、Dropbox や Spotify のデスクトップアプリは、マシン上のファイルをスキャンできますが、このような動作はウェブアプリでは可能ではありません。 このようなネイティブアプリでよくあるアプローチの1つは、localhost でウェブサーバーを起動し、ウェブアプリからはそのサーバーに XMLHttpRequest (XHR) または WebSocket でリクエストを送るという方法です。 ほとんどのウェブアプリは常に HTTPS を使用します。つまり、ブラウザーはセキュアではない URL に XHR や WebSocket のリクエストを送ることを禁止します。 このようなリクエストのブロックを、混合コンテンツブロック (Mixed Content Blocking) と呼びます。 ウェブアプリと通信できるようにするには、ネイティブアプリがセキュアなウェブサーバーを提供する必要があります。 +開発者は、ダウンロード可能なネイティブアプリを提供して、ウェブサイトとともに追加機能を提供したい場合があります。たとえば、Dropbox や Spotify のデスクトップアプリは、マシン上のファイルをスキャンできますが、このような動作はウェブアプリでは可能ではありません。このようなネイティブアプリでよくあるアプローチの1つは、localhost でウェブサーバーを起動し、ウェブアプリからはそのサーバーに XMLHttpRequest (XHR) または WebSocket でリクエストを送るという方法です。ほとんどのウェブアプリは常に HTTPS を使用します。つまり、ブラウザーはセキュアではない URL に XHR や WebSocket のリクエストを送ることを禁止します。このようなリクエストのブロックを、混合コンテンツブロック (Mixed Content Blocking) と呼びます。ウェブアプリと通信できるようにするには、ネイティブアプリがセキュアなウェブサーバーを提供する必要があります。 -幸い、モダンなウェブブラウザは `http://127.0.0.1:8000/` を [「潜在的に信頼することができる」][secure-contexts]URL であると[見做してくれます][mcb-localhost]。この URL はループバックアドレスを指すためです。 `127.0.0.1` に送られたトラフィックは、マシンの外部に送られないことが保証されているため、ネットワークの傍受に対して安全であることが自明だとみなされます。 つまり、ウェブアプリが HTTPS を使い、ネイティブアプリのウェブサービスが `127.0.0.1` でウェブサービスを提供する場合、XHR による2者間の通信はめでたく成功するということです。 残念ながら、[localhost という名前は、まだ同じようには扱われません][let-localhost]。 また、WebSocket にはいずれの名前に対しても同様の扱いはありません。 +幸い、モダンなウェブブラウザは `http://127.0.0.1:8000/` を [「潜在的に信頼することができる」][secure-contexts]URL であると[見做してくれます][mcb-localhost]。この URL はループバックアドレスを指すためです。 `127.0.0.1` に送られたトラフィックは、マシンの外部に送られないことが保証されているため、ネットワークの傍受に対して安全であることが自明だとみなされます。つまり、ウェブアプリが HTTPS を使い、ネイティブアプリのウェブサービスが `127.0.0.1` でウェブサービスを提供する場合、XHR による2者間の通信はめでたく成功するということです。残念ながら、[localhost という名前は、まだ同じようには扱われません][let-localhost]。また、WebSocket にはいずれの名前に対しても同様の扱いはありません。 -この制限を回避するために、グローバルの DNS に `127.0.0.1` に解決するドメイン名 (たとえば、`localhost.example.com`) をセットアップして、そのドメイン名に対する証明書を取得し、その証明書を対応する秘密鍵と一緒にネイティブアプリに含めて配布したあと、ウェブアプリが `http://127.0.0.1:8000/` の代わりに `https://localhost.example.com:8000/` と通信するように設定しようとするかもしれません。 *このようなことは絶対にしてはいけません。*ユーザーをリスクに晒すことになるため、署名書が取り消される可能性があります。 +この制限を回避するために、グローバルの DNS に `127.0.0.1` に解決するドメイン名 (たとえば、`localhost.example.com`) をセットアップして、そのドメイン名に対する証明書を取得し、その証明書を対応する秘密鍵と一緒にネイティブアプリに含めて配布したあと、ウェブアプリが `http://127.0.0.1:8000/` の代わりに `https://localhost.example.com:8000/` と通信するように設定しようとするかもしれません。*このようなことは絶対にしてはいけません。*ユーザーをリスクに晒すことになるため、署名書が取り消される可能性があります。 -IP アドレスの代わりにドメイン名を導入してしまうと、攻撃者が DNS ルックアップに対して中間者攻撃 (Man in the Middle; MitM) して、別の IP アドレスを指すレスポンスを挿入することを可能にしてしまいます。 攻撃者はローカルアプリのふりをして、偽のレスポンスをウェブアプリに送り返すことができます。これにより、実装の仕方によっては、ウェブアプリ側のあなたのアカウントが偽装されることもあります。 +IP アドレスの代わりにドメイン名を導入してしまうと、攻撃者が DNS ルックアップに対して中間者攻撃 (Man in the Middle; MitM) して、別の IP アドレスを指すレスポンスを挿入することを可能にしてしまいます。攻撃者はローカルアプリのふりをして、偽のレスポンスをウェブアプリに送り返すことができます。これにより、実装の仕方によっては、ウェブアプリ側のあなたのアカウントが偽装されることもあります。 -このような場合、アプリが正しく動作するためには証明書の秘密鍵をネイティブアプリ内に同梱することが不可欠であるため、中間者攻撃が成功する可能性があります。 つまり、ネイティブアプリをダウンロードすれば、攻撃者を含む誰もが秘密鍵のコピーを取得できてしまうからです。 これは秘密鍵が流出している状況と見做せるため、認証局 (CA) がこのことを検出した場合には、証明書を無効化する必要があります。 [多くのネイティブアプリ][mdsp1]で、[秘密鍵を含めて配布したこと][mdsp3]が原因で[アプリの証明書][mdsp2]が無効化されています。 +このような場合、アプリが正しく動作するためには証明書の秘密鍵をネイティブアプリ内に同梱することが不可欠であるため、中間者攻撃が成功する可能性があります。つまり、ネイティブアプリをダウンロードすれば、攻撃者を含む誰もが秘密鍵のコピーを取得できてしまうからです。これは秘密鍵が流出している状況と見做せるため、認証局 (CA) がこのことを検出した場合には、証明書を無効化する必要があります。[多くのネイティブアプリ][mdsp1]で、[秘密鍵を含めて配布したこと][mdsp3]が原因で[アプリの証明書][mdsp2]が無効化されています。 -残念ながら、この方法では、多くの優れたセキュアなオプションなしでネイティブアプリが対応するウェブサイトと通信することになってしまします。 ブラウザがさらに[ウェブから localhost へのアクセス制限を強化][tighten-access]した場合、将来の状況はさらに面倒になる可能性があります。 +残念ながら、この方法では、多くの優れたセキュアなオプションなしでネイティブアプリが対応するウェブサイトと通信することになってしまします。ブラウザがさらに[ウェブから localhost へのアクセス制限を強化][tighten-access]した場合、将来の状況はさらに面倒になる可能性があります。 -また、特権を持つネイティブの API を提供するウェブサービスを公開することも本質的にリスクがあることにも注意が必要です。権限を与えるつもりのないウェブサイトからのアクセスを許してしまう可能性があるからです。 それでもこの方法を使いたい場合は、[Cross-Origin Resource Sharing][cors] を熟読して、Access-Control-Allow-Origin を利用し、メモリセーフな HTTP パーサーを使用してください。アクセスを許可していないオリジンからでも preflight request を送信することが可能でああるため、パーサーのバグを悪用できてしまう可能性があるからです。 +また、特権を持つネイティブの API を提供するウェブサービスを公開することも本質的にリスクがあることにも注意が必要です。権限を与えるつもりのないウェブサイトからのアクセスを許してしまう可能性があるからです。それでもこの方法を使いたい場合は、[Cross-Origin Resource Sharing][cors] を熟読して、Access-Control-Allow-Origin を利用し、メモリセーフな HTTP パーサーを使用してください。アクセスを許可していないオリジンからでも preflight request を送信することが可能でああるため、パーサーのバグを悪用できてしまう可能性があるからです。 # 自分の証明書を作成して信頼する -CA の助けを借りなくても、誰でも自分の証明書を作ることができます。 唯一の違いは、自分で作った証明書は、他の誰からも信頼されないということです。 それでも、ローカルの開発の場合は十分です。 +CA の助けを借りなくても、誰でも自分の証明書を作ることができます。唯一の違いは、自分で作った証明書は、他の誰からも信頼されないということです。それでも、ローカルの開発の場合は十分です。 localhost の秘密鍵と自己署名証明書を生成する最も簡単な方法は、次のような openssl のコマンドを実行することです。 @@ -42,9 +42,9 @@ localhost の秘密鍵と自己署名証明書を生成する最も簡単な方 その後、localhost.crt と localhost.key を使ってローカルのウェブサーバーを設定し、localhost.crt をローカルのトラストルートのリストにインストールできます。 -開発用の証明書をより現実的に管理したい場合、[ mkcert ][mkcert] を使うことができます。mkcert を使うと、ローカルのルート証明書を生成して、end-entity (または leaf) 証明書をそのルート証明書で署名することができます。 そして、自己署名の end-entity 証明書ではなく、ルート証明書をインポートします。 +開発用の証明書をより現実的に管理したい場合、[ mkcert ][mkcert] を使うことができます。mkcert を使うと、ローカルのルート証明書を生成して、end-entity (または leaf) 証明書をそのルート証明書で署名することができます。そして、自己署名の end-entity 証明書ではなく、ルート証明書をインポートします。 -`127.0.0.1` へのエイリアスとして /etc/hosts を追加すれば、`www.localhost` のようなドットを含むドメインを使うこともできます。 この方法を採用した場合、ブラウザの cookie storage の扱い方が微妙に変わります。 +`127.0.0.1` へのエイリアスとして /etc/hosts を追加すれば、`www.localhost` のようなドットを含むドメインを使うこともできます。この方法を採用した場合、ブラウザの cookie storage の扱い方が微妙に変わります。 [mcb-localhost]: https://bugs.chromium.org/p/chromium/issues/detail?id=607878 [secure-contexts]: https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy diff --git a/content/ja/thankyou.md b/content/ja/thankyou.md index 1081291340..d2f8803365 100644 --- a/content/ja/thankyou.md +++ b/content/ja/thankyou.md @@ -7,9 +7,9 @@ lastmod: 2022-12-02

あなたの寄付に感謝いたします

ISRG の全員を代表して、私たちの活動をサポートしていただき、どうもありがとうございます。

-

寄付に関する領収書は提供されたメールアドレスへ送信されました。 Internet Security Research Group は 501(c)(3) で定められた非営利公共団体です。 私たち公益法人の雇用者識別番号 (EIN) は 46-3344200 です。

+

寄付に関する領収書は提供されたメールアドレスへ送信されました。 Internet Security Research Group は 501(c)(3) で定められた非営利公共団体です。私たち公益法人の雇用者識別番号 (EIN) は 46-3344200 です。

寄付を2倍に増額する

-

多くの組織では、従業員による非営利団体への寄付に対してマッチングを行っています。 あなたが所属する組織にマッチングプログラムがあるかどうかを確認して、寄付のインパクトを2倍に増やしましょう！

+

多くの組織では、従業員による非営利団体への寄付に対してマッチングを行っています。あなたが所属する組織にマッチングプログラムがあるかどうかを確認して、寄付のインパクトを2倍に増やしましょう！

{{< double_donation >}}
diff --git a/content/ru/docs/faq.md b/content/ru/docs/faq.md index f6619c346a..757c6de55f 100644 --- a/content/ru/docs/faq.md +++ b/content/ru/docs/faq.md @@ -44,7 +44,7 @@ Let's Encrypt — небольшая компания, мы полагаемся ## Сайт с сертификатом Let's Encrypt используется для фишинга/вредоносного ПО/мошенничества/..., что мне делать? -Мы рекомендуем сообщить об этом в Google Safe Browsing и Microsoft Smart Screen, которые способны эффективно защищать пользователей Интернета. URL-адреса для отчетов: +Мы рекомендуем сообщить об этом в Google Safe Browsing и Microsoft SmartScreen, которые способны эффективно защищать пользователей Интернета. URL-адреса для отчетов: - [https://safebrowsing.google.com/safebrowsing/report_badware/](https://safebrowsing.google.com/safebrowsing/report_badware/) - [https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site-guest](https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site-guest) diff --git a/content/sv/docs/glossary.md b/content/sv/docs/glossary.md index 217eb2d282..79effc1c70 100644 --- a/content/sv/docs/glossary.md +++ b/content/sv/docs/glossary.md @@ -1,7 +1,7 @@ --- title: Ordlista slug: glossary -lastmod: 2026-09-08 +lastmod: 2026-10-04 show_lastmod: 1 description: "En ordlista med termer relaterade till SSL/TLS-certifikat, HTTPS och webbsäkerhet som används av Let's Encrypt." --- diff --git a/content/sv/docs/profiles.md b/content/sv/docs/profiles.md index 6e3283a22e..992cb7dfe9 100644 --- a/content/sv/docs/profiles.md +++ b/content/sv/docs/profiles.md @@ -1,7 +1,7 @@ --- title: Profiler slug: profiles -lastmod: 2026-09-08 +lastmod: 2026-10-04 show_lastmod: false --- diff --git a/content/zh-cn/about.md b/content/zh-cn/about.md index 1cbee4b404..53c219f09a 100644 --- a/content/zh-cn/about.md +++ b/content/zh-cn/about.md @@ -9,9 +9,9 @@ menu: parent: about --- -Let's Encrypt 是一家免费、开放、自动化的公益性证书颁发机构 (CA)， 由[互联网安全研究组](https://www.abetterinternet.org/) (ISRG) 运作。 +Let's Encrypt 是一家免费、开放、自动化的公益性证书颁发机构 (CA)，由[互联网安全研究组](https://www.abetterinternet.org/) (ISRG) 运作。 -我们以尽可能对用户友好的方式免费提供数字证书，助力各类网站启用 HTTPS (SSL/TLS)。 这是因为我们想要创建一个更安全，更尊重隐私的 Web 环境。 +我们以尽可能对用户友好的方式免费提供数字证书，助力各类网站启用 HTTPS (SSL/TLS)。这是因为我们想要创建一个更安全，更尊重隐私的 Web 环境。 您可以下载我们的[年度报告](https://www.abetterinternet.org/annual-reports/)回顾我们最近一年的工作成果。 diff --git a/content/zh-cn/certificates.md b/content/zh-cn/certificates.md index 1c5735dd3c..b61cd76b04 100644 --- a/content/zh-cn/certificates.md +++ b/content/zh-cn/certificates.md @@ -6,15 +6,15 @@ lastmod: 2026-07-08 show_lastmod: 1 --- -本页面描述了 Let's Encrypt 过往及当前运作的所有证书颁发机构 (CA)。 所谓的 CA 应当理解为一组名称和密钥：一家 CA 可以由 _很多_ 证书表示，只要所有证书的主体和公钥信息相同即可。 对于这种情形，我们也提供了 CA 对应的所有证书的详细信息。 如果您需要查询下列 CA 对应的信任锚点 ID，请参见[对象标识符](/docs/oids)。 +本页面描述了 Let's Encrypt 过往及当前运作的所有证书颁发机构 (CA)。所谓的 CA 应当理解为一组名称和密钥：一家 CA 可以由 _很多_ 证书表示，只要所有证书的主体和公钥信息相同即可。对于这种情形，我们也提供了 CA 对应的所有证书的详细信息。如果您需要查询下列 CA 对应的信任锚点 ID，请参见[对象标识符](/docs/oids)。 [![2026 年 7 月起的 ISRG 证书层级图示](/images/isrg-hierarchy.png)](/images/isrg-hierarchy-full.png) # 根证书颁发机构 -我们的根证书密钥是在安全的地点离线存储的， 而提供给用户的最终实体证书都是由下一节介绍的中间证书签发。 +我们的根证书密钥是在安全的地点离线存储的，而提供给用户的最终实体证书都是由下一节介绍的中间证书签发。 -需要注意的是，根证书的有效期限和其他证书有所不同。 作为一种自签名证书，根证书也有 `notAfter` 截止日期，但各类根证书项目和证书库可以选择延长或提前终止对根证书的信任。 因此，下列证书有效期限仅为依据各根证书项目的现行政策所作的预估。 +需要注意的是，根证书的有效期限和其他证书有所不同。作为一种自签名证书，根证书也有 `notAfter` 截止日期，但各类根证书项目和证书库可以选择延长或提前终止对根证书的信任。因此，下列证书有效期限仅为依据各根证书项目的现行政策所作的预估。 * **ISRG Root X1** * 主体：`C=US, O=Internet Security Research Group, CN=ISRG Root X1` @@ -60,7 +60,7 @@ show_lastmod: 1 # 中间证书颁发机构 -我们目前有四份中间证书供轮转使用。 包含 ECDSA 公钥的用户证书由其中一份 ECDSA 中间证书签发，包含 RSA 公钥的用户证书则由其中一份 RSA 中间证书签发。 +我们目前有四份中间证书供轮转使用。包含 ECDSA 公钥的用户证书由其中一份 ECDSA 中间证书签发，包含 RSA 公钥的用户证书则由其中一份 RSA 中间证书签发。 * **Let's Encrypt YE1** * 主体：`C=US, O=Let's Encrypt, CN=YE1` @@ -110,7 +110,7 @@ show_lastmod: 1
备用证书 -这些中间证书已经生效，但尚未用于签发其他证书。 我们随时可能在无预先告知的情况下将下列证书用于签发流程。 +这些中间证书已经生效，但尚未用于签发其他证书。我们随时可能在无预先告知的情况下将下列证书用于签发流程。 * **Let's Encrypt YE3** * 主体：`C=US, O=Let's Encrypt, CN=YE3` @@ -132,7 +132,7 @@ show_lastmod: 1
已不再使用的证书 -这些中间证书已不再用于签发用户证书， 但仍有可能产生 CRL，直至其过去签发的所有证书全部过期。 +这些中间证书已不再用于签发用户证书，但仍有可能产生 CRL，直至其过去签发的所有证书全部过期。 * **Let's Encrypt E5** * 主体：`C=US, O=Let's Encrypt, CN=E5` @@ -282,10 +282,10 @@ show_lastmod: 1 # 证书链 -ACME 客户端通过 Let's Encrypt 的 ACME 接口下载的新证书实际上是“证书链”的一部分，这条链中还包含若干份中间证书。 一般情况下，证书链中只有最终实体证书和一份中间证书，但中间证书也可以有多份。 这样设计的意图在于，只要把这一整条证书链提供给网站访客的浏览器，浏览器就能顺着这条链逐一验证数字签名，直至找到其信任的根证书，全程不需要再下载其他的中间证书。 +ACME 客户端通过 Let's Encrypt 的 ACME 接口下载的新证书实际上是“证书链”的一部分，这条链中还包含若干份中间证书。一般情况下，证书链中只有最终实体证书和一份中间证书，但中间证书也可以有多份。这样设计的意图在于，只要把这一整条证书链提供给网站访客的浏览器，浏览器就能顺着这条链逐一验证数字签名，直至找到其信任的根证书，全程不需要再下载其他的中间证书。 -一份证书还可能有多条证书链。例如，当中间证书存在交叉签名时，任选其一均可形成证书链，并最终到达各自的根证书。 在这种情况下，各网站可以根据需要选择使用不同的证书链。 +一份证书还可能有多条证书链。例如，当中间证书存在交叉签名时，任选其一均可形成证书链，并最终到达各自的根证书。在这种情况下，各网站可以根据需要选择使用不同的证书链。 -上述正在使用的各中间证书都注明了其默认提供的证书链，以及是否有其他证书链可供 ACME 客户端选择。 一般而言，从 ISRG Root X1 延伸出的证书链数据量最大，但对于老旧客户端的兼容性也最好。 从 ISRG Root X2 延伸出的证书链（仅对 ECDSA 证书提供）较小，但只有在 2022 年以后更新过证书库的客户端才有可能支持。 从 Root YE 或 Root YR 延伸出的证书链则不能直接使用，因为其根证书尚未被各大可信证书库收录。 +上述正在使用的各中间证书都注明了其默认提供的证书链，以及是否有其他证书链可供 ACME 客户端选择。一般而言，从 ISRG Root X1 延伸出的证书链数据量最大，但对于老旧客户端的兼容性也最好。从 ISRG Root X2 延伸出的证书链（仅对 ECDSA 证书提供）较小，但只有在 2022 年以后更新过证书库的客户端才有可能支持。从 Root YE 或 Root YR 延伸出的证书链则不能直接使用，因为其根证书尚未被各大可信证书库收录。 想要使用非默认证书链的用户可以查阅其 ACME 客户端的文档了解如何设置证书链（例如使用 [Certbot 的 `--preferred-chain` 选项](https://eff-certbot.readthedocs.io/en/stable/using.html#certbot-command-line-options)）。 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 da464e400f..9a92118d67 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 @@ -4,9 +4,9 @@ slug: a-warm-welcome-to-asn1-and-der lastmod: 2021-03-21 --- -本文以轻松的笔触介绍了 HTTPS 证书背后的数据结构和格式， 只要稍有计算机科学知识并对数字证书略知一二就不难理解。 +本文以轻松的笔触介绍了 HTTPS 证书背后的数据结构和格式，只要稍有计算机科学知识并对数字证书略知一二就不难理解。 -HTTPS 证书是一种文件，与任何其他文件一样。 它的具体格式是由 [RFC 5280](https://tools.ietf.org/html/rfc5280) 规定的， 该标准采用了一门名为 ASN.1 的语言，专门用于定义文件格式，也可以说是定义数据结构。 譬如，C 语言是这样定义数据结构的： +HTTPS 证书是一种文件，与任何其他文件一样。它的具体格式是由 [RFC 5280](https://tools.ietf.org/html/rfc5280) 规定的，该标准采用了一门名为 ASN.1 的语言，专门用于定义文件格式，也可以说是定义数据结构。譬如，C 语言是这样定义数据结构的： ```c struct point { @@ -34,19 +34,19 @@ Point ::= SEQUENCE { } ``` -与 Go 和 C 的语法相比，ASN.1 的优势在于它不依赖某一门特定的编程语言， 任何语言都可以根据上述 ASN.1 定义实现 Point 结构。不仅如此，借助工具还可以将 ASN.1 定义自动转换成你想使用的语言。 在 ASN.1 中，一系列相关的定义称为一个“[模块](https://www.obj-sys.com/asn1tutorial/node6.html)”。 +与 Go 和 C 的语法相比，ASN.1 的优势在于它不依赖某一门特定的编程语言，任何语言都可以根据上述 ASN.1 定义实现 Point 结构。不仅如此，借助工具还可以将 ASN.1 定义自动转换成你想使用的语言。在 ASN.1 中，一系列相关的定义称为一个“[模块](https://www.obj-sys.com/asn1tutorial/node6.html)”。 -ASN.1 的另一特点在于它有各种序列化格式，也就是说数据可以从内存导出成一串字节（或存入文件中），也可以由一串字节反过来导入内存。 因此任何一台设备生成的证书其他设备都能正常读取，无需顾忌 CPU 和操作系统的差异。 +ASN.1 的另一特点在于它有各种序列化格式，也就是说数据可以从内存导出成一串字节（或存入文件中），也可以由一串字节反过来导入内存。因此任何一台设备生成的证书其他设备都能正常读取，无需顾忌 CPU 和操作系统的差异。 -还有一些语言也能起到与 ASN.1 [同样的作用](https://en.wikipedia.org/wiki/Interface_description_language)。 例如，Protocol Buffers 也提供了一门定义类型的[语言](https://developers.google.com/protocol-buffers/docs/proto3)，以及负责将各类对象编码的[序列化格式](https://developers.google.com/protocol-buffers/docs/encoding)。 [Thrift](https://thrift.apache.org/) 同样具备类似的语言和序列化格式。 Protocol Buffers 和 Thrift 完全可以胜任定义 HTTPS 证书的职责，只不过 ASN.1 早在 1984 年就已诞生，对于数字证书（1988 年）和 HTTPS（1994 年）技术来说具备先天优势。 +还有一些语言也能起到与 ASN.1 [同样的作用](https://en.wikipedia.org/wiki/Interface_description_language)。例如，Protocol Buffers 也提供了一门定义类型的[语言](https://developers.google.com/protocol-buffers/docs/proto3)，以及负责将各类对象编码的[序列化格式](https://developers.google.com/protocol-buffers/docs/encoding)。 [Thrift](https://thrift.apache.org/) 同样具备类似的语言和序列化格式。 Protocol Buffers 和 Thrift 完全可以胜任定义 HTTPS 证书的职责，只不过 ASN.1 早在 1984 年就已诞生，对于数字证书（1988 年）和 HTTPS（1994 年）技术来说具备先天优势。 -多年来 ASN.1 标准几经修订，各修订版本通常以发布年份加以区分。 本文介绍 ASN.1 旨在帮助读者准确理解 RFC 5280 及其他 HTTPS 证书相关标准，所以我们将着重探讨 1988 年版，并简要提及后续版本引入的功能。 各版本的标准文档可以直接在国际电信联盟 (ITU) 的网站上下载，不过部分文件只对 ITU 成员开放。 相关标准包括 [X.680](https://www.itu.int/rec/T-REC-X.680)（定义了 ASN.1 语言）和 [X.690](https://www.itu.int/rec/T-REC-X.690)（定义了 DER 和 BER 序列化格式）， 其前身分别是 [X.208](https://www.itu.int/rec/T-REC-X.208/en) 与 [X.209](https://www.itu.int/rec/T-REC-X.209/en)。 +多年来 ASN.1 标准几经修订，各修订版本通常以发布年份加以区分。本文介绍 ASN.1 旨在帮助读者准确理解 RFC 5280 及其他 HTTPS 证书相关标准，所以我们将着重探讨 1988 年版，并简要提及后续版本引入的功能。各版本的标准文档可以直接在国际电信联盟 (ITU) 的网站上下载，不过部分文件只对 ITU 成员开放。相关标准包括 [X.680](https://www.itu.int/rec/T-REC-X.680)（定义了 ASN.1 语言）和 [X.690](https://www.itu.int/rec/T-REC-X.690)（定义了 DER 和 BER 序列化格式），其前身分别是 [X.208](https://www.itu.int/rec/T-REC-X.208/en) 与 [X.209](https://www.itu.int/rec/T-REC-X.209/en)。 -ASN.1 最主要的序列化格式称为 Distinguished Encoding Rules (DER)。 它是对 Basic Encoding Rules (BER) 格式加以严格规范化而成的一种变体。 例如，在 DER 格式中，即使是集合类型 (SET OF) 的元素也必须有序排列。 +ASN.1 最主要的序列化格式称为 Distinguished Encoding Rules (DER)。它是对 Basic Encoding Rules (BER) 格式加以严格规范化而成的一种变体。例如，在 DER 格式中，即使是集合类型 (SET OF) 的元素也必须有序排列。 DER 格式的证书通常会进一步转换成 PEM 格式，这一过程采用 [Base64](https://en.wikipedia.org/wiki/Base64) 编码将二进制字节转化为一连串的字母、数字、“+”和“/”符号，并在头尾加入“\-\-\-\--BEGIN CERTIFICATE\-\-\-\--”与“\-\-\-\--END CERTIFICATE\-\-\-\--”两行文字以示分隔。 PEM 格式的优点在于方便复制与粘贴。 -本文将首先介绍 ASN.1 使用的类型与语法，然后再介绍 ASN.1 定义的对象是如何编码的。 读者不妨随时翻阅前后章节，毕竟 ASN.1 语言的部分功能直接决定了其编码方式。 本文倾向使用更为通行的术语，如用“字节”而非“八位组”，用“数值”而非“内容”。 “序列化”与“编码”则作为同义词使用。 +本文将首先介绍 ASN.1 使用的类型与语法，然后再介绍 ASN.1 定义的对象是如何编码的。读者不妨随时翻阅前后章节，毕竟 ASN.1 语言的部分功能直接决定了其编码方式。本文倾向使用更为通行的术语，如用“字节”而非“八位组”，用“数值”而非“内容”。“序列化”与“编码”则作为同义词使用。 类型 ========= @@ -54,48 +54,48 @@ 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 对字段长度没有限制。 字符串 ------- -ASN.1 有很多字符串类型：BMPString、GeneralString、GraphicString、IA5String、ISO646String、NumericString、PrintableString、TeletexString、T61String、UniversalString、UTF8String、VideotexString，还有 VisibleString。 对于 HTTPS 证书来说基本只需要关心 PrintableString、UTF8String 和 [IA5String](https://en.wikipedia.org/wiki/IA5STRING)。 ASN.1 模块定义字段的时候也会定义其应当使用的字符串类型。 [例如](https://tools.ietf.org/html/rfc5280#page-127)： +ASN.1 有很多字符串类型：BMPString、GeneralString、GraphicString、IA5String、ISO646String、NumericString、PrintableString、TeletexString、T61String、UniversalString、UTF8String、VideotexString，还有 VisibleString。对于 HTTPS 证书来说基本只需要关心 PrintableString、UTF8String 和 [IA5String](https://en.wikipedia.org/wiki/IA5STRING)。 ASN.1 模块定义字段的时候也会定义其应当使用的字符串类型。[例如](https://tools.ietf.org/html/rfc5280#page-127)： ``` CPSuri ::= IA5String ``` -PrintableString 只能存储 ASCII 中的部分字符，包括字母、数字、空格以及一些特定的符号：`' () + , - . / : = ?`。 注意其中不包括 `*` 和 `@`。 虽然允许使用的字符有限，但在存储空间上并无优势。 +PrintableString 只能存储 ASCII 中的部分字符，包括字母、数字、空格以及一些特定的符号：`' () + , - . / : = ?`。注意其中不包括 `*` 和 `@`。虽然允许使用的字符有限，但在存储空间上并无优势。 -某些字段，例如 [RFC 5280 中的 DirectoryString](https://tools.ietf.org/html/rfc5280#page-20)，有多种字符串类型可供选择。 由于 DER 编码会将字符串的类型信息一并存储，使用 PrintableString 这类字符串时务必确保其内容[符合类型要求](https://community.letsencrypt.org/t/2018-03-12-wildcard-certificate-encoding-issue/55485)。 +某些字段，例如 [RFC 5280 中的 DirectoryString](https://tools.ietf.org/html/rfc5280#page-20)，有多种字符串类型可供选择。由于 DER 编码会将字符串的类型信息一并存储，使用 PrintableString 这类字符串时务必确保其内容[符合类型要求](https://community.letsencrypt.org/t/2018-03-12-wildcard-certificate-encoding-issue/55485)。 -IA5String 源自 [International Alphabet No. 5](https://en.wikipedia.org/wiki/T.50_(standard))，限制较为宽松，所有 ASCII 字符几乎都能使用，在证书中常用于邮箱地址、DNS 域名、网址之类的字段。 需要注意的是 IA5 编码中有部分数值的含义与 US-ASCII 并不相同。 +IA5String 源自 [International Alphabet No. 5](https://en.wikipedia.org/wiki/T.50_(standard))，限制较为宽松，所有 ASCII 字符几乎都能使用，在证书中常用于邮箱地址、DNS 域名、网址之类的字段。需要注意的是 IA5 编码中有部分数值的含义与 US-ASCII 并不相同。 TeletexString、BMPString 和 UniversalString 对 HTTPS 证书来说都已过时，建议不再使用。但一些历史悠久的证书可能在其过时之前就已颁布，因此还能发现它们的身影，需要予以解析。 -与 C 和 C++ 语言中的字符串不同，ASN.1 的字符串不以空字符结尾。 事实上，字符串中出现空字符也是完全符合规范的。 如果两套系统采取不同方式读取同一 ASN.1 字符串，就可能出现安全漏洞。 例如，过去攻击者只要持有 evil.com 域名，就能[诱使某些证书颁发机构](https://www.theregister.co.uk/2009/07/30/universal_ssl_certificate/)为“example.com\\0.evil.com”颁发证书。 当时的证书验证软件会认为这一证书对 example.com 也是有效的。 在 C 和 C++ 中处理 ASN.1 字符串必须加倍小心，避免产生安全漏洞。 +与 C 和 C++ 语言中的字符串不同，ASN.1 的字符串不以空字符结尾。事实上，字符串中出现空字符也是完全符合规范的。如果两套系统采取不同方式读取同一 ASN.1 字符串，就可能出现安全漏洞。例如，过去攻击者只要持有 evil.com 域名，就能[诱使某些证书颁发机构](https://www.theregister.co.uk/2009/07/30/universal_ssl_certificate/)为“example.com\\0.evil.com”颁发证书。当时的证书验证软件会认为这一证书对 example.com 也是有效的。在 C 和 C++ 中处理 ASN.1 字符串必须加倍小心，避免产生安全漏洞。 日期和时间 --------------- -时间类型也有不少：UTCTime、GeneralizedTime、DATE、TIME-OF-DAY、DATE-TIME 以及 DURATION。 但在 HTTPS 证书中只需关心 UTCTime 和 GeneralizedTime。 +时间类型也有不少：UTCTime、GeneralizedTime、DATE、TIME-OF-DAY、DATE-TIME 以及 DURATION。但在 HTTPS 证书中只需关心 UTCTime 和 GeneralizedTime。 -UTCTime 采用 YYMMDDhhmm[ss] 的格式表示日期和时间，末尾还可以加上时区，或者加上“Z”表示协调世界时 (UTC)。 例如，UTCTime 的 820102120000Z 和 820102070000-0500 表示同一时刻：1982 年 1 月 2 日纽约 (UTC−5) 的早晨七点，即协调世界时的正午十二点。 +UTCTime 采用 YYMMDDhhmm[ss] 的格式表示日期和时间，末尾还可以加上时区，或者加上“Z”表示协调世界时 (UTC)。例如，UTCTime 的 820102120000Z 和 820102070000-0500 表示同一时刻：1982 年 1 月 2 日纽约 (UTC−5) 的早晨七点，即协调世界时的正午十二点。 因为 UTCTime 没有写明是 20 世纪还是 21 世纪，[RFC 5280](https://tools.ietf.org/html/rfc5280#section-4.1.2.5.1) 补充规定了其范围是 1950 至 2050 年。 RFC 5280 还规定时区必须为“Z”，且秒数不能省略。 -GeneralizedTime 用四位数字表示年份，从而得以支持 2050 年以后的日期。 它还允许秒数出现小数（而且句点和逗号竟然都可以作为小数点）。 RFC 5280 又禁止了秒数出现小数，并要求时区为“Z”。 +GeneralizedTime 用四位数字表示年份，从而得以支持 2050 年以后的日期。它还允许秒数出现小数（而且句点和逗号竟然都可以作为小数点）。 RFC 5280 又禁止了秒数出现小数，并要求时区为“Z”。 OBJECT IDENTIFIER ----------------- -Object identifier (OID) 是一种全球唯一的层状标识符，由一串整数组成。 它可以用来标识任何东西，但通常用于指代标准、算法、证书扩展、组织机构或政策文件。 例如 [1.2.840.113549](https://oid-base.com/get/1.2.840.113549) 表示的是 RSA 安全公司， 因此该公司有权分配以这一串数字开头的 OID，比如 [RFC 8017](https://tools.ietf.org/html/rfc8017#page-69) 定义的 [1.2.840.113549.1.1.11](https://oid-base.com/get/1.2.840.113549.1.1.11) 表示 sha256WithRSAEncryption。 +Object identifier (OID) 是一种全球唯一的层状标识符，由一串整数组成。它可以用来标识任何东西，但通常用于指代标准、算法、证书扩展、组织机构或政策文件。例如 [1.2.840.113549](https://oid-base.com/get/1.2.840.113549) 表示的是 RSA 安全公司，因此该公司有权分配以这一串数字开头的 OID，比如 [RFC 8017](https://tools.ietf.org/html/rfc8017#page-69) 定义的 [1.2.840.113549.1.1.11](https://oid-base.com/get/1.2.840.113549.1.1.11) 表示 sha256WithRSAEncryption。 类似地，[1.3.6.1.4.1.11129](https://oid-base.com/get/1.3.6.1.4.1.11129) 指的是 Google 公司，Google 则在 [RFC 6962](https://tools.ietf.org/html/rfc6962) 中将 [1.3.6.1.4.1.11129.2.4.2](https://oid-base.com/get/1.3.6.1.4.1.11129.2.4.2) 分配给了证书透明化系统中的 [SCT 列表扩展](https://letsencrypt.org/2018/04/04/sct-encoding.html)，因为该系统最初便是由 Google 研发的。 -同一前缀下的所有 OID 在英文中又称为 OID arc。 OID 越短，占据的空间就越小，价值也就越高，对于大量使用 OID 的格式尤为如此。 OID 前缀 [2.5](https://oid-base.com/get/2.5) 分配给了 Directory Services，指的是一系列的标准文档，在 HTTPS 证书中处于核心地位的 X.509 标准也位列其中。 证书中有很多字段用的都是这个简短的前缀。 例如，[2.5.4.6](https://oid-base.com/get/2.5.4.6) 表示国家名称 (countryName)，[2.5.4.10](https://oid-base.com/get/2.5.4.10) 则表示机构名称 (organizationName)。 这些 OID 在绝大多数证书中至少都会出现一次，自然越短越好。 +同一前缀下的所有 OID 在英文中又称为 OID arc。 OID 越短，占据的空间就越小，价值也就越高，对于大量使用 OID 的格式尤为如此。 OID 前缀 [2.5](https://oid-base.com/get/2.5) 分配给了 Directory Services，指的是一系列的标准文档，在 HTTPS 证书中处于核心地位的 X.509 标准也位列其中。证书中有很多字段用的都是这个简短的前缀。例如，[2.5.4.6](https://oid-base.com/get/2.5.4.6) 表示国家名称 (countryName)，[2.5.4.10](https://oid-base.com/get/2.5.4.10) 则表示机构名称 (organizationName)。这些 OID 在绝大多数证书中至少都会出现一次，自然越短越好。 -标准文件中的 OID 常用英文词汇表示以便阅读，有时还会拼接形成新的 OID。 [以 RFC 8017 为例](https://tools.ietf.org/html/rfc8017#page-68)： +标准文件中的 OID 常用英文词汇表示以便阅读，有时还会拼接形成新的 OID。[以 RFC 8017 为例](https://tools.ietf.org/html/rfc8017#page-68)： ```asn1 pkcs-1 OBJECT IDENTIFIER ::= { @@ -114,9 +114,9 @@ NULL 就是 NULL，懂了吧？ SEQUENCE 和 SEQUENCE OF ------------------------ -别被名字给骗了，这是两种截然不同的类型。 SEQUENCE 相当于大多数编程语言中的 struct 类型， 用于存放若干不同类型的固定字段。 参见[下文的证书示例](#bit-string-%E5%92%8C-octet-string)。 +别被名字给骗了，这是两种截然不同的类型。 SEQUENCE 相当于大多数编程语言中的 struct 类型，用于存放若干不同类型的固定字段。参见[下文的证书示例](#bit-string-%E5%92%8C-octet-string)。 -SEQUENCE OF 表示的则是任意数量同一类型的字段， 相当于编程语言中的数组或列表。 [例如](https://tools.ietf.org/html/rfc5280#page-116)： +SEQUENCE OF 表示的则是任意数量同一类型的字段，相当于编程语言中的数组或列表。[例如](https://tools.ietf.org/html/rfc5280#page-116)： ```asn1 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName @@ -124,12 +124,12 @@ SEQUENCE OF 表示的则是任意数量同一类型的字段， 相当于编程 可以是 0 个、1 个乃至 7000 个 RelativeDistinguishedName，并且按某种特定顺序排列。 -不过 SEQUENCE 和 SEQUENCE OF 还是有相似之处的：二者的编码完全相同！ 这一点留到探讨[编码](#sequence-%E7%9A%84%E7%BC%96%E7%A0%81)时再详细介绍。 +不过 SEQUENCE 和 SEQUENCE OF 还是有相似之处的：二者的编码完全相同！这一点留到探讨[编码](#sequence-%E7%9A%84%E7%BC%96%E7%A0%81)时再详细介绍。 SET 和 SET OF -------------- -这两种类型与 SEQUENCE 和 SEQUENCE OF 基本相同，只是强调其中元素的顺序无关紧要。 但是在编码前必须先予以排序。 [例如](https://tools.ietf.org/html/rfc5280#page-116)： +这两种类型与 SEQUENCE 和 SEQUENCE OF 基本相同，只是强调其中元素的顺序无关紧要。但是在编码前必须先予以排序。[例如](https://tools.ietf.org/html/rfc5280#page-116)： ```asn1 RelativeDistinguishedName ::= @@ -141,7 +141,7 @@ RelativeDistinguishedName ::= BIT STRING 和 OCTET STRING --------------------------- -前者表示一段任意的二进制位，而后者表示一段任意的字节。 这两种类型可以存放无特殊结构的数据，比如密码学中的 nonce 和散列值。 它们也可以当作 C 语言中的 void 指针或 Go 语言中的空接口 (interface{}) 使用，表示数据虽然存在内部结构，但该结构只在别处定义，与 ASN.1 的类型系统无关。 [例如](https://tools.ietf.org/html/rfc5280#page-116)，证书的数字签名就是用 BIT STRING 定义的： +前者表示一段任意的二进制位，而后者表示一段任意的字节。这两种类型可以存放无特殊结构的数据，比如密码学中的 nonce 和散列值。它们也可以当作 C 语言中的 void 指针或 Go 语言中的空接口 (interface{}) 使用，表示数据虽然存在内部结构，但该结构只在别处定义，与 ASN.1 的类型系统无关。[例如](https://tools.ietf.org/html/rfc5280#page-116)，证书的数字签名就是用 BIT STRING 定义的： ``` Certificate ::= SEQUENCE { @@ -155,7 +155,7 @@ Certificate ::= SEQUENCE { CHOICE 和 ANY -------------- -CHOICE 表示可以使用其定义中列出的任意一种类型。 [例如](https://tools.ietf.org/html/rfc5280#page-117)，下方的 Time 要么是 UTCTime，要么是 GeneralizedTime： +CHOICE 表示可以使用其定义中列出的任意一种类型。[例如](https://tools.ietf.org/html/rfc5280#page-117)，下方的 Time 要么是 UTCTime，要么是 GeneralizedTime： ```asn1 Time ::= CHOICE { @@ -163,7 +163,7 @@ Time ::= CHOICE { generalTime GeneralizedTime } ``` -ANY 表示允许使用任意类型。 但实际中通常还有一些 ASN.1 语法难以表达的限制。 [例如](https://tools.ietf.org/html/rfc5280#page-111)： +ANY 表示允许使用任意类型。但实际中通常还有一些 ASN.1 语法难以表达的限制。[例如](https://tools.ietf.org/html/rfc5280#page-111)： ```asn1 AttributeTypeAndValue ::= SEQUENCE { @@ -177,20 +177,20 @@ ANY 表示允许使用任意类型。 但实际中通常还有一些 ASN.1 语 ANY 在协议的扩展机制中扮演了重要的角色。它为将来新增字段留出了余地，协议的主体规范发布后不必反复修订，新字段只需注册新的类型（用 OID 表示），并随之定义具体的字段格式即可。 -需要注意的是 ANY 属于 ASN.1 从 1988 年遗留下来的类型。 [1994 年](https://www.itu.int/rec/T-REC-X.680-199407-S/en) ANY 就已经被废弃，取而代之的是 Information Object Class，这是一种规范化的扩展定义方式，弥补了 ANY 的不足。 现如今这一改变已经相当彻底，2015 年版的 ASN.1 标准甚至连 ANY 的字样都没有出现。 但是如果回过头看 1994 年版还是可以找到有关这一变动的探讨。 此处介绍这种旧式语法是因为 RFC 5280 仍在使用， [RFC 5912](https://tools.ietf.org/html/rfc5912) 则把 RFC 5280 及相关标准中的类型都转换成了 2002 年的 ASN.1 格式。 +需要注意的是 ANY 属于 ASN.1 从 1988 年遗留下来的类型。 [1994 年](https://www.itu.int/rec/T-REC-X.680-199407-S/en) ANY 就已经被废弃，取而代之的是 Information Object Class，这是一种规范化的扩展定义方式，弥补了 ANY 的不足。现如今这一改变已经相当彻底，2015 年版的 ASN.1 标准甚至连 ANY 的字样都没有出现。但是如果回过头看 1994 年版还是可以找到有关这一变动的探讨。此处介绍这种旧式语法是因为 RFC 5280 仍在使用， [RFC 5912](https://tools.ietf.org/html/rfc5912) 则把 RFC 5280 及相关标准中的类型都转换成了 2002 年的 ASN.1 格式。 其他语法 ============== -以 `--` 开头的文字是注释。 SEQUENCE 和 SET 类型的字段标注 OPTIONAL 表示可以省略，或者标注 DEFAULT foo 表示省略后的默认值为 foo。 具有长度的类型（字符串、OCTET STRING、BIT STRING、SET OF、SEQUENCE OF）可以通过 SIZE 参数限定长度必须在某一范围内或恰为某个数。 +以 `--` 开头的文字是注释。 SEQUENCE 和 SET 类型的字段标注 OPTIONAL 表示可以省略，或者标注 DEFAULT foo 表示省略后的默认值为 foo。具有长度的类型（字符串、OCTET STRING、BIT STRING、SET OF、SEQUENCE OF）可以通过 SIZE 参数限定长度必须在某一范围内或恰为某个数。 -类型定义结尾可以使用花括号限定该类型只能取某些值。 [例如此处定义](https://tools.ietf.org/html/rfc5280#page-117) Version 字段只能取三个值中的一个，并对这三个值分别赋予了含义： +类型定义结尾可以使用花括号限定该类型只能取某些值。[例如此处定义](https://tools.ietf.org/html/rfc5280#page-117) Version 字段只能取三个值中的一个，并对这三个值分别赋予了含义： ```asn1 Version ::= INTEGER { v1(0), v2(1), v3(2) } ``` -这种方法也常用于标识 OID 的名称。注意此时没有用逗号，因此表示的是一个整体，而非可供选择的多个值。 [以 RFC 5280 为例](https://tools.ietf.org/html/rfc5280#page-110)： +这种方法也常用于标识 OID 的名称。注意此时没有用逗号，因此表示的是一个整体，而非可供选择的多个值。[以 RFC 5280 为例](https://tools.ietf.org/html/rfc5280#page-110)： ```asn1 id-pkix OBJECT IDENTIFIER ::= @@ -198,34 +198,34 @@ id-pkix OBJECT IDENTIFIER ::= security(5) mechanisms(5) pkix(7) } ``` -接下来还会出现 \[数字\]、IMPLICIT、EXPLICIT、UNIVERSAL、APPLICATION 等语法要素， 这些语法关系到编码细节，我们将在下文探讨。 +接下来还会出现 \[数字\]、IMPLICIT、EXPLICIT、UNIVERSAL、APPLICATION 等语法要素，这些语法关系到编码细节，我们将在下文探讨。 编码 ============ ASN.1 有很多种编码：BER、DER、PER、XER 等等。 BER (Basic Encoding Rules) 是一种很灵活的编码， DER (Distinguished Encoding Rules) 则在 BER 的基础上加入了[规范化](https://en.wikipedia.org/wiki/Canonicalization)的规则，从而保证同样的信息编码方式也是唯一的。 PER (Packed Encoding Rules) 编码更为紧凑，适合对存储空间或传输速度要求较高的场景。 XER (XML Encoding Rules) 则在需要使用 XML 的情况下能够派上用场。 -HTTPS 证书通常采用 DER 编码。 用 BER 也是可以的，但是数字签名必须根据 DER 编码计算，和证书的实际编码方式无关，所以用 BER 相当于自讨苦吃。 本文以介绍 BER 为主，并随之说明 DER 在其基础上施加的额外规定。 +HTTPS 证书通常采用 DER 编码。用 BER 也是可以的，但是数字签名必须根据 DER 编码计算，和证书的实际编码方式无关，所以用 BER 相当于自讨苦吃。本文以介绍 BER 为主，并随之说明 DER 在其基础上施加的额外规定。 阅读本章时建议在另一窗口打开这个[实际证书解码示例](https://lapo.it/asn1js/#MIIFaTCCBFGgAwIBAgISA9QVMY4sVx0pBfw-BSdonQ0JMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQDExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA5MjkxNjMzMzZaFw0xOTEyMjgxNjMzMzZaMBoxGDAWBgNVBAMTD2xldHNlbmNyeXB0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANACdZdYiHLXjUhzqmaHENZ_mYp05-bbJw0RhmkCMN32iqPP0_2_KBRi60F87-itSNcKpQ_HQmEm5NoaH6rHzPuihv834og9TPsHeM0QOkaGOcR001h0kGRlIgynXzG7kSO7hTAUSbLfzCD4Hp8swLJHCz787sn_09DvPkJdeHhlQvrgfnGXqsHLqSXo9UtZXriwYS0HRCt5dKCLTOQAmS5ezKG2-7LVcuQQGsG1st3f2t092zJ8BDj_hAd0Zh8vKRwkDZvPzZzo76g4pGtVPRhmcDnVLin4PmsysWevEdzpJhNO7FXCsCA2aWo4ePAYKrR9BjyNlPAQ2QkKlI_cJx8CAwEAAaOCAncwggJzMA4GA1UdDwEB_wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH_BAIwADAdBgNVHQ4EFgQUfCuj5zyEXzjUdndlK8VKWGyO3aowHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl7_Oo7KEwbwYIKwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5pbnQteDMubGV0c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMubGV0c2VuY3J5cHQub3JnLzAvBgNVHREEKDAmgg9sZXRzZW5jcnlwdC5vcmeCE3d3dy5sZXRzZW5jcnlwdC5vcmcwTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggECBgorBgEEAdZ5AgQCBIHzBIHwAO4AdQDiaUuuJujpQAnohhu2O4PUPuf-dIj7pI8okwGd3fHb_gAAAW1-FbruAAAEAwBGMEQCIBROHx_dL0yfOpZs7Y6teawOn0oawhuW-3lvVs61DhjcAiB2ZuYwHu3BwYtqJTqfwsjQzjMZm8bQOutdme7dfaLXvgB1ACk8UZZUyDlluqpQ_FgH1Ldvv1h6KXLcpMMM9OVFR_R4AAABbX4VuuYAAAQDAEYwRAIgTc8_QJi4odfZIQ1u74zzvkBobqa08Wb_vxoqlgviUYICIGnAFgaPUg-xzKTRZGTGO4cj8UGJ3f52NoD6UWipPgIvMA0GCSqGSIb3DQEBCwUAA4IBAQAWl67Avp7BgqZW3VEWEjXHganloM8OHMS6en6S46nyuW0itGzth8SmCuG4i7fseecEG3Zsm0U1S1d3AffClOwWAGxB5Ark8Bpjszy8nGtNo7pFH-psGCBGj1pnklteu3jUzkkXKHS00Dsna1fJIzswgD7X7et8PRvV3ufIidkvvbfev0L2TYPWEFMM7WO0eIysf9WTljuflgcbzJXY0PatUBzL59ekidJZvGZ7d-hTl14CcCTrZ-VGMZlmK6tMhBuXJdAa5R0QSUpqirGRLz37Ox-SVh_tjA-I2tcRs0euAoX0etcr5cbBapV4-6LtSUt_rLBddeXCnDxqAWQxyy0p)，方便对照。 类型–长度–数据 ----------------- -与 Protocol Buffers 和 Thrift 一样，BER 的编码形式称为“类型–长度–数据”（type–length–value，常缩写为 TLV）。 也就是说，如果按顺序读取 BER 编码的每个字节，首先读取到的是类型信息，在 ASN.1 中称为“标签”。 标签可以有一个或多个字节，表示存储的是哪种数据，例如 INTEGER、UTF8String 等等。 +与 Protocol Buffers 和 Thrift 一样，BER 的编码形式称为“类型–长度–数据”（type–length–value，常缩写为 TLV）。也就是说，如果按顺序读取 BER 编码的每个字节，首先读取到的是类型信息，在 ASN.1 中称为“标签”。标签可以有一个或多个字节，表示存储的是哪种数据，例如 INTEGER、UTF8String 等等。 | 类型 | 长度 | 数据 | | -- | -- | -------- | | 02 | 03 | 01 00 01 | -接下来出现的是长度，表示数据究竟有多少个字节。 再接下来自然就是数据本身了。 例如，以十六进制表示的字节 02 03 01 00 01 表示一个 INTEGER（02 就是 INTEGER 类型对应的标签），长度是 03，后面的 3 个字节 01 00 01 则是数据。 +接下来出现的是长度，表示数据究竟有多少个字节。再接下来自然就是数据本身了。例如，以十六进制表示的字节 02 03 01 00 01 表示一个 INTEGER（02 就是 INTEGER 类型对应的标签），长度是 03，后面的 3 个字节 01 00 01 则是数据。 与类型–长度–数据的编码方式不同，JSON、CSV、XML 等格式通过分隔符实现编码，也就是事先并不知道数据的长度，出现特定的分隔符（比如 JSON 中的 `}` 和 XML 中的 ``）便表示数据结束。 标签 --- -标签通常只有一个字节。 如果使用多个字节还可以编码任意大小的标签，但通常没有这个必要。 +标签通常只有一个字节。如果使用多个字节还可以编码任意大小的标签，但通常没有这个必要。 以下是一些常见的标签： @@ -257,14 +257,14 @@ table { 这些标签都属于“通用”标签 (universal tags)，由 ASN.1 核心规范定义，在所有 ASN.1 模块中都有着相同的含义。此外还有一些无关紧要的通用标签，这里略去不表。 -这些标签的值都小于 31（0x1F），其实是有原因的。第 8、7、6 位（也就是标签字节的最高三位）有着特殊含义，所以大于 31 的通用标签只能用多字节标签表示。 有一小部分通用标签的值大于 31，但是数量很少。 +这些标签的值都小于 31（0x1F），其实是有原因的。第 8、7、6 位（也就是标签字节的最高三位）有着特殊含义，所以大于 31 的通用标签只能用多字节标签表示。有一小部分通用标签的值大于 31，但是数量很少。 -标 * 的两个标签在编码中一定是 0x30 和 0x31，因为第 6 位表示该字段是单一字段还是复合字段。 这两种类型必然是复合字段，所以第 6 位只能是 1。 详见[单一字段与复合字段](#%E5%8D%95%E4%B8%80%E5%AD%97%E6%AE%B5%E4%B8%8E%E5%A4%8D%E5%90%88%E5%AD%97%E6%AE%B5)的说明。 +标 * 的两个标签在编码中一定是 0x30 和 0x31，因为第 6 位表示该字段是单一字段还是复合字段。这两种类型必然是复合字段，所以第 6 位只能是 1。详见[单一字段与复合字段](#%E5%8D%95%E4%B8%80%E5%AD%97%E6%AE%B5%E4%B8%8E%E5%A4%8D%E5%90%88%E5%AD%97%E6%AE%B5)的说明。 标签类别 ----------- -通用标签把“好用”的数字都用光了，但这并不妨碍我们定义自己的标签。 除了通用标签外还有三种标签：程序内部标签、特定语境标签和私有标签。 标签类别可通过第 7 位和第 8 位区分： +通用标签把“好用”的数字都用光了，但这并不妨碍我们定义自己的标签。除了通用标签外还有三种标签：程序内部标签、特定语境标签和私有标签。标签类别可通过第 7 位和第 8 位区分： | 类别 | 第 8 位 | 第 7 位 | | ----------------------- | -----:| -----:| @@ -273,7 +273,7 @@ table { | 特定语境 (Context-specific) | 1 | 0 | | 私有 (Private) | 1 | 1 | -标准规范中使用的大多是通用标签，因为通用标签已经涵盖了所有常用数据结构。 例如，证书序列号就是用朴实无华的 INTEGER 类型编码的，标签值为 0x02。 但有时标准中也需要定义特定语境标签来区分 SET 和 SEQUENCE 中的可省略元素，或者区分 CHOICE 中同类型的选项。 以下述定义为例： +标准规范中使用的大多是通用标签，因为通用标签已经涵盖了所有常用数据结构。例如，证书序列号就是用朴实无华的 INTEGER 类型编码的，标签值为 0x02。但有时标准中也需要定义特定语境标签来区分 SET 和 SEQUENCE 中的可省略元素，或者区分 CHOICE 中同类型的选项。以下述定义为例： ```asn1 Point ::= SEQUENCE { @@ -282,18 +282,18 @@ Point ::= SEQUENCE { } ``` -OPTIONAL 字段如果省略，在编码中就完全不存在，这样一来只有 x 坐标和只有 y 坐标的 Point 就无法区分。 例如，一个只声明 x 坐标为 9 的 Point 编码如下（30 是 SEQUENCE 的标签）： +OPTIONAL 字段如果省略，在编码中就完全不存在，这样一来只有 x 坐标和只有 y 坐标的 Point 就无法区分。例如，一个只声明 x 坐标为 9 的 Point 编码如下（30 是 SEQUENCE 的标签）： ```der 30 03 02 01 09 ``` -这是一个长度为 3（字节）的 SEQUENCE，包含一个长度为 1 的 INTEGER 元素，且其数值为 9。 但一个 y 坐标为 9 的 Point 也得这么编码，于是就出现了歧义。 +这是一个长度为 3（字节）的 SEQUENCE，包含一个长度为 1 的 INTEGER 元素，且其数值为 9。但一个 y 坐标为 9 的 Point 也得这么编码，于是就出现了歧义。 编码指令 --------------------- -为避免出现歧义，标准规范需要通过编码指令为每个字段分配互不相同的标签。 既然通用标签不能随意改变含义，我们只好改用其他类别，比如程序内部标签： +为避免出现歧义，标准规范需要通过编码指令为每个字段分配互不相同的标签。既然通用标签不能随意改变含义，我们只好改用其他类别，比如程序内部标签： ```asn1 Point ::= SEQUENCE { @@ -332,35 +332,35 @@ x 和 y 坐标都为 9 的 Point 则可以编码如下： 长度 ------ -类型–长度–数据中的长度指的一定是数据的字节数，数据中嵌套的所有字段也包含在内。 因此，只含有一个元素的 SEQUENCE 长度也不是 1，而是该元素编码后有多少个字节。 +类型–长度–数据中的长度指的一定是数据的字节数，数据中嵌套的所有字段也包含在内。因此，只含有一个元素的 SEQUENCE 长度也不是 1，而是该元素编码后有多少个字节。 -长度也有两种编码方式：短编码和长编码。 短编码就是一个字节，取值范围是 0 到 127。 +长度也有两种编码方式：短编码和长编码。短编码就是一个字节，取值范围是 0 到 127。 -长编码则至少有两个字节。第一个字节的第 8 位必须为 1， 其余 7 位表示这个长度字段还有几个字节。 接下来就是一个多字节整数，给出了长度的具体数值。 +长编码则至少有两个字节。第一个字节的第 8 位必须为 1，其余 7 位表示这个长度字段还有几个字节。接下来就是一个多字节整数，给出了长度的具体数值。 -可想而知，这样得到的长度值可以非常大。 长度最大时第一个字节是 254（255 是保留值，供将来扩展使用），表示这个长度字段内还有足足 126 个字节。 如果这 126 个字节都是 255，那么实际数据的长度会达到 21008−1 字节（超过 10294 GB）。 +可想而知，这样得到的长度值可以非常大。长度最大时第一个字节是 254（255 是保留值，供将来扩展使用），表示这个长度字段内还有足足 126 个字节。如果这 126 个字节都是 255，那么实际数据的长度会达到 21008−1 字节（超过 10294 GB）。 -此外，同一长度值的长编码并不唯一，比如一个字节的数字可以拿两个字节表示，短编码就能表示的数字也可以用长编码。 所以 DER 规定必须采用最短的编码方式。 +此外，同一长度值的长编码并不唯一，比如一个字节的数字可以拿两个字节表示，短编码就能表示的数字也可以用长编码。所以 DER 规定必须采用最短的编码方式。 -安全警示：不要轻信长度字段的值！ 举例来说，待解码的数据流究竟有没有该字段显示的那么长还是需要核实的。 +安全警示：不要轻信长度字段的值！举例来说，待解码的数据流究竟有没有该字段显示的那么长还是需要核实的。 不定长编码 ----------------- -在 BER 中，字符串、SEQUENCE、SEQUENCE OF、SET 和 SET OF 类型的字段即使事先不知道长度也可以直接编码，通过数据流输出就可以采用这种方式。 具体方法是将长度字段设为一个字节 0x80，数据中连续存放若干个编码后的字段，最后以两个字节 `00 00`（可以认为是一个标签和长度都为 0 的字段）结尾。 例如，UTF8String 的不定长编码就是若干个 UTF8String 拼接在一起，然后在末尾加上 `00 00`。 +在 BER 中，字符串、SEQUENCE、SEQUENCE OF、SET 和 SET OF 类型的字段即使事先不知道长度也可以直接编码，通过数据流输出就可以采用这种方式。具体方法是将长度字段设为一个字节 0x80，数据中连续存放若干个编码后的字段，最后以两个字节 `00 00`（可以认为是一个标签和长度都为 0 的字段）结尾。例如，UTF8String 的不定长编码就是若干个 UTF8String 拼接在一起，然后在末尾加上 `00 00`。 -不定长编码还可以任意嵌套。 例如，在 UTF8String 的不定长编码中，待拼接的每一段 UTF8String 本身也可以选用定长或不定长编码。 +不定长编码还可以任意嵌套。例如，在 UTF8String 的不定长编码中，待拼接的每一段 UTF8String 本身也可以选用定长或不定长编码。 -作为长度的 0x80 字节并不存在歧义，因为它既不是短编码，也不是长编码。 它的第 8 位是 1，按理说应该是长编码，其余 7 位表示还有多少个字节。 但这 7 位都是 0，说明长度要用 0 个字节来表示，这是不允许的。 +作为长度的 0x80 字节并不存在歧义，因为它既不是短编码，也不是长编码。它的第 8 位是 1，按理说应该是长编码，其余 7 位表示还有多少个字节。但这 7 位都是 0，说明长度要用 0 个字节来表示，这是不允许的。 -DER 禁止使用不定长编码， 所以必须使用定长编码，提前写明数据的实际长度。 +DER 禁止使用不定长编码，所以必须使用定长编码，提前写明数据的实际长度。 单一字段与复合字段 ------------------------ -标签中第一个字节的第 6 位表示该字段是单一 (primitive) 字段还是复合 (constructed) 字段。 单一字段中存储的就是数据本身，比如 UTF8String 的数据就是经过 UTF-8 编码的字符串。 复合字段存储的则是若干其他字段，经过编码后拼接在一起。 例如“不定长编码”一节中提到的不定长 UTF8String 就会有多个 UTF8String 字段（各有标签和长度）编码后连在一起，形成复合字段。 复合字段的长度便是拼接后各字段的总字节数。 复合字段可以采用定长或不定长编码， 而单一字段只能用定长编码，因为其数据中没有其他字段，也就无法表明数据该在哪里结束。 +标签中第一个字节的第 6 位表示该字段是单一 (primitive) 字段还是复合 (constructed) 字段。单一字段中存储的就是数据本身，比如 UTF8String 的数据就是经过 UTF-8 编码的字符串。复合字段存储的则是若干其他字段，经过编码后拼接在一起。例如“不定长编码”一节中提到的不定长 UTF8String 就会有多个 UTF8String 字段（各有标签和长度）编码后连在一起，形成复合字段。复合字段的长度便是拼接后各字段的总字节数。复合字段可以采用定长或不定长编码，而单一字段只能用定长编码，因为其数据中没有其他字段，也就无法表明数据该在哪里结束。 -INTEGER、OBJECT IDENTIFIER 和 NULL 类型必须是单一字段， 而 SEQUENCE、SEQUENCE OF、SET 和 SET OF 类型必须是复合字段（因为它们的作用本来就是存放多个元素）。 BIT STRING、OCTET STRING、UTCTime、GeneralizedTime 还有各种字符串类型既可以是单一字段，也可以是复合字段，在 BER 中编码者可以自行决定， 但在 DER 中凡是单一、复合均可的类型都必须用单一字段。 +INTEGER、OBJECT IDENTIFIER 和 NULL 类型必须是单一字段，而 SEQUENCE、SEQUENCE OF、SET 和 SET OF 类型必须是复合字段（因为它们的作用本来就是存放多个元素）。 BIT STRING、OCTET STRING、UTCTime、GeneralizedTime 还有各种字符串类型既可以是单一字段，也可以是复合字段，在 BER 中编码者可以自行决定，但在 DER 中凡是单一、复合均可的类型都必须用单一字段。 EXPLICIT 与 IMPLICIT -------------------- @@ -384,7 +384,7 @@ TBSCertificate ::= SEQUENCE { -- If present, version MUST be v3 -- } ``` -这两个关键字定义的是标签的编码方式，与标签值是明确写出还是自动分配无关。事实上使用这两个关键字时都必须在方括号中写明标签的值。 IMPLICIT 字段的编码方式与其原始类型相同，只是标签的值和类别由方括号中的内容决定。 EXPLICIT 字段则需要先将数据按原始类型编码，再将编码结果套入另一字段中。 外层字段的标签值和类别再由方括号中的内容决定，而且一定是[复合字段](#%E5%8D%95%E4%B8%80%E5%AD%97%E6%AE%B5%E4%B8%8E%E5%A4%8D%E5%90%88%E5%AD%97%E6%AE%B5)。 +这两个关键字定义的是标签的编码方式，与标签值是明确写出还是自动分配无关。事实上使用这两个关键字时都必须在方括号中写明标签的值。 IMPLICIT 字段的编码方式与其原始类型相同，只是标签的值和类别由方括号中的内容决定。 EXPLICIT 字段则需要先将数据按原始类型编码，再将编码结果套入另一字段中。外层字段的标签值和类别再由方括号中的内容决定，而且一定是[复合字段](#%E5%8D%95%E4%B8%80%E5%AD%97%E6%AE%B5%E4%B8%8E%E5%A4%8D%E5%90%88%E5%AD%97%E6%AE%B5)。 例如，若在 ASN.1 的编码指令中加上 IMPLICIT： @@ -410,7 +410,7 @@ TBSCertificate ::= SEQUENCE { A5 04 0C 02 68 69 ``` -如果 IMPLICIT 和 EXPLICIT 关键字都没有出现，默认编码为 EXPLICIT，除非该模块开头指定了“EXPLICIT TAGS”、“IMPLICIT TAGS”或“AUTOMATIC TAGS”。 例如 RFC 5280 定义了两个模块，一个[默认编码为 EXPLICIT](https://tools.ietf.org/html/rfc5280#appendix-A.1)，另一个则导入了前一模块，并将[默认编码设为 IMPLICIT](https://tools.ietf.org/html/rfc5280#appendix-A.2)。 IMPLICIT 编码比 EXPLICIT 编码更短。 +如果 IMPLICIT 和 EXPLICIT 关键字都没有出现，默认编码为 EXPLICIT，除非该模块开头指定了“EXPLICIT TAGS”、“IMPLICIT TAGS”或“AUTOMATIC TAGS”。例如 RFC 5280 定义了两个模块，一个[默认编码为 EXPLICIT](https://tools.ietf.org/html/rfc5280#appendix-A.1)，另一个则导入了前一模块，并将[默认编码设为 IMPLICIT](https://tools.ietf.org/html/rfc5280#appendix-A.2)。 IMPLICIT 编码比 EXPLICIT 编码更短。 AUTOMATIC TAGS 的作用与 IMPLICIT TAGS 相同，只是标签的数值（`[0]`、`[1]` 等等）会在必要时自动分配，比如 SEQUENCE 中存在可省略元素的情况。 @@ -424,7 +424,7 @@ INTEGER 的编码 整数的编码由一个或多个字节组成，采用补码格式，最左侧字节的最高位（即第 8 位）为符号位。 BER 标准中是这样写的： -计算二进制补码的数值时，首先将其各字节的每一位标号，最后一个字节的最低位序号为 0，从这一位开始到第一个字节的最高位序号依次递增， 第 N 位表示的数值为 2N。 整个二进制补码的值即为所有等于 1 的二进制位表示的数值的总和（除了最高位），再减去最高位表示的数值（如果最高位为 1）。 +计算二进制补码的数值时，首先将其各字节的每一位标号，最后一个字节的最低位序号为 0，从这一位开始到第一个字节的最高位序号依次递增，第 N 位表示的数值为 2N。整个二进制补码的值即为所有等于 1 的二进制位表示的数值的总和（除了最高位），再减去最高位表示的数值（如果最高位为 1）。 例如，这个字节（以二进制表示）等于十进制数字 50： @@ -438,7 +438,7 @@ INTEGER 的编码 10000000 00000000 00000000 00000000 00000001（即十进制的 20 − 239） -BER 和 DER 都规定整数必须以最短的方式编码。 这一规则是通过以下条件体现的： +BER 和 DER 都规定整数必须以最短的方式编码。这一规则是通过以下条件体现的： ``` ……第一个字节的每一位和第二个字节的最高位： @@ -447,13 +447,13 @@ BER 和 DER 都规定整数必须以最短的方式编码。 这一规则是通 2. 也不能同时为 0。 ``` -第二项条件的大意就是说，如果编码开头存在零字节，那么把它们删去也不会影响数值。 第二个字节的最高位也很重要，因为有些数值的编码开头必须有零字节。 例如，十进制的 255 需要用两个字节编码： +第二项条件的大意就是说，如果编码开头存在零字节，那么把它们删去也不会影响数值。第二个字节的最高位也很重要，因为有些数值的编码开头必须有零字节。例如，十进制的 255 需要用两个字节编码： 00000000 11111111 因为一个字节 11111111 表示的是 −1（最高位是符号位）。 -第一项条件则最好结合实例来看。 比如十进制数字 −128 的编码为： +第一项条件则最好结合实例来看。比如十进制数字 −128 的编码为： 10000000（即十进制的 −27 = −128） @@ -461,11 +461,11 @@ BER 和 DER 都规定整数必须以最短的方式编码。 这一规则是通 11111111 10000000（还是十进制的 −128，不过是错误的编码） -不难验证，−215 + 214 + 213 + 212 + 211 + 210 + 29 + 28 + 27 = −27 = −128。 注意，1 在单字节的 10000000 中是符号位，但在第二个字节中只代表 27。 +不难验证，−215 + 214 + 213 + 212 + 211 + 210 + 29 + 28 + 27 = −27 = −128。注意，1 在单字节的 10000000 中是符号位，但在第二个字节中只代表 27。 -这种变换具有普遍性：BER（或 DER）编码的任何一个负数都可以在开头加上 11111111 并保持数值不变。 这称为[符号扩展](https://andybargh.com/binary-sign-extension/)。 反过来说，如果一个负数的编码开头是 11111111，将该字节删去同样不会影响数值。 这就是 BER 与 DER 要求使用最短编码的原因。 +这种变换具有普遍性：BER（或 DER）编码的任何一个负数都可以在开头加上 11111111 并保持数值不变。这称为[符号扩展](https://andybargh.com/binary-sign-extension/)。反过来说，如果一个负数的编码开头是 11111111，将该字节删去同样不会影响数值。这就是 BER 与 DER 要求使用最短编码的原因。 -INTEGER 采用补码表示[对于证书发行影响重大](https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__closed__&product=NSS&content=%E2%80%9CSerial%20entropy%E2%80%9D&comments=0&list_id=16028758)。RFC 5280 规定证书序列号必须是正数， 但最高位必然是符号位，所以 DER 中 8 个字节只能编码 63 位的序列号， 64 位的正数需要 9 个字节才能编码（尽管第一个字节为 0）。 +INTEGER 采用补码表示[对于证书发行影响重大](https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__closed__&product=NSS&content=%E2%80%9CSerial%20entropy%E2%80%9D&comments=0&list_id=16028758)。RFC 5280 规定证书序列号必须是正数，但最高位必然是符号位，所以 DER 中 8 个字节只能编码 63 位的序列号， 64 位的正数需要 9 个字节才能编码（尽管第一个字节为 0）。 值为 263+1（恰好是 64 位的正数）的 INTEGER 编码如下： @@ -490,7 +490,7 @@ PrintableString 的“hi”编码为： 16 02 68 69 ``` -UTF8String 也类似，但它能表示的字符更多。 例如，表情“😎” (U+1F60E Smiling Face With Sunglasses) 的编码是： +UTF8String 也类似，但它能表示的字符更多。例如，表情“😎” (U+1F60E Smiling Face With Sunglasses) 的编码是： ```der 0c 04 f0 9f 98 8e @@ -499,15 +499,15 @@ UTF8String 也类似，但它能表示的字符更多。 例如，表情“😎 日期和时间的编码 ---------------------- -出人意料的是，UTCTime 和 GeneralizedTime 的编码方式其实和字符串一样。 正如上文“类型”一章所述，UTCTime 表示时间的格式是 YYMMDDhhmmss， GeneralizedTime 则在其基础上将 YY 改成了四位年份 YYYY。 二者最后都可以加上时区，或者加一个 Z 表示协调世界时 (UTC)。 +出人意料的是，UTCTime 和 GeneralizedTime 的编码方式其实和字符串一样。正如上文“类型”一章所述，UTCTime 表示时间的格式是 YYMMDDhhmmss， GeneralizedTime 则在其基础上将 YY 改成了四位年份 YYYY。二者最后都可以加上时区，或者加一个 Z 表示协调世界时 (UTC)。 -例如，太平洋标准时间（PST，即 UTC−8）的 2019 年 12 月 15 日 19:02:10 用 UTCTime 表示为 191215190210-0800， 用 BER 编码就是： +例如，太平洋标准时间（PST，即 UTC−8）的 2019 年 12 月 15 日 19:02:10 用 UTCTime 表示为 191215190210-0800，用 BER 编码就是： ```der 17 11 31 39 31 32 31 35 31 39 30 32 31 30 2d 30 38 30 30 ``` -BER 编码中，UTCTime 和 GeneralizedTime 的秒数都可以省略，并且可以使用各种时区。 但在 DER 编码（及 RFC 5280）中，秒数则不能省略，且不能出现小数，时区也只能用 Z，表示协调世界时。 +BER 编码中，UTCTime 和 GeneralizedTime 的秒数都可以省略，并且可以使用各种时区。但在 DER 编码（及 RFC 5280）中，秒数则不能省略，且不能出现小数，时区也只能用 Z，表示协调世界时。 上述时间如果用 DER 编码则是： @@ -518,13 +518,13 @@ BER 编码中，UTCTime 和 GeneralizedTime 的秒数都可以省略，并且可 OBJECT IDENTIFIER 的编码 -------------------------- -如[上文所述](#object-identifier)，OID 的实质就是一串整数， 而且至少由两个整数组成。 第一个数必须是 0、1、2 三者之一， 如果是 0 或 1，则第二个数必须小于 40。 因此，前两个数 X 和 Y 可以直接用 40×X+Y 来表示，不会产生歧义。 +如[上文所述](#object-identifier)，OID 的实质就是一串整数，而且至少由两个整数组成。第一个数必须是 0、1、2 三者之一，如果是 0 或 1，则第二个数必须小于 40。因此，前两个数 X 和 Y 可以直接用 40×X+Y 来表示，不会产生歧义。 以 2.999.3 的编码为例，首先要将前两个数合并成 1079（即 40×2+999），得到 1079.3。 -完成合并后再用 Base 128 编码，左侧为高位字节。 也就是说，每个字节的最高位设为 1，但最后一个字节最高位设为 0，表示一个整数到此结束。各字节的其余七位从高到低依次相连表示数值。 例如数字 3 就用一个字节 0x03 表示， 而 129 则需要两个字节 0x81 0x01。 每个数字都如此转换成字节后，拼接在一起就形成了 OID 的编码。 +完成合并后再用 Base 128 编码，左侧为高位字节。也就是说，每个字节的最高位设为 1，但最后一个字节最高位设为 0，表示一个整数到此结束。各字节的其余七位从高到低依次相连表示数值。例如数字 3 就用一个字节 0x03 表示，而 129 则需要两个字节 0x81 0x01。每个数字都如此转换成字节后，拼接在一起就形成了 OID 的编码。 -无论是在 BER 还是 DER 中，OID 都必须用最短的方式编码。 所以其中每个数字编码时开头都不能出现 0x80 字节。 +无论是在 BER 还是 DER 中，OID 都必须用最短的方式编码。所以其中每个数字编码时开头都不能出现 0x80 字节。 例如，OID 1.2.840.113549.1.1.11（代表 [sha256WithRSAEncryption](https://tools.ietf.org/html/rfc8017#appendix-A.2.4)）的编码是： @@ -544,11 +544,11 @@ NULL 字段的长度永远为 0，所以它的编码只有标签和长度： SEQUENCE 的编码 ----------------- -首先需要注意的是，SEQUENCE 必然是复合字段，因为它的作用就是容纳其他对象。 换句话说，SEQUENCE 中的数据就是其元素各自编码后按定义中的顺序拼接在一起组成的。 因此，SEQUENCE 标签的第 6 位（[单一/复合字段](#%E5%8D%95%E4%B8%80%E5%AD%97%E6%AE%B5%E4%B8%8E%E5%A4%8D%E5%90%88%E5%AD%97%E6%AE%B5)位）一定是 1。 虽然 SEQUENCE 本来的标签是 0x10，但在编码中一定会以 0x30 的形式出现。 +首先需要注意的是，SEQUENCE 必然是复合字段，因为它的作用就是容纳其他对象。换句话说，SEQUENCE 中的数据就是其元素各自编码后按定义中的顺序拼接在一起组成的。因此，SEQUENCE 标签的第 6 位（[单一/复合字段](#%E5%8D%95%E4%B8%80%E5%AD%97%E6%AE%B5%E4%B8%8E%E5%A4%8D%E5%90%88%E5%AD%97%E6%AE%B5)位）一定是 1。虽然 SEQUENCE 本来的标签是 0x10，但在编码中一定会以 0x30 的形式出现。 -SEQUENCE 的定义中标为 OPTIONAL 的字段可以省略，省略后就会直接从编码中消失。 读取 SEQUENCE 的内容时，解码器可以根据标签和已读入的元素确定正在读取的是哪个字段。 如果存在歧义，比如有同类型的元素，则在 ASN.1 模块中必须借助[编码指令](#%E7%BC%96%E7%A0%81%E6%8C%87%E4%BB%A4)为这些元素分配不同的标签。 +SEQUENCE 的定义中标为 OPTIONAL 的字段可以省略，省略后就会直接从编码中消失。读取 SEQUENCE 的内容时，解码器可以根据标签和已读入的元素确定正在读取的是哪个字段。如果存在歧义，比如有同类型的元素，则在 ASN.1 模块中必须借助[编码指令](#%E7%BC%96%E7%A0%81%E6%8C%87%E4%BB%A4)为这些元素分配不同的标签。 -标有 DEFAULT 的字段与 OPTIONAL 类似。 如果该字段取默认值，在 BER 编码中就可以予以省略， 而在 DER 编码中则必须省略。 +标有 DEFAULT 的字段与 OPTIONAL 类似。如果该字段取默认值，在 BER 编码中就可以予以省略，而在 DER 编码中则必须省略。 例如，RFC 5280 中的 [AlgorithmIdentifier](https://tools.ietf.org/html/rfc5280#page-118) 就是 SEQUENCE 类型： @@ -567,7 +567,7 @@ algorithm 为 1.2.840.113549.1.1.11 的 AlgorithmIdentifier 编码如下。 RFC SEQUENCE OF 的编码 -------------------- -SEQUENCE OF 的编码方式与 SEQUENCE 完全相同， 甚至连标签都一样！ 解码时也只有查阅 ASN.1 模块才能确定一个字段究竟是 SEQUENCE 还是 SEQUENCE OF。 +SEQUENCE OF 的编码方式与 SEQUENCE 完全相同，甚至连标签都一样！解码时也只有查阅 ASN.1 模块才能确定一个字段究竟是 SEQUENCE 还是 SEQUENCE OF。 例如以下是一个 SEQUENCE OF 对象的编码，其中包含 7、8、9 三个 INTEGER。 @@ -578,21 +578,21 @@ SEQUENCE OF 的编码方式与 SEQUENCE 完全相同， 甚至连标签都一样 SET 的编码 ------------ -与 SEQUENCE 一样，SET 也一定是复合字段，其数据总是由若干个字段的编码组成的。 它的标签是 0x11， 但因为[单一/复合字段](#%E5%8D%95%E4%B8%80%E5%AD%97%E6%AE%B5%E4%B8%8E%E5%A4%8D%E5%90%88%E5%AD%97%E6%AE%B5)位（第 6 位）必须为 1，所以在编码中实际上是 0x31。 +与 SEQUENCE 一样，SET 也一定是复合字段，其数据总是由若干个字段的编码组成的。它的标签是 0x11，但因为[单一/复合字段](#%E5%8D%95%E4%B8%80%E5%AD%97%E6%AE%B5%E4%B8%8E%E5%A4%8D%E5%90%88%E5%AD%97%E6%AE%B5)位（第 6 位）必须为 1，所以在编码中实际上是 0x31。 -SET 的编码方式也和 SEQUENCE 类似，OPTIONAL 和 DEFAULT 字段如果省略或取默认值就不会出现， 任何由类型相同导致的歧义都需要在 ASN.1 模块中解决，并且取默认值的 DEFAULT 字段在 DER 编码中必须省略。 +SET 的编码方式也和 SEQUENCE 类似，OPTIONAL 和 DEFAULT 字段如果省略或取默认值就不会出现，任何由类型相同导致的歧义都需要在 ASN.1 模块中解决，并且取默认值的 DEFAULT 字段在 DER 编码中必须省略。 -BER 编码对 SET 中元素的顺序没有要求， 但在 DER 中各元素必须按标签值升序排列。 +BER 编码对 SET 中元素的顺序没有要求，但在 DER 中各元素必须按标签值升序排列。 SET OF 的编码 --------------- -SET OF 的编码方式和 SET 一样，标签也是 0x31。 DER 编码同样规定 SET OF 中的字段要按升序排列。 因为 SET OF 中所有元素的类型都一样，仅靠标签排序是不够的。 所以 SET OF 中的元素以编码后的字节序为准，编码较短的就先在最后补齐零字节再作排序。 +SET OF 的编码方式和 SET 一样，标签也是 0x31。 DER 编码同样规定 SET OF 中的字段要按升序排列。因为 SET OF 中所有元素的类型都一样，仅靠标签排序是不够的。所以 SET OF 中的元素以编码后的字节序为准，编码较短的就先在最后补齐零字节再作排序。 BIT STRING 的编码 ------------------- -一个 N 位的 BIT STRING 用 N/8 个字节（向上取整）来编码，开头还有一个字节的前缀，当 N 不是 8 的倍数时可以指明最后有几个二进制位是无用的。 例如，编码 18 个二进制位 011011100101110111 至少需要三个字节， 但三个字节其实足以存放 24 个二进制位， 有 6 位是用不上的。 这 6 位就放在末尾，于是最终编码为： +一个 N 位的 BIT STRING 用 N/8 个字节（向上取整）来编码，开头还有一个字节的前缀，当 N 不是 8 的倍数时可以指明最后有几个二进制位是无用的。例如，编码 18 个二进制位 011011100101110111 至少需要三个字节，但三个字节其实足以存放 24 个二进制位，有 6 位是用不上的。这 6 位就放在末尾，于是最终编码为： ```der 03 04 06 6e 5d c0 @@ -603,7 +603,7 @@ BIT STRING 的编码 OCTET STRING 的编码 --------------------- -OCTET STRING 的编码就是其中包含的所有字节。 例如，包含四个字节 03 02 06 A0 的 OCTET STRING 的编码为： +OCTET STRING 的编码就是其中包含的所有字节。例如，包含四个字节 03 02 06 A0 的 OCTET STRING 的编码为： ```der 04 04 03 02 06 A0 @@ -612,9 +612,9 @@ OCTET STRING 的编码就是其中包含的所有字节。 例如，包含四个 CHOICE 和 ANY 的编码 ----------------------- -CHOICE 和 ANY 的编码与其最终表示的实际类型一致，但也可以通过编码指令更改。 假如一份 ASN.1 相关规范要求某一个 CHOICE 字段必须是 INTEGER 或 UTCTime，而现在该字段恰好属于 INTEGER，那就按 INTEGER 编码即可。 +CHOICE 和 ANY 的编码与其最终表示的实际类型一致，但也可以通过编码指令更改。假如一份 ASN.1 相关规范要求某一个 CHOICE 字段必须是 INTEGER 或 UTCTime，而现在该字段恰好属于 INTEGER，那就按 INTEGER 编码即可。 -但实际应用中 CHOICE 往往都有编码指令。 比如在 RFC 5280 的下列定义中，rfc822Name 和 dNSName 的类型都是 IA5String，只有靠编码指令才能区分。 +但实际应用中 CHOICE 往往都有编码指令。比如在 RFC 5280 的下列定义中，rfc822Name 和 dNSName 的类型都是 IA5String，只有靠编码指令才能区分。 ``` GeneralName ::= CHOICE { @@ -644,19 +644,19 @@ CHOICE 和 ANY 的编码与其最终表示的实际类型一致，但也可以 安全性 ====== -解码 BER 和 DER 格式时必须格外小心，尤其是在 C、C++ 等非内存安全的编程语言中。 各种解码器的安全漏洞可谓罄竹难书， 而解析用户输入本身就是[安全问题的一大来源](https://langsec.org/)。 ASN.1 编码与漏洞近乎[如影随形](https://bugzilla.redhat.com/show_bug.cgi?id=1300257)， 毕竟这种格式颇为复杂，各种不定长度的字段不计其数， 连长度字段本身都没有固定长度！ 另一方面，ASN.1 格式的数据又往往来自潜在的攻击者， 所以如果要靠数字证书验证用户身份，不能光考虑如何解码正确的证书，还得应对五花八门的恶意输入，以免 ASN.1 代码中存在漏洞而被攻陷。 +解码 BER 和 DER 格式时必须格外小心，尤其是在 C、C++ 等非内存安全的编程语言中。各种解码器的安全漏洞可谓罄竹难书，而解析用户输入本身就是[安全问题的一大来源](https://langsec.org/)。 ASN.1 编码与漏洞近乎[如影随形](https://bugzilla.redhat.com/show_bug.cgi?id=1300257)，毕竟这种格式颇为复杂，各种不定长度的字段不计其数，连长度字段本身都没有固定长度！另一方面，ASN.1 格式的数据又往往来自潜在的攻击者，所以如果要靠数字证书验证用户身份，不能光考虑如何解码正确的证书，还得应对五花八门的恶意输入，以免 ASN.1 代码中存在漏洞而被攻陷。 -面对这些问题，最好的解决办法就是尽可能使用内存安全的编程语言， 并且无论能否使用这类语言，都应当借助现成的 [ASN.1 编译器](https://www.itu.int/en/ITU-T/asn1/Pages/Tools.aspx)生成解析程序，而非闭门造车，自行编写解码器。 +面对这些问题，最好的解决办法就是尽可能使用内存安全的编程语言，并且无论能否使用这类语言，都应当借助现成的 [ASN.1 编译器](https://www.itu.int/en/ITU-T/asn1/Pages/Tools.aspx)生成解析程序，而非闭门造车，自行编写解码器。 致谢 ================ -首先我要向 [A Layman's Guide to a Subset of ASN.1, DER, and BER](https://luca.ntop.org/Teaching/Appunti/asn1.html) 致以诚挚的敬意，本文中的大部分知识我都是从这份材料中学到的。 我还要感谢另一篇佳作 [A warm welcome to DNS](https://powerdns.org/hello-dns/) 的作者，其文风也奠定了本文的笔法基调。 +首先我要向 [A Layman's Guide to a Subset of ASN.1, DER, and BER](https://luca.ntop.org/Teaching/Appunti/asn1.html) 致以诚挚的敬意，本文中的大部分知识我都是从这份材料中学到的。我还要感谢另一篇佳作 [A warm welcome to DNS](https://powerdns.org/hello-dns/) 的作者，其文风也奠定了本文的笔法基调。 一点题外话 ============== -你可曾注意到 PEM 编码的证书开头都是“MII”？ 例如： +你可曾注意到 PEM 编码的证书开头都是“MII”？例如： ``` -----BEGIN CERTIFICATE----- @@ -665,9 +665,9 @@ MIIFajCCBFKgAwIBAgISA6HJW9qjaoJoMn8iU8vTuiQ2MA0GCSqGSIb3DQEBCwUA ... ``` -现在你已经能解释原因了！ 证书本身[是一个 SEQUENCE 结构](https://tools.ietf.org/html/rfc5280#page-116)，所以第一个字节是 0x30。 接下来是[长度字段](#%E9%95%BF%E5%BA%A6)， 绝大多数证书都不止 127 个字节，所以需要采用长编码， 也就是说第一个字节是 0x80 + N，意味着后面还有 N 个字节表示长度。 N 一般都是 2，因为大多数证书的长度都在 128 至 65535 个字节之间，只需要两个字节表示。 +现在你已经能解释原因了！证书本身[是一个 SEQUENCE 结构](https://tools.ietf.org/html/rfc5280#page-116)，所以第一个字节是 0x30。接下来是[长度字段](#%E9%95%BF%E5%BA%A6)，绝大多数证书都不止 127 个字节，所以需要采用长编码，也就是说第一个字节是 0x80 + N，意味着后面还有 N 个字节表示长度。 N 一般都是 2，因为大多数证书的长度都在 128 至 65535 个字节之间，只需要两个字节表示。 -于是我们可以得知 DER 格式的证书前两个字节是 0x30 0x82。 但 [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) 采用了 [Base64 编码](https://en.wikipedia.org/wiki/Base64)，将每 3 个二进制字节转换成 4 个 ASCII 字符。 换句话说，Base64 是将 24 个二进制位写成 4 个 ASCII 字符，每个字符表示 6 个二进制位。 我们已经知道证书的前 16 位是什么了， 要证明（几乎）所有证书开头都是“MII”，还需确定接下来的两个二进制位。 这两位正是长度字节的最高位， 它们会是 1 吗？ 那这个证书就非得超过 16383 个字节不可！ 由此我们可以断定 PEM 证书开头的几个字符都是相同的。 你不妨也试试看： +于是我们可以得知 DER 格式的证书前两个字节是 0x30 0x82。但 [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) 采用了 [Base64 编码](https://en.wikipedia.org/wiki/Base64)，将每 3 个二进制字节转换成 4 个 ASCII 字符。换句话说，Base64 是将 24 个二进制位写成 4 个 ASCII 字符，每个字符表示 6 个二进制位。我们已经知道证书的前 16 位是什么了，要证明（几乎）所有证书开头都是“MII”，还需确定接下来的两个二进制位。这两位正是长度字节的最高位，它们会是 1 吗？那这个证书就非得超过 16383 个字节不可！由此我们可以断定 PEM 证书开头的几个字符都是相同的。你不妨也试试看： ```bash xxd -r -p <<<308200 | base64 diff --git a/content/zh-cn/docs/account-id.md b/content/zh-cn/docs/account-id.md index 5afd46fd11..f42b142f20 100644 --- a/content/zh-cn/docs/account-id.md +++ b/content/zh-cn/docs/account-id.md @@ -6,10 +6,10 @@ show_lastmod: 1 --- -当您向 Let’s Encrypt 报告问题时，提供您的 Let’s Encrypt 账户 ID 会对解决问题很有帮助。 在大多数情况下，您使用的 ACME 客户端软件连接到 Let’s Encrypt 服务器时将自动创建账户。若您在多个服务器上运行 ACME 客户端，您可能有多个账户。 +当您向 Let’s Encrypt 报告问题时，提供您的 Let’s Encrypt 账户 ID 会对解决问题很有帮助。在大多数情况下，您使用的 ACME 客户端软件连接到 Let’s Encrypt 服务器时将自动创建账户。若您在多个服务器上运行 ACME 客户端，您可能有多个账户。 账户 ID 的格式与网址相同，例如 `https://acme-v02.api.letsencrypt.org/acme/acct/12345678`。 如果您使用的是 1.23.0 或更高版本的 [Certbot](https://certbot.eff.org/)，可以执行 `certbot show_account` 命令查看账户 ID。 1.23.0 之前的 Certbot 版本则可以通过 `/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/regr.json` 中的“uri”字段查看账户 ID。 -如果您正在使用其他 ACME 客户端，具体方法将取决于您使用的客户端。 您可以检查日志中是否有上述形式的 URL。 如果您的 ACME 客户端未记录帐户 ID，您可以通过使用相同私钥提交新的注册请求来获取它。 详见[了解更多 ACME 规范详情](https://tools.ietf.org/html/rfc8555#section-7.3)。 您还可以在 ACME 客户端对 API 服务器发出的每个 POST 的响应中的 Boulder-Requester 标头中找到您的数字格式账户 ID。 +如果您正在使用其他 ACME 客户端，具体方法将取决于您使用的客户端。您可以检查日志中是否有上述形式的 URL。如果您的 ACME 客户端未记录帐户 ID，您可以通过使用相同私钥提交新的注册请求来获取它。详见[了解更多 ACME 规范详情](https://tools.ietf.org/html/rfc8555#section-7.3)。您还可以在 ACME 客户端对 API 服务器发出的每个 POST 的响应中的 Boulder-Requester 标头中找到您的数字格式账户 ID。 diff --git a/content/zh-cn/docs/acme-protocol-updates.md b/content/zh-cn/docs/acme-protocol-updates.md index a3c10059d2..c2227c82f1 100644 --- a/content/zh-cn/docs/acme-protocol-updates.md +++ b/content/zh-cn/docs/acme-protocol-updates.md @@ -10,17 +10,17 @@ show_lastmod: 1 # 目前使用的 API 端点 -我们目前运营的 API 网址如下。 另请查阅[我们的实现差异文档](https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md)，了解这些接口与 ACME 标准规范之间存在的不同。 +我们目前运营的 API 网址如下。另请查阅[我们的实现差异文档](https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md)，了解这些接口与 ACME 标准规范之间存在的不同。 * [生产环境] `https://acme-v02.api.letsencrypt.org/directory` * [测试环境] `https://acme-staging-v02.api.letsencrypt.org/directory` # 向后兼容的 ACME 新功能 -Let's Encrypt 会不定期在现有接口中实现向后兼容的新功能， 目的通常是改善对 ACME 规范的支持。 +Let's Encrypt 会不定期在现有接口中实现向后兼容的新功能，目的通常是改善对 ACME 规范的支持。 所有新功能都会在 ACME 的公开文档中明确记载，并且不会对实现得当的客户端造成任何不良影响。 # ACME 的新版本与不兼容的变更 -我们力图避免破坏 ACME 协议的兼容性，但如果经过考量确有必要，我们会尽可能提前告知，并确保在足够长的时间内平缓完成过渡。 为应对此类不兼容的变更，各位系统管理员应当具备及时更新 ACME 客户端的能力。 +我们力图避免破坏 ACME 协议的兼容性，但如果经过考量确有必要，我们会尽可能提前告知，并确保在足够长的时间内平缓完成过渡。为应对此类不兼容的变更，各位系统管理员应当具备及时更新 ACME 客户端的能力。 diff --git a/content/zh-cn/docs/allow-port-80.md b/content/zh-cn/docs/allow-port-80.md index a5c664b05e..3fb77c6a87 100644 --- a/content/zh-cn/docs/allow-port-80.md +++ b/content/zh-cn/docs/allow-port-80.md @@ -6,12 +6,12 @@ show_lastmod: 1 --- -我们偶尔会收到使用 HTTP-01 验证类型时遇到问题的人的报告，这是因为他们通过防火墙封闭了 Web 服务器上的 80 端口。 我们的建议是，所有用于一般 Web 使用的服务器应该同时在 80 端口上提供 HTTP 服务、在 443 端口上提供 HTTPS 服务。 他们还应该将所有发送至 80 端口的请求重定向至 443 端口，并且在（443 端口上的）所有响应中添加 HSTS 标头。 +我们偶尔会收到使用 HTTP-01 验证类型时遇到问题的人的报告，这是因为他们通过防火墙封闭了 Web 服务器上的 80 端口。我们的建议是，所有用于一般 Web 使用的服务器应该同时在 80 端口上提供 HTTP 服务、在 443 端口上提供 HTTPS 服务。他们还应该将所有发送至 80 端口的请求重定向至 443 端口，并且在（443 端口上的）所有响应中添加 HSTS 标头。 开放 80 端口并不会在服务器中引入更大的攻击面，因为 80 端口和 443 端口通常由同样的软件提供服务。 -关闭 80 端口不会降低意外通过 HTTP 访问您网站的人的风险。 在正常情况下，那个人将收到 HTTPS 重定向，其后续通信将受到保护。 如果该人受到活跃的 MITM 攻击，MITM 攻击者将在 80 端口上回应请求，因此您的站点将永远无法对该用户回答“连接已被拒绝”。 +关闭 80 端口不会降低意外通过 HTTP 访问您网站的人的风险。在正常情况下，那个人将收到 HTTPS 重定向，其后续通信将受到保护。如果该人受到活跃的 MITM 攻击，MITM 攻击者将在 80 端口上回应请求，因此您的站点将永远无法对该用户回答“连接已被拒绝”。 -最后，保持 80 端口开放并提供重定向有助于让人们访问您网站的正确版本（HTTPS 版本）。 有很多您无法控制的情况都可能暂时将访问者引导至您网站的 HTTP 版本，例如电子邮件中的自动链接或者手动输入网站域名。 对他们来说，获得重定向比获得错误更好。 +最后，保持 80 端口开放并提供重定向有助于让人们访问您网站的正确版本（HTTPS 版本）。有很多您无法控制的情况都可能暂时将访问者引导至您网站的 HTTP 版本，例如电子邮件中的自动链接或者手动输入网站域名。对他们来说，获得重定向比获得错误更好。 -不幸的是，在某些情况下您可能无法控制 80 端口的开放或者关闭。 部分 ISP（通常为住宅网络提供商）会因各种原因阻止对 80 端口的访问。 若您的 ISP 阻止您使用 80 端口但您仍旧希望从 Let’s Encrypt 获取证书，您有两种选择：您可以使用 DNS-01 验证方式，或（在443端口上）使用 [支持 TLS-ALPN-01 验证方式的客户端](https://community.letsencrypt.org/t/which-client-support-tls-alpn-challenge/75859/2) +不幸的是，在某些情况下您可能无法控制 80 端口的开放或者关闭。部分 ISP（通常为住宅网络提供商）会因各种原因阻止对 80 端口的访问。若您的 ISP 阻止您使用 80 端口但您仍旧希望从 Let’s Encrypt 获取证书，您有两种选择：您可以使用 DNS-01 验证方式，或（在443端口上）使用 [支持 TLS-ALPN-01 验证方式的客户端](https://community.letsencrypt.org/t/which-client-support-tls-alpn-challenge/75859/2) diff --git a/content/zh-cn/docs/caa.md b/content/zh-cn/docs/caa.md index 209baa4c61..38c9f56e77 100644 --- a/content/zh-cn/docs/caa.md +++ b/content/zh-cn/docs/caa.md @@ -1,26 +1,26 @@ --- title: 证书颁发机构授权 (CAA) slug: caa -lastmod: 2023-08-16 +lastmod: 2026-10-04 show_lastmod: 1 --- -CAA 是一类 DNS 记录，网站所有者可以通过它规定哪些证书颁发机构 (CA) 有权为其域名颁发证书。 2013 年 CAA 首次实现标准化，我们现在使用的则是 2019 年由 [RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659) 和 [RFC 8657](https://datatracker.ietf.org/doc/html/rfc8657) 修订的版本。 默认情况下，只要核验了域名归属，所有公共 CA 都能为任一公开 DNS 域名颁发证书。 这意味着但凡有一家 CA 的验证流程出现问题，全球所有域名的安全性都将受其影响。 而 CAA 能帮助域名持有者减轻这一风险。 +CAA 是一类 DNS 记录，网站所有者可以通过它规定哪些证书颁发机构 (CA) 有权为其域名颁发证书。 2013 年 CAA 首次实现标准化，我们现在使用的则是 2019 年由 [RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659) 和 [RFC 8657](https://datatracker.ietf.org/doc/html/rfc8657) 修订的版本。默认情况下，只要核验了域名归属，所有公共 CA 都能为任一公开 DNS 域名颁发证书。这意味着但凡有一家 CA 的验证流程出现问题，全球所有域名的安全性都将受其影响。而 CAA 能帮助域名持有者减轻这一风险。 # 使用 CAA 记录 -如果您对 CAA 不感兴趣，那么一般无需执行任何操作（不过请参阅下文的“CAA 错误”一节）。 但如果您想借助 CAA 限制哪些 CA 能为您的域名颁发证书，就需要选择一家支持设置 CAA 记录的 DNS 服务商。 具体可查阅 [SSLMate 的 CAA 页面](https://sslmate.com/caa/support)， 如果其中包含您使用的服务商，就可以使用 [SSLMate 的 CAA 记录生成器](https://sslmate.com/caa/)生成一系列 CAA 记录，允许指定 CA 为您的域名颁发证书。 +如果您对 CAA 不感兴趣，那么一般无需执行任何操作（不过请参阅下文的“CAA 错误”一节）。但如果您想借助 CAA 限制哪些 CA 能为您的域名颁发证书，就需要选择一家支持设置 CAA 记录的 DNS 服务商。具体可查阅 [SSLMate 的 CAA 页面](https://sslmate.com/caa/support)，如果其中包含您使用的服务商，就可以使用 [SSLMate 的 CAA 记录生成器](https://sslmate.com/caa/)生成一系列 CAA 记录，允许指定 CA 为您的域名颁发证书。 ## 放置 CAA 记录的位置 -CAA 记录一般应在您注册的域名层级（如 example.org 或 mysite.co.uk）上设置， 这样对该域名和所有子域名（如 community.example.org）都能生效。 +CAA 记录一般应在您注册的域名层级（如 example.org 或 mysite.co.uk）上设置，这样对该域名和所有子域名（如 community.example.org）都能生效。 -需要注意的是，CA 只会遵循*最接近*待签发证书的域名的 CAA 记录。 也就是说，如果您为 www.community.example.org 域名申请证书，CA 会依次查询 www.community.example.org、community.example.org、example.org，直至找到 CAA 记录为止。 +需要注意的是，CA 只会遵循*最接近*待签发证书的域名的 CAA 记录。也就是说，如果您为 www.community.example.org 域名申请证书，CA 会依次查询 www.community.example.org、community.example.org、example.org，直至找到 CAA 记录为止。 -这也意味着您可以为子域名单独设置不同的 CAA。 例如，假设 example.org 网站由您自己架设，但 api.example.org 由云服务提供， 您就可以先在 example.org 上设置 CAA 记录，只允许 Let's Encrypt 为该域名及其所有子域名颁发证书；再在 api.example.org 上设置 CAA 记录，允许云服务厂商为该域名单独颁发证书。 +这也意味着您可以为子域名单独设置不同的 CAA。例如，假设 example.org 网站由您自己架设，但 api.example.org 由云服务提供，您就可以先在 example.org 上设置 CAA 记录，只允许 Let's Encrypt 为该域名及其所有子域名颁发证书；再在 api.example.org 上设置 CAA 记录，允许云服务厂商为该域名单独颁发证书。 -还要注意的是，CAA 查询与其他 DNS 查询一样会遵循 CNAME 记录。 假设 community.example.org 的 CNAME 指向 example.forum.com，CA 就会完全遵循 example.forum.com 的所有 CAA 记录。 域名设置 CNAME 后就不能再有其他任何记录，所以原域名与 CNAME 域名之间不会产生 CAA 的冲突。 +还要注意的是，CAA 查询与其他 DNS 查询一样会遵循 CNAME 记录。假设 community.example.org 的 CNAME 指向 example.forum.com，CA 就会完全遵循 example.forum.com 的所有 CAA 记录。域名设置 CNAME 后就不能再有其他任何记录，所以原域名与 CNAME 域名之间不会产生 CAA 的冲突。 ## 记录中应该包含什么 @@ -30,25 +30,25 @@ CAA 记录都应当遵循同样的基本格式： CAA ``` -其中 **flags** 就是一个整数，并且通常都是 `0`，表示没有设置任何标志位。 如果您愿意的话，也可以将 flags 设为 `128`，对应“关键位”，表示 CA 如果不理解 tag 字段的内容就必须立即拒绝颁发证书。 +其中 **flags** 就是一个整数，并且通常都是 `0`，表示没有设置任何标志位。如果您愿意的话，也可以将 flags 设为 `128`，对应“关键位”，表示 CA 如果不理解 tag 字段的内容就必须立即拒绝颁发证书。 -而 **tag** 则是一段字符串，表示该 CAA 记录的类型，内容通常是 `issue` 或 `issuewild`。 下文再详细介绍。 +而 **tag** 则是一段字符串，表示该 CAA 记录的类型，内容通常是 `issue` 或 `issuewild`。下文再详细介绍。 最后的 **value** 也是一段字符串，其中最多可以有一个 CA 的标识名（如 letsencrypt.org），以及若干由分号分隔的参数，如下文所述。 ### `issue` 和 `issuewild` -将 tag 设为 `issue` 即可控制哪些 CA 能为此域名及其子域名颁发证书。 这种记录对普通证书（如 example.org）和通配符证书（如 *.example.org）都有效，因此足以满足大部分需求。 只要将标识 CA 的域名置于 CAA 记录的 value 字段中就能允许该 CA 颁发证书。 +将 tag 设为 `issue` 即可控制哪些 CA 能为此域名及其子域名颁发证书。这种记录对普通证书（如 example.org）和通配符证书（如 *.example.org）都有效，因此足以满足大部分需求。只要将标识 CA 的域名置于 CAA 记录的 value 字段中就能允许该 CA 颁发证书。 -带有 `issuewild` tag 的记录则用于控制哪些 CA 能颁发*通配符*证书（如 *.example.org）。 只有在需要为通配符和非通配符证书设置不同的权限时才需要使用 `issuewild` 记录。 +带有 `issuewild` tag 的记录则用于控制哪些 CA 能颁发*通配符*证书（如 *.example.org）。只有在需要为通配符和非通配符证书设置不同的权限时才需要使用 `issuewild` 记录。 注意，多项记录可以具有相同的 tag，其效果将会*累加*，只要任意一项记录允许该 CA 颁发证书即可。 -Let's Encrypt 在 CAA 中的标识名为 `letsencrypt.org`， 这一名称已正式载入我们的[证书颁发制度暨运作声明第 4.2.1 节](https://cps.letsencrypt.org/#4.2.1-performing-identification-and-authentication-functions)。 +Let's Encrypt 在 CAA 中的标识名为 `letsencrypt.org`，这一名称已正式载入我们的[证书颁发制度暨运作声明第 4.2.1 节](https://cps.letsencrypt.org/#4.2.1-performing-identification-and-authentication-functions)。 ### `validationmethods` 参数 -此参数可以置于标识 CA 的域名后，用以控制 CA 可采取的域名控制权验证措施。 您可以借此要求 CA 使用您认为更可靠的验证方式。 例如，您可以在 CAA 记录的 value 字段末尾加上 `;validationmethods=tls-alpn-01`，强制 CA 通过 TLS-ALPN-01 的方式完成验证。 +此参数可以置于标识 CA 的域名后，用以控制 CA 可采取的域名控制权验证措施。您可以借此要求 CA 使用您认为更可靠的验证方式。例如，您可以在 CAA 记录的 value 字段末尾加上 `;validationmethods=tls-alpn-01`，强制 CA 通过 TLS-ALPN-01 的方式完成验证。 Let's Encrypt 接受以下验证方式： @@ -58,7 +58,7 @@ Let's Encrypt 接受以下验证方式： ### `accounturi` 参数 -此参数可以置于标识 CA 的域名后，用以控制哪些 ACME 账户能申请为该域名颁发证书。 这可以确保即使有人暂时劫持了您的域名，没有您的 ACME 账户密钥也无法恶意申请证书。 +此参数可以置于标识 CA 的域名后，用以控制哪些 ACME 账户能申请为该域名颁发证书。这可以确保即使有人暂时劫持了您的域名，没有您的 ACME 账户密钥也无法恶意申请证书。 Let's Encrypt 账户的 `accounturi` 形如 `https://acme-v02.api.letsencrypt.org/acme/acct/1234567890`，末尾的数字是您的账户 ID。 @@ -78,25 +78,25 @@ example.org CAA 0 issuewild "myca.org" example.org CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456" ``` -此例中 MyCA 可以为 example.org 颁发证书，但只能使用 DNS-01 验证方式。 该 CA 也可以使用任何验证方式颁发通配符证书。 另外，OtherCA 也能颁发证书，但申请者账户编号必须是 `123456`，且 OtherCA 必须能够识别并正确处理 `accounturi` 参数。 +此例中 MyCA 可以为 example.org 颁发证书，但只能使用 DNS-01 验证方式。该 CA 也可以使用任何验证方式颁发通配符证书。另外，OtherCA 也能颁发证书，但申请者账户编号必须是 `123456`，且 OtherCA 必须能够识别并正确处理 `accounturi` 参数。 # CAA 错误 -Let's Encrypt 颁发证书前都会检查 CAA 记录，但即使是未设置 CAA 的域名有时也会出现 DNS 查询错误， 这种情况下域名可能存在 CAA 记录，但我们无法获取，也就无从得知是否有权为该域名颁发证书。 +Let's Encrypt 颁发证书前都会检查 CAA 记录，但即使是未设置 CAA 的域名有时也会出现 DNS 查询错误，这种情况下域名可能存在 CAA 记录，但我们无法获取，也就无从得知是否有权为该域名颁发证书。 -如果遇到 CAA 相关的错误，可以在我们的[测试环境](/docs/staging-environment)中多试几次，观察错误是否消失。 如果同一错误反复出现，就需要向您的 DNS 提供商或迁移服务提供商寻求帮助。 如果无法确定 DNS 提供商，请向网站托管服务商咨询。 +如果遇到 CAA 相关的错误，可以在我们的[测试环境](/docs/staging-environment)中多试几次，观察错误是否消失。如果同一错误反复出现，就需要向您的 DNS 提供商或迁移服务提供商寻求帮助。如果无法确定 DNS 提供商，请向网站托管服务商咨询。 -某些不熟悉 CAA 的 DNS 提供商可能会辩称“我们不支持 CAA 记录”， 其实他们不必主动适配 CAA，只需对 CAA 等未知的 DNS 请求类型给予 NOERROR 响应即可。 事实上，对于未知的 QTYPE，其他的响应类型（包括 NOTIMP）都是违背 [RFC 1035](https://tools.ietf.org/html/rfc1035) 标准的，需要予以修复。 +某些不熟悉 CAA 的 DNS 提供商可能会辩称“我们不支持 CAA 记录”，其实他们不必主动适配 CAA，只需对 CAA 等未知的 DNS 请求类型给予 NOERROR 响应即可。事实上，对于未知的 QTYPE，其他的响应类型（包括 NOTIMP）都是违背 [RFC 1035](https://tools.ietf.org/html/rfc1035) 标准的，需要予以修复。 ## SERVFAIL -SERVFAIL 是最常见的一类错误， 通常由 DNSSEC 验证失败造成。 如果遇到 SERVFAIL 错误，首先应当借助 [dnsviz.net](http://dnsviz.net/) 等 DNSSEC 调试器加以排查。 如果未发现问题，可能是域名服务器只有在响应为空时才会生成错误的数字签名， 而 CAA 响应恰好经常是空的。 PowerDNS 4.0.3 以下版本[就有这一问题](https://community.letsencrypt.org/t/caa-servfail-changes/38298/2?u=jsha)。 +SERVFAIL 是最常见的一类错误，通常由 DNSSEC 验证失败造成。如果遇到 SERVFAIL 错误，首先应当借助 [dnsviz.net](http://dnsviz.net/) 等 DNSSEC 调试器加以排查。如果未发现问题，可能是域名服务器只有在响应为空时才会生成错误的数字签名，而 CAA 响应恰好经常是空的。 PowerDNS 4.0.3 以下版本[就有这一问题](https://community.letsencrypt.org/t/caa-servfail-changes/38298/2?u=jsha)。 -如果没有开启 DNSSEC，但还是遇到了 SERVFAIL 错误，另一常见原因便是权威域名服务器的响应为 NOTIMP。正如上文所述，这是违反 RFC 1035 标准的。正确的响应代码应是 NOERROR，且响应内容为空。 如果确实是这一问题，请向 DNS 提供商反馈。 +如果没有开启 DNSSEC，但还是遇到了 SERVFAIL 错误，另一常见原因便是权威域名服务器的响应为 NOTIMP。正如上文所述，这是违反 RFC 1035 标准的。正确的响应代码应是 NOERROR，且响应内容为空。如果确实是这一问题，请向 DNS 提供商反馈。 -最后，SERVFAIL 也可能是权威域名服务器崩溃导致的。 请检查域名 NS 记录，确认各域名服务器是否正常运转。 +最后，SERVFAIL 也可能是权威域名服务器崩溃导致的。请检查域名 NS 记录，确认各域名服务器是否正常运转。 ## 超时 -CAA 查询也有可能超时， 意即多次查询后权威服务器仍未作出任何响应。 其原因往往是域名服务器的防火墙配置不当，将类型未知的 DNS 查询报文一律丢弃。 请咨询 DNS 提供商是否存在此类防火墙。 +CAA 查询也有可能超时，意即多次查询后权威服务器仍未作出任何响应。其原因往往是域名服务器的防火墙配置不当，将类型未知的 DNS 查询报文一律丢弃。请咨询 DNS 提供商是否存在此类防火墙。 diff --git a/content/zh-cn/docs/cert-compat.md b/content/zh-cn/docs/cert-compat.md index a2831483a0..2ac2943771 100644 --- a/content/zh-cn/docs/cert-compat.md +++ b/content/zh-cn/docs/cert-compat.md @@ -6,9 +6,9 @@ show_lastmod: 1 --- -一个平台能否验证 Let's Encrypt 颁发的证书，关键在于该平台是否信任 ISRG 的 ISRG Root X1 或 ISRG Root X2 根证书。 这两份根证书在多年前（ISRG Root X1 于 2016 年末，ISRG Root X2 于 2022 年中）就已收录至各平台的证书库中，但用户普遍完成版本更新则可能需要更长的时间。 目前 ISRG Root X1 已经得到了广泛信任，但 ISRG Root X2 仍待普及。 +一个平台能否验证 Let's Encrypt 颁发的证书，关键在于该平台是否信任 ISRG 的 ISRG Root X1 或 ISRG Root X2 根证书。这两份根证书在多年前（ISRG Root X1 于 2016 年末，ISRG Root X2 于 2022 年中）就已收录至各平台的证书库中，但用户普遍完成版本更新则可能需要更长的时间。目前 ISRG Root X1 已经得到了广泛信任，但 ISRG Root X2 仍待普及。 -如果您的证书只能在部分已知的兼容平台上通过验证，原因可能是网站服务器配置不当。 如果您在较新的系统中遇到问题，最常见的原因是网站没有提供正确的证书链。 您可以使用 [SSL Labs 的服务器测试](https://www.ssllabs.com/ssltest/)来测试您站点的兼容性。 如果通过这项测试仍不能确定原因，可以在我们的[社群论坛](https://community.letsencrypt.org/)中寻求帮助。 +如果您的证书只能在部分已知的兼容平台上通过验证，原因可能是网站服务器配置不当。如果您在较新的系统中遇到问题，最常见的原因是网站没有提供正确的证书链。您可以使用 [SSL Labs 的服务器测试](https://www.ssllabs.com/ssltest/)来测试您站点的兼容性。如果通过这项测试仍不能确定原因，可以在我们的[社群论坛](https://community.letsencrypt.org/)中寻求帮助。 如果您的平台尚未在下方列出，欢迎提交 [Pull Request](https://github.com/letsencrypt/website/blob/main/content/en/docs/cert-compat.md) 予以补充，同时请引用官方文档注明该平台收录各根证书的时间。 diff --git a/content/zh-cn/docs/cert-lifetimes.md b/content/zh-cn/docs/cert-lifetimes.md index 9c03a3e0c4..0e1bbb835d 100644 --- a/content/zh-cn/docs/cert-lifetimes.md +++ b/content/zh-cn/docs/cert-lifetimes.md @@ -7,7 +7,7 @@ show_lastmod: 1 ## 目前的证书有效期 -从 2015 年创立以来，Let's Encrypt 就提供了 90 天有效的证书。 这一默认有效期将保持不变，我们签发的大部分证书有效期也都是 90 天。 +从 2015 年创立以来，Let's Encrypt 就提供了 90 天有效的证书。这一默认有效期将保持不变，我们签发的大部分证书有效期也都是 90 天。 另一方面，所有用户都可以选择申请 6 天有效的短期证书。 @@ -15,7 +15,7 @@ show_lastmod: 1 ## 未来的计划 -根据[行业规则](https://cabforum.org/working-groups/server/baseline-requirements/documents/)，从 2029 年 3 月 15 日起，证书有效期不能超过 47 天。 因此，我们将[于 2028 年 2 月将证书有效期上限缩短至 45 天](/2025/12/02/from-90-to-45.html)。 +根据[行业规则](https://cabforum.org/working-groups/server/baseline-requirements/documents/)，从 2029 年 3 月 15 日起，证书有效期不能超过 47 天。因此，我们将[于 2028 年 2 月将证书有效期上限缩短至 45 天](/2025/12/02/from-90-to-45.html)。 ## 为什么要缩短有效期？ @@ -23,7 +23,7 @@ show_lastmod: 1 缩短有效期的主要原因有两个： -- 减轻签发不当和密钥泄露导致的危害。 即使证书的签发流程存在问题，或者在签发前后发生密钥泄露，这份证书产生影响的时间也会比较短。 -- 鼓励自动化，从而大幅提升易用性与可靠性。 只要将证书管理流程自动化，有效期的长短就不会造成任何不便。 +- 减轻签发不当和密钥泄露导致的危害。即使证书的签发流程存在问题，或者在签发前后发生密钥泄露，这份证书产生影响的时间也会比较短。 +- 鼓励自动化，从而大幅提升易用性与可靠性。只要将证书管理流程自动化，有效期的长短就不会造成任何不便。 -起初我们选择将有效期定为 90 天，因为 90 天一方面足够短，能够促进自动化；另一方面也足够长，手动续期同样可行。 尽管我们希望推动自动化，但这只是次要目标，更重要的还是普及 HTTPS。 当时自动签发证书远不如现在一般常见，原因之一就是工具生态（如 ACME 客户端）不成熟。 而现如今情况已大不相同，全自动的证书管理流程屡见不鲜，工具生态也更加丰富。 因此，我们现在有更为充分的条件推行有效期短于 90 天的证书。 +起初我们选择将有效期定为 90 天，因为 90 天一方面足够短，能够促进自动化；另一方面也足够长，手动续期同样可行。尽管我们希望推动自动化，但这只是次要目标，更重要的还是普及 HTTPS。当时自动签发证书远不如现在一般常见，原因之一就是工具生态（如 ACME 客户端）不成熟。而现如今情况已大不相同，全自动的证书管理流程屡见不鲜，工具生态也更加丰富。因此，我们现在有更为充分的条件推行有效期短于 90 天的证书。 diff --git a/content/zh-cn/docs/certificates-for-localhost.md b/content/zh-cn/docs/certificates-for-localhost.md index 1c58417f9a..74d2da8d21 100644 --- a/content/zh-cn/docs/certificates-for-localhost.md +++ b/content/zh-cn/docs/certificates-for-localhost.md @@ -5,33 +5,33 @@ lastmod: 2025-07-31 show_lastmod: 1 --- -有时，人们希望获得主机名为“localhost”的证书，以用于本地开发或与需要与 Web 应用程序通信的原生应用程序一同分发。 Let’s Encrypt 不能为“localhost”提供证书，因为没有人唯一地拥有它，并且它不在“.com”或“.net”等顶级域名下。 您可以将您自己的域名设置为解析至“127.0.0.1”，并使用 DNS 验证获取证书。 然而，通常情况下这是个坏主意，您其实有更好的选择。 +有时，人们希望获得主机名为“localhost”的证书，以用于本地开发或与需要与 Web 应用程序通信的原生应用程序一同分发。 Let’s Encrypt 不能为“localhost”提供证书，因为没有人唯一地拥有它，并且它不在“.com”或“.net”等顶级域名下。您可以将您自己的域名设置为解析至“127.0.0.1”，并使用 DNS 验证获取证书。然而，通常情况下这是个坏主意，您其实有更好的选择。 # 用于本地开发目的 -如果您正在开发 Web 应用程序，那么您可能需要运行 Apache 或 Nginx 等本地 Web 服务器并在浏览器中通过 `http://localhost:8000/` 访问它。 但是，浏览器在 HTTP 与 HTTPS 页面上的行为方式略有不同。 主要区别是：在 HTTPS 页面上，从 HTTP 链接加载 JavaScript 的请求都会被阻断。 因此，若您在本地使用 HTTP 开发，您添加的脚本可能能在本地开发环境正常工作，但是将在部署至 HTTPS 站点时出现问题。 若要发现此类问题，您可能需要在本地 Web 服务器配置 HTTPS。 但是，您不希望始终看到证书错误警告。 那么如何在访问本地网页版本时让浏览器显示那个绿色锁标志呢？ +如果您正在开发 Web 应用程序，那么您可能需要运行 Apache 或 Nginx 等本地 Web 服务器并在浏览器中通过 `http://localhost:8000/` 访问它。但是，浏览器在 HTTP 与 HTTPS 页面上的行为方式略有不同。主要区别是：在 HTTPS 页面上，从 HTTP 链接加载 JavaScript 的请求都会被阻断。因此，若您在本地使用 HTTP 开发，您添加的脚本可能能在本地开发环境正常工作，但是将在部署至 HTTPS 站点时出现问题。若要发现此类问题，您可能需要在本地 Web 服务器配置 HTTPS。但是，您不希望始终看到证书错误警告。那么如何在访问本地网页版本时让浏览器显示那个绿色锁标志呢？ -最佳选择是：生成您自己的证书（自签名的或由本地根证书签名），并且可以在您的操作系统的受信证书存储中信任它。 然后在本地网页服务器中使用该证书。 请参阅下文了解详情。 +最佳选择是：生成您自己的证书（自签名的或由本地根证书签名），并且可以在您的操作系统的受信证书存储中信任它。然后在本地网页服务器中使用该证书。请参阅下文了解详情。 # 用于与 Web 应用通信的原生应用 -有时开发人员希望提供可下载的原生应用程序，可以与网站一起使用以提供额外的功能。 例如，Dropbox 和 Spotify 桌面应用程序会扫描您机器上的文件，而网页版无法进行此操作。 一种常见的解决方案是让这些原生应用程序在 localhost 上提供 Web 服务，由 Web 应用通过 XMLHttpRequest (XHR) 或 WebSockets 与之通信。 Web 应用程序基本上都使用了 HTTPS，这意味着浏览器将禁止它向非安全链接发送 XHR 或 WebSockets 请求。 这称为混合内容阻断。 要与 Web 应用程序通信，原生应用程序需要提供安全的 Web 服务。 +有时开发人员希望提供可下载的原生应用程序，可以与网站一起使用以提供额外的功能。例如，Dropbox 和 Spotify 桌面应用程序会扫描您机器上的文件，而网页版无法进行此操作。一种常见的解决方案是让这些原生应用程序在 localhost 上提供 Web 服务，由 Web 应用通过 XMLHttpRequest (XHR) 或 WebSockets 与之通信。 Web 应用程序基本上都使用了 HTTPS，这意味着浏览器将禁止它向非安全链接发送 XHR 或 WebSockets 请求。这称为混合内容阻断。要与 Web 应用程序通信，原生应用程序需要提供安全的 Web 服务。 -幸运的是，现代浏览器[认为][mcb-localhost] `http://127.0.0.1:8000/` 是一个 [“可能可信赖的”][secure-contexts]链接，因为它指向一个环回地址。 发送到 `127.0.0.1` 的流量肯定不会离开您的计算机，因此它自然而然地不受网络拦截的影响。 这意味着如果您的 Web 应用程序使用HTTPS，并且您在 `127.0.0.1` 上提供原生应用程序的 Web 服务，则两者可以通过 XHR 进行通信。 不幸的是，[localhost 没有受到相同的待遇][let-localhost]。 此外，在 WebSockets 中这两类地址都不会受到特殊对待。 +幸运的是，现代浏览器[认为][mcb-localhost] `http://127.0.0.1:8000/` 是一个 [“可能可信赖的”][secure-contexts]链接，因为它指向一个环回地址。发送到 `127.0.0.1` 的流量肯定不会离开您的计算机，因此它自然而然地不受网络拦截的影响。这意味着如果您的 Web 应用程序使用HTTPS，并且您在 `127.0.0.1` 上提供原生应用程序的 Web 服务，则两者可以通过 XHR 进行通信。不幸的是，[localhost 没有受到相同的待遇][let-localhost]。此外，在 WebSockets 中这两类地址都不会受到特殊对待。 -您可能会想到一些规避的方法，例如在公网 DNS 中注册一个解析到 `127.0.0.1` 的域名（如 `localhost.example.com`），申请该域名的证书，并将证书及私钥与原生应用程序共同分发，这样就能让 Web 应用与 `https://localhost.example.com:8000/`（而非 `http://127.0.0.1:8000/`）通信了。 *但请不要这样做。*这会给您的用户带来安全风险，您的证书也可能会被吊销。 +您可能会想到一些规避的方法，例如在公网 DNS 中注册一个解析到 `127.0.0.1` 的域名（如 `localhost.example.com`），申请该域名的证书，并将证书及私钥与原生应用程序共同分发，这样就能让 Web 应用与 `https://localhost.example.com:8000/`（而非 `http://127.0.0.1:8000/`）通信了。*但请不要这样做。*这会给您的用户带来安全风险，您的证书也可能会被吊销。 -由于您使用的是域名而非 IP 地址，攻击者可以作为中间人 (MitM) 劫持 DNS 查询，将域名指向其他 IP 地址。 这可能会导致您在 Web 应用程序上的帐户遭到入侵，具体取决于其设计方式。 +由于您使用的是域名而非 IP 地址，攻击者可以作为中间人 (MitM) 劫持 DNS 查询，将域名指向其他 IP 地址。这可能会导致您在 Web 应用程序上的帐户遭到入侵，具体取决于其设计方式。 -这种中间人攻击之所以能够奏效，是因为证书的私钥必然要和原生应用程序捆绑分发， 这意味着任何人只要下载了应用程序就能获得私钥，包括攻击者在内。 这等同于您的私钥泄露，证书颁发机构一旦知情就有义务将该证书吊销。 [很多原生应用程序][mdsp1]都是因为[携带私钥][mdsp3]而被[吊销了证书][mdsp2]。 +这种中间人攻击之所以能够奏效，是因为证书的私钥必然要和原生应用程序捆绑分发，这意味着任何人只要下载了应用程序就能获得私钥，包括攻击者在内。这等同于您的私钥泄露，证书颁发机构一旦知情就有义务将该证书吊销。[很多原生应用程序][mdsp1]都是因为[携带私钥][mdsp3]而被[吊销了证书][mdsp2]。 -不幸的是，这也意味着原生应用很难找到足够安全的途径与其网站通信。 如果浏览器进一步[缩紧来自 Web 的对 localhost 的访问][tighten-access]，将来情况可能会变得更加棘手。 +不幸的是，这也意味着原生应用很难找到足够安全的途径与其网站通信。如果浏览器进一步[缩紧来自 Web 的对 localhost 的访问][tighten-access]，将来情况可能会变得更加棘手。 -还需要注意的是，原生应用程序通过 Web API 提供权限较高的功能本身就存在风险，因为这样的接口可能会被其他网站恶意调用。 如果您执意这么做，请务必了解[跨源资源共享][cors]并使用 Access-Control-Allow-Origin。另外还要确保使用内存安全的 HTTP 解析器，因为其他网站即使无权调用接口也可以发送预检请求，从而利用解析器中的漏洞发动攻击。 +还需要注意的是，原生应用程序通过 Web API 提供权限较高的功能本身就存在风险，因为这样的接口可能会被其他网站恶意调用。如果您执意这么做，请务必了解[跨源资源共享][cors]并使用 Access-Control-Allow-Origin。另外还要确保使用内存安全的 HTTP 解析器，因为其他网站即使无权调用接口也可以发送预检请求，从而利用解析器中的漏洞发动攻击。 # 制作并信任您自己的证书 -任何人都可以在没有 CA 帮助的情况下制作自己的证书。 唯一的区别是您自己制作的证书不会被其他任何人信任。 当然如果用于本地开发，那没什么关系。 +任何人都可以在没有 CA 帮助的情况下制作自己的证书。唯一的区别是您自己制作的证书不会被其他任何人信任。当然如果用于本地开发，那没什么关系。 为 localhost 生成私钥和自签名证书的最简单方法是使用以下 openssl 命令： @@ -42,9 +42,9 @@ show_lastmod: 1 然后，您就可以使用 localhost.crt 和 localhost.key 配置本地 Web 服务器，并在本地的受信任根证书列表中安装 localhost.crt。 -如果您希望您的开发用证书更加逼真，您可以使用 [ mkcert ][mkcert] 生成自己的本地根证书，并颁发由其签名的终端实体证书（又称叶证书）。 然后，您就可以导入根证书而不是自签名的终端实体证书。 +如果您希望您的开发用证书更加逼真，您可以使用 [ mkcert ][mkcert] 生成自己的本地根证书，并颁发由其签名的终端实体证书（又称叶证书）。然后，您就可以导入根证书而不是自签名的终端实体证书。 -您还可以选择使用多级域名，例如将 `www.localhost` 作为 `127.0.0.1` 的别名加入 /etc/hosts 中， 这对于浏览器处理 Cookie 的方式有一定的影响。 +您还可以选择使用多级域名，例如将 `www.localhost` 作为 `127.0.0.1` 的别名加入 /etc/hosts 中，这对于浏览器处理 Cookie 的方式有一定的影响。 [mcb-localhost]: https://bugs.chromium.org/p/chromium/issues/detail?id=607878 [secure-contexts]: https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy diff --git a/content/zh-cn/docs/challenge-types.md b/content/zh-cn/docs/challenge-types.md index 6cb5cc873c..a5d129cd07 100644 --- a/content/zh-cn/docs/challenge-types.md +++ b/content/zh-cn/docs/challenge-types.md @@ -6,15 +6,15 @@ show_lastmod: 1 --- -当您从 Let's Encrypt 获得证书时，我们的服务器会验证您是否使用 ACME 标准定义的验证方式来验证您对证书中域名的控制权。 大多数情况下，验证由 ACME 客户端自动处理，但如果您需要做出一些更复杂的配置决策，那么了解更多有关它们的信息会很有用。 如果您不确定怎么做，请使用您的客户端的默认设置或使用 HTTP-01。 +当您从 Let's Encrypt 获得证书时，我们的服务器会验证您是否使用 ACME 标准定义的验证方式来验证您对证书中域名的控制权。大多数情况下，验证由 ACME 客户端自动处理，但如果您需要做出一些更复杂的配置决策，那么了解更多有关它们的信息会很有用。如果您不确定怎么做，请使用您的客户端的默认设置或使用 HTTP-01。 # HTTP-01 验证 -这是当今最常见的验证方式。 Let’s Encrypt 向您的 ACME 客户端提供一个令牌，然后您的 ACME 客户端将在您对 Web 服务器的 `http://<你的域名>/.well-known/acme-challenge/`（用提供的令牌替换 ``）路径上放置指定文件。 该文件包含令牌以及帐户密钥的指纹。 一旦您的 ACME 客户端告诉 Let's Encrypt 文件已准备就绪，Let's Encrypt 会尝试获取它（可能从多个地点进行多次尝试）。 如果我们的验证机制在您的 Web 服务器上找到了放置于正确地点的正确文件，则该验证被视为成功，您可以继续申请颁发证书。 如果验证检查失败，您将不得不再次使用新证书重新申请。 +这是当今最常见的验证方式。 Let’s Encrypt 向您的 ACME 客户端提供一个令牌，然后您的 ACME 客户端将在您对 Web 服务器的 `http://<你的域名>/.well-known/acme-challenge/`（用提供的令牌替换 ``）路径上放置指定文件。该文件包含令牌以及帐户密钥的指纹。一旦您的 ACME 客户端告诉 Let's Encrypt 文件已准备就绪，Let's Encrypt 会尝试获取它（可能从多个地点进行多次尝试）。如果我们的验证机制在您的 Web 服务器上找到了放置于正确地点的正确文件，则该验证被视为成功，您可以继续申请颁发证书。如果验证检查失败，您将不得不再次使用新证书重新申请。 -我们的 HTTP-01 验证最多接受 10 次重定向。 我们只接受目标为“http:”或“https:”且端口为 80 或 443 的重定向。 当被重定向到 HTTPS 链接时，我们不会验证证书是否有效（因为验证的目的是申请有效证书，所以它可能会遇到自签名或过期的证书）。 +我们的 HTTP-01 验证最多接受 10 次重定向。我们只接受目标为“http:”或“https:”且端口为 80 或 443 的重定向。当被重定向到 HTTPS 链接时，我们不会验证证书是否有效（因为验证的目的是申请有效证书，所以它可能会遇到自签名或过期的证书）。 -HTTP-01 验证只能使用 80 端口。 因为允许客户端指定任意端口会降低安全性，所以 ACME 标准已禁止此行为。 +HTTP-01 验证只能使用 80 端口。因为允许客户端指定任意端口会降低安全性，所以 ACME 标准已禁止此行为。 优点： @@ -31,17 +31,17 @@ HTTP-01 验证只能使用 80 端口。 因为允许客户端指定任意端口 # DNS-01 验证 -此验证方式要求您在该域名下的 TXT 记录中放置特定值来证明您控制域名的 DNS 系统。 该配置比 HTTP-01 略困难，但可以在某些 HTTP-01 不可用的情况下工作。 它还允许您颁发通配符证书。 在 Let’s Encrypt 为您的 ACME 客户端提供令牌后，您的客户端将创建从该令牌和您的帐户密钥派生的 TXT 记录，并将该记录放在 `_acme-challenge.` 下。 然后 Let’s Encrypt 将向 DNS 系统查询该记录。 如果找到匹配项，您就可以继续颁发证书！ +此验证方式要求您在该域名下的 TXT 记录中放置特定值来证明您控制域名的 DNS 系统。该配置比 HTTP-01 略困难，但可以在某些 HTTP-01 不可用的情况下工作。它还允许您颁发通配符证书。在 Let’s Encrypt 为您的 ACME 客户端提供令牌后，您的客户端将创建从该令牌和您的帐户密钥派生的 TXT 记录，并将该记录放在 `_acme-challenge.` 下。然后 Let’s Encrypt 将向 DNS 系统查询该记录。如果找到匹配项，您就可以继续颁发证书！ -由于颁发和续期的自动化非常重要，只有当您的 DNS 提供商拥有可用于自动更新的 API 时，使用 DNS-01 验证方式才有意义。 我们的社区在[此处提供了此类 DNS 提供商的列表][dns-api-providers]。 您的 DNS 提供商与域名注册商（即向您出售域名的公司）可能相同，也可能不同。 如果您想更改 DNS 提供商，只需在注册商处进行一些小的更改， 无需等待域名即将到期。 +由于颁发和续期的自动化非常重要，只有当您的 DNS 提供商拥有可用于自动更新的 API 时，使用 DNS-01 验证方式才有意义。我们的社区在[此处提供了此类 DNS 提供商的列表][dns-api-providers]。您的 DNS 提供商与域名注册商（即向您出售域名的公司）可能相同，也可能不同。如果您想更改 DNS 提供商，只需在注册商处进行一些小的更改，无需等待域名即将到期。 -需要注意的是，如果将具备完整权限的 DNS API 凭据置于网页服务器上，服务器一旦被黑客攻破会造成更为严重的影响。 最佳做法是使用[权限范围受限的 API 凭据][securing-dns-credentials]，或在单独的服务器上执行 DNS 验证并自动将证书复制到 Web 服务器上。 +需要注意的是，如果将具备完整权限的 DNS API 凭据置于网页服务器上，服务器一旦被黑客攻破会造成更为严重的影响。最佳做法是使用[权限范围受限的 API 凭据][securing-dns-credentials]，或在单独的服务器上执行 DNS 验证并自动将证书复制到 Web 服务器上。 -由于 Let’s Encrypt 在查找用于 DNS-01 验证的 TXT 记录时遵循 DNS 标准，因此您可以使用 CNAME 记录或 NS 记录将验证工作委派给其他 DNS 区域。 这可以用于[将 `_acme-challenge` 子域名委派][securing-dns-credentials]给验证专用的服务器或区域。 如果您的 DNS 提供商更新速度很慢，那么您也可以使用此方法把验证工作委派给更新速度更快的服务器。 +由于 Let’s Encrypt 在查找用于 DNS-01 验证的 TXT 记录时遵循 DNS 标准，因此您可以使用 CNAME 记录或 NS 记录将验证工作委派给其他 DNS 区域。这可以用于[将 `_acme-challenge` 子域名委派][securing-dns-credentials]给验证专用的服务器或区域。如果您的 DNS 提供商更新速度很慢，那么您也可以使用此方法把验证工作委派给更新速度更快的服务器。 -大多数 DNS 提供商都有一个“更新时间”，它反映了从更新 DNS 记录到其在所有服务器上都可用所需的时间。 这个时间可能很难测量，因为这些提供商通常也使用[任播][]，这意味着多个服务器可以拥有相同的 IP 地址，并且根据您在世界上的位置，您和 Let’s Encrypt 可能会与不同的服务器通信（并获得不同的应答）。 最好的情况是 DNS API 为您提供了自动检查更新是否完成的方法。 如果您的 DNS 提供商没有这样的方法，您只需将客户端配置为等待足够长的时间（通常多达一个小时），以确保在触发验证之前更新已经完全完成。 +大多数 DNS 提供商都有一个“更新时间”，它反映了从更新 DNS 记录到其在所有服务器上都可用所需的时间。这个时间可能很难测量，因为这些提供商通常也使用[任播][]，这意味着多个服务器可以拥有相同的 IP 地址，并且根据您在世界上的位置，您和 Let’s Encrypt 可能会与不同的服务器通信（并获得不同的应答）。最好的情况是 DNS API 为您提供了自动检查更新是否完成的方法。如果您的 DNS 提供商没有这样的方法，您只需将客户端配置为等待足够长的时间（通常多达一个小时），以确保在触发验证之前更新已经完全完成。 -您可以为同一名称提供多个 TXT 记录。 例如，如果您同时验证通配符和非通配符证书，那么这种情况可能会发生。 但是，您应该确保清理旧的 TXT 记录，因为如果响应大小太大，Let's Encrypt 将拒绝该记录。 +您可以为同一名称提供多个 TXT 记录。例如，如果您同时验证通配符和非通配符证书，那么这种情况可能会发生。但是，您应该确保清理旧的 TXT 记录，因为如果响应大小太大，Let's Encrypt 将拒绝该记录。 优点： @@ -58,9 +58,9 @@ HTTP-01 验证只能使用 80 端口。 因为允许客户端指定任意端口 # TLS-ALPN-01验证 -这一验证类型是在 TLS-SNI-01 被废除后开发的，现已在 [RFC 8737][tls-alpn] 中实现标准化。 与 TLS-SNI-01 一样，它通过 443 端口上的 TLS 执行。 但是，它使用自定义的 ALPN 协议来确保只有知道此验证类型的服务器才会响应验证请求。 这还允许对此质询类型的验证请求使用与要验证的域名匹配的SNI字段，从而使其更安全。 +这一验证类型是在 TLS-SNI-01 被废除后开发的，现已在 [RFC 8737][tls-alpn] 中实现标准化。与 TLS-SNI-01 一样，它通过 443 端口上的 TLS 执行。但是，它使用自定义的 ALPN 协议来确保只有知道此验证类型的服务器才会响应验证请求。这还允许对此质询类型的验证请求使用与要验证的域名匹配的SNI字段，从而使其更安全。 -这一验证类型并不适合大多数人。 它最适合那些想要执行类似于 HTTP-01 的基于主机的验证，但希望它完全在 TLS 层进行以分离关注点的 TLS 反向代理的作者。 目前这一群体主要是大型的网站托管服务商。 +这一验证类型并不适合大多数人。它最适合那些想要执行类似于 HTTP-01 的基于主机的验证，但希望它完全在 TLS 层进行以分离关注点的 TLS 反向代理的作者。目前这一群体主要是大型的网站托管服务商。 优点： @@ -76,7 +76,7 @@ HTTP-01 验证只能使用 80 端口。 因为允许客户端指定任意端口 # TLS-SNI-01验证 -ACME 的草案版本中定义了这一验证方式。 其原理是与 443 端口执行 TLS 握手时使用特殊的 [SNI][] 字段，并验证证书是否包含特定信息。 这种方式不够安全，因此已[于 2019 年 3 月被废除][tls-sni-disablement]。 +ACME 的草案版本中定义了这一验证方式。其原理是与 443 端口执行 TLS 握手时使用特殊的 [SNI][] 字段，并验证证书是否包含特定信息。这种方式不够安全，因此已[于 2019 年 3 月被废除][tls-sni-disablement]。 [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 diff --git a/content/zh-cn/docs/client-options.md b/content/zh-cn/docs/client-options.md index b1d46c3b4b..66cb3bfd59 100644 --- a/content/zh-cn/docs/client-options.md +++ b/content/zh-cn/docs/client-options.md @@ -6,7 +6,7 @@ lastmod: 2025-01-22 {{< clientslastmod >}} -Let's Encrypt 使用 ACME 协议来验证您对给定域名的控制权并向您颁发证书。 要获得 Let's Encrypt 证书，您需要选择一个要使用的 ACME 客户端软件。 +Let's Encrypt 使用 ACME 协议来验证您对给定域名的控制权并向您颁发证书。要获得 Let's Encrypt 证书，您需要选择一个要使用的 ACME 客户端软件。 下列 ACME 客户端由第三方提供。 Let's Encrypt 不控制或审查第三方客户端，也不能保证其安全性或可靠性。 @@ -14,13 +14,13 @@ Let's Encrypt 使用 ACME 协议来验证您对给定域名的控制权并向您 # 推荐客户端：Certbot -我们建议大多数人从 [Certbot](https://certbot.eff.org/) 客户端开始。 它既可以只为您获取证书，也可以帮助您获取并安装证书。 它易于使用，适用于许多操作系统，并且具有出色的文档。 +我们建议大多数人从 [Certbot](https://certbot.eff.org/) 客户端开始。它既可以只为您获取证书，也可以帮助您获取并安装证书。它易于使用，适用于许多操作系统，并且具有出色的文档。 如果 Certbot 不能满足您的需求，或者您只是想尝试其他软件，那么下面有更多的客户端可供选择，这些客户端按照编写所用的语言或是使用环境排序。 # 其他客户端 -下列客户端均支持 ACMEv2 API ([RFC 8555](https://tools.ietf.org/html/rfc8555))。 2021 年 6 月起我们已[彻底废除 ACMEv1](https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/27)。 如果您使用的客户端在该列表中，请确保您将其升级到最新版本。 如果下面没有列出您正在使用的客户端，则该客户端有几率不支持ACMEv2 API，请与项目维护者联系或更换其他客户端。 +下列客户端均支持 ACMEv2 API ([RFC 8555](https://tools.ietf.org/html/rfc8555))。 2021 年 6 月起我们已[彻底废除 ACMEv1](https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/27)。如果您使用的客户端在该列表中，请确保您将其升级到最新版本。如果下面没有列出您正在使用的客户端，则该客户端有几率不支持ACMEv2 API，请与项目维护者联系或更换其他客户端。 {{< clients libraries="库" projects="集成了 Let’s Encrypt 的项目" >}} @@ -40,4 +40,4 @@ Python 模块[acme](https://github.com/certbot/certbot/tree/main/acme) 是 Certb 1. 您在修改代码时将该客户端添加至相关列表的**末尾**。 1. 您的提交更新了 `clients.json` 顶部的 `lastmod` 日期戳。 -我们可能会定期移除停止维护的客户端或项目。 如果将来开发进程恢复，欢迎再次发起 Pull Request 重新将该项目加入列表中。 +我们可能会定期移除停止维护的客户端或项目。如果将来开发进程恢复，欢迎再次发起 Pull Request 重新将该项目加入列表中。 diff --git a/content/zh-cn/docs/ct-logs.html b/content/zh-cn/docs/ct-logs.html index 93834460c8..c316ccc6b0 100644 --- a/content/zh-cn/docs/ct-logs.html +++ b/content/zh-cn/docs/ct-logs.html @@ -7,12 +7,12 @@

- 证书透明化 (CT) 是一套记录并监控 TLS 证书颁发流程的系统。 CT 使普通人观察、研究证书颁发过程的能力大幅增强，有力地促进了 CA 生态系统和网络安全的发展。 因此，CT 正迅速成为关键基础设施。 + 证书透明化 (CT) 是一套记录并监控 TLS 证书颁发流程的系统。 CT 使普通人观察、研究证书颁发过程的能力大幅增强，有力地促进了 CA 生态系统和网络安全的发展。因此，CT 正迅速成为关键基础设施。

- Let's Encrypt 签发的所有证书都会录入 CT 日志。 同时我们也运作着若干 CT 日志系统， - 欢迎所有可信的证书颁发机构将证书提交至我们的日志。 我们的CT日志中已包含许多证书颁发机构的根证书。 如果您所经营的证书颁发机构不在我们的可信颁发者列表中，请在此处发起 Issue。 + Let's Encrypt 签发的所有证书都会录入 CT 日志。同时我们也运作着若干 CT 日志系统， + 欢迎所有可信的证书颁发机构将证书提交至我们的日志。我们的CT日志中已包含许多证书颁发机构的根证书。如果您所经营的证书颁发机构不在我们的可信颁发者列表中，请在此处发起 Issue。

@@ -61,7 +61,7 @@

已停止服务的 RFC 6962 日志系统

日志操作

- 以下示例使用的是 Sycamore 2026h2 分片。 我们的日志按时间分片，每一片区只包含到期时间落在对应范围内的证书，因此需要先在日志系统首页找到待查询证书所在的分片。 + 以下示例使用的是 Sycamore 2026h2 分片。我们的日志按时间分片，每一片区只包含到期时间落在对应范围内的证书，因此需要先在日志系统首页找到待查询证书所在的分片。

如需查看某一 CT 日志系统包含的所有根证书，可以在任意 UNIX 命令行中执行以下命令： @@ -73,7 +73,7 @@

日志操作

- 将证书提交至 CT 日志的操作通常由证书颁发机构完成。 如果您想尝试自行提交，可以先获取任一网站的 PEM 格式证书， 例如执行下列命令： + 将证书提交至 CT 日志的操作通常由证书颁发机构完成。如果您想尝试自行提交，可以先获取任一网站的 PEM 格式证书，例如执行下列命令： 

 $ echo | \
@@ -85,10 +85,10 @@ 
日志操作

- 证书需要以特定的 JSON 格式提交， 您可以使用 https://crt.sh/gen-add-chain 提供的 JSON 生成器完成格式转换。 该页面会生成一份 JSON 文件， 您需要下载并按需重新命名此文件，然后通过以下命令执行证书链添加操作（参见 https://crt.sh/gen-add-chain 提供的 JSON 生成器完成格式转换。该页面会生成一份 JSON 文件，您需要下载并按需重新命名此文件，然后通过以下命令执行证书链添加操作（参见 RFC 6962 的 4.1 节），将证书提交至 CT 日志系统。 我们的静态 CT 日志接口格式与 RFC 6962 一致。 该命令的输出中有一段数字签名，其内容实际上就是 SCT。 下文将进一步介绍这一数字签名。 +>），将证书提交至 CT 日志系统。我们的静态 CT 日志接口格式与 RFC 6962 一致。该命令的输出中有一段数字签名，其内容实际上就是 SCT。下文将进一步介绍这一数字签名。 

 $ curl \
@@ -110,7 +110,7 @@ 
日志操作

- 数字签名字段可用于验证证书是否已提交至日志系统。 您可以阅读我们的英文博客 SCT deep dive guide 了解如何进一步解码其内容。

diff --git a/content/zh-cn/docs/dst-root-ca-x3-expiration-september-2021.md b/content/zh-cn/docs/dst-root-ca-x3-expiration-september-2021.md index 7c63dc2521..9c941dd2e4 100644 --- a/content/zh-cn/docs/dst-root-ca-x3-expiration-september-2021.md +++ b/content/zh-cn/docs/dst-root-ca-x3-expiration-september-2021.md @@ -5,19 +5,19 @@ lastmod: 2024-02-05 show_lastmod: 1 --- -> **2024 年 2 月 5 日更新**：经过了两年的时间，下文所述用于兼容 Android 的交叉签名也已临近到期。 请参阅[我们近期的博客文章](https://letsencrypt.org/2023/07/10/cross-sign-expiration)详细了解 2024 年将要发生的变化。 +> **2024 年 2 月 5 日更新**：经过了两年的时间，下文所述用于兼容 Android 的交叉签名也已临近到期。请参阅[我们近期的博客文章](https://letsencrypt.org/2023/07/10/cross-sign-expiration)详细了解 2024 年将要发生的变化。 -> **2021 年 9 月 30 日更新**：DST Root CA X3 的交叉签名已如期失效，现在几乎所有设备的证书信任都由我们自己的 ISRG Root X1 根证书实现。 详细计划，请见下文！ 我们也在社群论坛上更新了关于生产环境证书链变化的讨论帖，如果您对此有任何疑问，[我们的团队和社群都将倾力相助](https://community.letsencrypt.org/t/production-chain-changes/150739/4)。 +> **2021 年 9 月 30 日更新**：DST Root CA X3 的交叉签名已如期失效，现在几乎所有设备的证书信任都由我们自己的 ISRG Root X1 根证书实现。详细计划，请见下文！我们也在社群论坛上更新了关于生产环境证书链变化的讨论帖，如果您对此有任何疑问，[我们的团队和社群都将倾力相助](https://community.letsencrypt.org/t/production-chain-changes/150739/4)。 -2021年9月30日，旧浏览器和设备信任Let’s Encrypt 证书的方式会有一些微小的变化。 如果您运行的是一个常规的网站， 您不会注意到任何变化，绝大多数访客仍然会接受您的 Let’s Encrypt 证书。 如果您提供 API 或必须支持物联网设备，您可能需要多注意更改。 +2021年9月30日，旧浏览器和设备信任Let’s Encrypt 证书的方式会有一些微小的变化。如果您运行的是一个常规的网站， 您不会注意到任何变化，绝大多数访客仍然会接受您的 Let’s Encrypt 证书。如果您提供 API 或必须支持物联网设备，您可能需要多注意更改。 -Let’s Encrypt 有个名为 [ISRG Root X1][] 的"[根证书][]" 。 现代浏览器和设备信任安装在您网站上的 Let's Encrypt 证书，因为它们的根证书列表中包含 ISRG Root X1。 为了确保我们颁发的证书在旧设备上受信任，我们还拥有来自旧根证书的“交叉签名”：DST Root CA X3。 +Let’s Encrypt 有个名为 [ISRG Root X1][] 的"[根证书][]" 。现代浏览器和设备信任安装在您网站上的 Let's Encrypt 证书，因为它们的根证书列表中包含 ISRG Root X1。为了确保我们颁发的证书在旧设备上受信任，我们还拥有来自旧根证书的“交叉签名”：DST Root CA X3。 -当我们开始签发时，旧的根证书 (DST Root CA X3) 帮助我们起步并立即受到几乎所有设备的信任。 较新的根证书 (ISRG Root X1) 现在也受到广泛信任 - 但一些较旧的设备永远不会信任它，因为它们没有获得软件更新（例如，iPhone 4 或 HTC Dream）。 [点击这里查看信任 ISRG Root X1 的平台][compatibility]。 +当我们开始签发时，旧的根证书 (DST Root CA X3) 帮助我们起步并立即受到几乎所有设备的信任。较新的根证书 (ISRG Root X1) 现在也受到广泛信任 - 但一些较旧的设备永远不会信任它，因为它们没有获得软件更新（例如，iPhone 4 或 HTC Dream）。[点击这里查看信任 ISRG Root X1 的平台][compatibility]。 -DST Root CA X3 将于2021年9月30日到期。 这意味着那些不信任 ISRG Root X1 的旧设备在访问使用 Let’s Encrypt 证书的网站时将会得到证书过期警告。 有一个重要的例外：不信任 ISRG Root X1 的旧 Android 设备将能够继续正常访问使用 Let’s Encrypt 证书加密的网站， [感谢来自 DST Root CA X3][cross-sign]的特殊交叉签名延长了该根证书的到期时间。 此例外仅适用于 Android 。 +DST Root CA X3 将于2021年9月30日到期。这意味着那些不信任 ISRG Root X1 的旧设备在访问使用 Let’s Encrypt 证书的网站时将会得到证书过期警告。有一个重要的例外：不信任 ISRG Root X1 的旧 Android 设备将能够继续正常访问使用 Let’s Encrypt 证书加密的网站， [感谢来自 DST Root CA X3][cross-sign]的特殊交叉签名延长了该根证书的到期时间。此例外仅适用于 Android 。 -我应该怎么办？ 对于大多数人来说，什么都不用做！ 我们已经用有利于广泛兼容的方式设置了我们的证书颁发服务，所以您的网站将在大多数情况下正常运行。 如果您提供 API 服务或必须支持 IoT 设备，则需要确保两件事：(1) API 服务的所有客户端都必须信任 ISRG Root X1 (而不仅仅信任 DST Root CA X3)，以及 (2) 如果您的 API 的客户端使用 OpenSSL，[它们必须使用 1.1.0 或更高版本][openssl]。 在 OpenSSL 1.0.x 版本中 ，证书验证时有个奇怪现象：当使用我们默认推荐的兼容 Android 的证书链时，即使客户端信任 ISRG Root X1 ，也会出现证书错误。 +我应该怎么办？对于大多数人来说，什么都不用做！我们已经用有利于广泛兼容的方式设置了我们的证书颁发服务，所以您的网站将在大多数情况下正常运行。如果您提供 API 服务或必须支持 IoT 设备，则需要确保两件事：(1) API 服务的所有客户端都必须信任 ISRG Root X1 (而不仅仅信任 DST Root CA X3)，以及 (2) 如果您的 API 的客户端使用 OpenSSL，[它们必须使用 1.1.0 或更高版本][openssl]。在 OpenSSL 1.0.x 版本中 ，证书验证时有个奇怪现象：当使用我们默认推荐的兼容 Android 的证书链时，即使客户端信任 ISRG Root X1 ，也会出现证书错误。 如果你想要了解我们正在进行的生产环境证书链更改的更多信息，[请在我们的社区中查看这个帖子][production] diff --git a/content/zh-cn/docs/faq.md b/content/zh-cn/docs/faq.md index 492b579737..caea22f4f1 100644 --- a/content/zh-cn/docs/faq.md +++ b/content/zh-cn/docs/faq.md @@ -19,32 +19,32 @@ show_lastmod: 1 ## Let's Encrypt 提供哪些服务？ -Let's Encrypt 是一家全球性的证书颁发机构 (CA)， 为世界各地的个人和团体提供获取、续期、管理 SSL/TLS 证书的服务。 网站可以使用我们的证书来启用安全的 HTTPS 连接。 +Let's Encrypt 是一家全球性的证书颁发机构 (CA)，为世界各地的个人和团体提供获取、续期、管理 SSL/TLS 证书的服务。网站可以使用我们的证书来启用安全的 HTTPS 连接。 -Let's Encrypt 仅提供域名验证 (DV) 证书， 不提供组织验证 (OV) 和扩展验证 (EV) 证书，主要原因是我们无法自动颁发这两类证书。 +Let's Encrypt 仅提供域名验证 (DV) 证书，不提供组织验证 (OV) 和扩展验证 (EV) 证书，主要原因是我们无法自动颁发这两类证书。 前往我们的[快速入门](/getting-started)页面即可开始使用 Let's Encrypt。 -## 使用 Let's Encrypt 的费用是多少？ 真的免费吗？ +## 使用 Let's Encrypt 的费用是多少？真的免费吗？ -我们颁发证书不收取任何费用。 Let's Encrypt 属于非营利组织，旨在推广 HTTPS 技术的应用，从而构建更加安全且尊重隐私的互联网环境。 我们致力于提供免费便捷的服务，以此帮助所有网站部署 HTTPS。 +我们颁发证书不收取任何费用。 Let's Encrypt 属于非营利组织，旨在推广 HTTPS 技术的应用，从而构建更加安全且尊重隐私的互联网环境。我们致力于提供免费便捷的服务，以此帮助所有网站部署 HTTPS。 -同时，我们也需要个人与赞助商的慷慨援助，才能持续向全球提供免费的服务。 如果您有兴趣支持我们，请考虑[捐款](/donate)或[成为赞助商](https://www.abetterinternet.org/sponsor)。 +同时，我们也需要个人与赞助商的慷慨援助，才能持续向全球提供免费的服务。如果您有兴趣支持我们，请考虑[捐款](/donate)或[成为赞助商](https://www.abetterinternet.org/sponsor)。 部分服务商（如网站托管服务）可能会收取小额费用，以弥补其提供 Let's Encrypt 证书所产生的管理费用。 ## 你们能提供怎样的客户服务？ -Let's Encrypt 的运营团队规模较小，依靠自动化来降低成本， 因此无法直接为用户提供客服支持。 不过我们确实有一些很棒的支持服务： +Let's Encrypt 的运营团队规模较小，依靠自动化来降低成本，因此无法直接为用户提供客服支持。不过我们确实有一些很棒的支持服务： 1. 我们有非常实用的[文档](/docs)。 -2. 我们有非常积极且乐于提供帮助的[社区支持论坛](https://community.letsencrypt.org/)。 我们社区的成员在回答问题方面做得很好，许多最常见的问题已经得到了解答。 +2. 我们有非常积极且乐于提供帮助的[社区支持论坛](https://community.letsencrypt.org/)。我们社区的成员在回答问题方面做得很好，许多最常见的问题已经得到了解答。 [这段影片](https://www.youtube.com/watch?v=Xe1TZaElTAs)充分展现了社群支持的力量，与我们的观念不谋而合。 ## 某个使用 Let's Encrypt 的网站涉嫌欺诈/钓鱼攻击/传播恶意软件……我该怎么办？ -我们建议向 Google Safe Browsing 与 Microsoft SmartScreen 项目举报此类网站，以便更为有效地保护用户。 举报网址如下： +我们建议向 Google Safe Browsing 与 Microsoft SmartScreen 项目举报此类网站，以便更为有效地保护用户。举报网址如下： - [https://safebrowsing.google.com/safebrowsing/report_badware/](https://safebrowsing.google.com/safebrowsing/report_badware/) - [https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site-guest](https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site-guest) @@ -67,17 +67,17 @@ Let's Encrypt 颁发的是标准的域名验证型证书，凡是有域名的服 ## Let's Encrypt 是否会在其服务器上生成或存储我的证书私钥？ -不会。 永远不会。 +不会。永远不会。 私钥只能由您自己的服务器生成并管理，与 Let's Encrypt 无关。 -## Let's Encrypt 证书的有效期有多长？ 能够使用多久？ +## Let's Encrypt 证书的有效期有多长？能够使用多久？ -我们的证书有效期默认为 90 天， 其背后的原因可以从[这里](/2015/11/09/why-90-days.html)了解。 +我们的证书有效期默认为 90 天，其背后的原因可以从[这里](/2015/11/09/why-90-days.html)了解。 -用户也可以选择有效期为 6 天的短期证书， 详见[此处](/2025/02/20/first-short-lived-cert-issued.html)。 +用户也可以选择有效期为 6 天的短期证书，详见[此处](/2025/02/20/first-short-lived-cert-issued.html)。 -除上述情形外证书有效期不能随意调整，任何用户都不例外。 我们建议有效期为 90 天的证书每 60 天续期一次，有效期为 6 天的证书每 3 天续期一次。 +除上述情形外证书有效期不能随意调整，任何用户都不例外。我们建议有效期为 90 天的证书每 60 天续期一次，有效期为 6 天的证书每 3 天续期一次。 ## Let's Encrypt 能颁发组织验证 (OV) 或扩展验证 (EV) 证书吗？ @@ -89,31 +89,31 @@ Let's Encrypt 颁发的是标准的域名验证型证书，凡是有域名的服 ## Let's Encrypt 颁发通配符证书吗？ -是的。 申请通配符证书必须通过 [DNS-01 验证](/docs/challenge-types/#dns-01-验证)。 有关更多技术信息，请参阅[该网页](https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578)。 +是的。申请通配符证书必须通过 [DNS-01 验证](/docs/challenge-types/#dns-01-验证)。有关更多技术信息，请参阅[该网页](https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578)。 ## 我的操作系统有可以使用的 Let's Encrypt (ACME) 客户端吗？ -您有大量的 [ACME 客户端](/docs/client-options)可以选择。 其中很可能就有支持您操作系统的客户端。 我们建议您在入门时使用 [Certbot](https://certbot.eff.org/)。 +您有大量的 [ACME 客户端](/docs/client-options)可以选择。其中很可能就有支持您操作系统的客户端。我们建议您在入门时使用 [Certbot](https://certbot.eff.org/)。 ## 我可以使用已有的私钥或证书签名请求 (CSR) 吗？ 是的，但并非所有客户端都支持此功能。 [Certbot](https://certbot.eff.org/) 是支持的。 -## 申请证书后我的域名流量剧增！ 为什么会这样？ +## 申请证书后我的域名流量剧增！为什么会这样？ -这是意料之中的正常情况。 在[证书颁发流程](/how-it-works)中，Let's Encrypt 会从[多个网络位置](/2020/02/19/multi-perspective-validation)核验您对域名的控制权。 验证通过后，您的证书还将录入各类[证书透明化 (CT) 日志系统](/docs/ct-logs)， 您可以在[此处](https://certificate.transparency.dev/howctworks/#pki)了解这种做法的必要性。 证书录入系统后，系统便会开始自动检测您的域名并尝试访问，在您的服务器日志中产生更多的记录。 +这是意料之中的正常情况。在[证书颁发流程](/how-it-works)中，Let's Encrypt 会从[多个网络位置](/2020/02/19/multi-perspective-validation)核验您对域名的控制权。验证通过后，您的证书还将录入各类[证书透明化 (CT) 日志系统](/docs/ct-logs)，您可以在[此处](https://certificate.transparency.dev/howctworks/#pki)了解这种做法的必要性。证书录入系统后，系统便会开始自动检测您的域名并尝试访问，在您的服务器日志中产生更多的记录。 ## Let's Encrypt 使用什么 IP 地址来验证我的网站服务器？ -我们不会发布用于验证的 IP 地址列表，因为它们随时都可能改变。 请注意，我们目前有[多个用于验证的 IP 地址](/2020/02/19/multi-perspective-validation.html)。 +我们不会发布用于验证的 IP 地址列表，因为它们随时都可能改变。请注意，我们目前有[多个用于验证的 IP 地址](/2020/02/19/multi-perspective-validation.html)。 ## 我的证书成功续期，但这次却不需要验证，为什么？ -域名验证通过后，结果会保留一段时间， 根据所选的[证书配置](/docs/profiles)，最长可以保留 30 天。 如果您申请证书时所有验证结果都还未过期，就无需重复验证。 +域名验证通过后，结果会保留一段时间，根据所选的[证书配置](/docs/profiles)，最长可以保留 30 天。如果您申请证书时所有验证结果都还未过期，就无需重复验证。 ## 为什么我的 Let's Encrypt (ACME) 客户端启动时间应当随机？ -我们要求 [ACME 客户端在随机的时间点执行证书续期](/docs/integration-guide/#续期时间)，防止每天的特定时刻（例如协调世界时的午夜零点、每小时或每分钟的第一秒）出现流量高峰。 服务器繁忙时我们还会要求客户端[等待一段时间再重试](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503)，因此将续期时间随机化也能避免不必要的反复请求。 +我们要求 [ACME 客户端在随机的时间点执行证书续期](/docs/integration-guide/#续期时间)，防止每天的特定时刻（例如协调世界时的午夜零点、每小时或每分钟的第一秒）出现流量高峰。服务器繁忙时我们还会要求客户端[等待一段时间再重试](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503)，因此将续期时间随机化也能避免不必要的反复请求。 ## 在哪里可以深入了解 TLS/SSL 与 PKI 的相关知识？ diff --git a/content/zh-cn/docs/glossary.md b/content/zh-cn/docs/glossary.md index 24283f2afa..99d29dda51 100644 --- a/content/zh-cn/docs/glossary.md +++ b/content/zh-cn/docs/glossary.md @@ -1,7 +1,7 @@ --- title: 术语表 slug: glossary -lastmod: 2026-09-08 +lastmod: 2026-10-04 show_lastmod: 1 description: "Let's Encrypt 所使用的 SSL/TLS 证书、HTTPS 以及网络安全相关术语的汇总表。" --- @@ -25,135 +25,135 @@ Note for translators: --> -{{% def id="AIA" name="颁发机构信息访问" english="Authority Information Access" abbr="AIA" %}} 用于提示[用户代理](#def-user-agent)获取[证书](#def-certificate)颁发者信息的方法的证书[扩展](#def-extension)。 通常包含[证书颁发机构的网址](#def-CAI)。 {{% /def %}} +{{% def id="AIA" name="颁发机构信息访问" english="Authority Information Access" abbr="AIA" %}} 用于提示[用户代理](#def-user-agent)获取[证书](#def-certificate)颁发者信息的方法的证书[扩展](#def-extension)。通常包含[证书颁发机构的网址](#def-CAI)。 {{% /def %}} -{{% def id="ACME" name="自动证书管理环境" english="Automatic Certificate Management Environment" abbr="ACME" abbr_first="1" %}} 由 [Let's Encrypt](#def-LE) 实现的协议。 与该协议兼容的软件可以用它与 Let's Encrypt 通信以获取[证书](#def-leaf)。 参见 [ACME RFC](https://tools.ietf.org/html/rfc8555) 和[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%87%AA%E5%8B%95%E6%86%91%E8%AD%89%E6%9B%B4%E6%96%B0%E7%92%B0%E5%A2%83)。 {{% /def %}} +{{% def id="ACME" name="自动证书管理环境" english="Automatic Certificate Management Environment" abbr="ACME" abbr_first="1" %}} 由 [Let's Encrypt](#def-LE) 实现的协议。与该协议兼容的软件可以用它与 Let's Encrypt 通信以获取[证书](#def-leaf)。参见 [ACME RFC](https://tools.ietf.org/html/rfc8555) 和[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%87%AA%E5%8B%95%E6%86%91%E8%AD%89%E6%9B%B4%E6%96%B0%E7%92%B0%E5%A2%83)。 {{% /def %}} {{% def id="ACME-client" name="ACME 客户端" english="ACME Client" %}} 能够与 ACME 服务器通信以获取[证书](#def-leaf)的程序。 {{% /def %}} {{% def id="ACME-server" name="ACME 服务器" english="ACME Server" %}} 兼容 ACME 协议的服务器，能够生成[证书](#def-leaf)。 Let's Encrypt 开发的软件 [Boulder](#def-boulder) 与 ACME 协议兼容，但[有一些差异](https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md)。 {{% /def %}} -{{% def id="boulder" english="Boulder" %}} 一款实现了 ACME 协议的软件，由 [Let's Encrypt](#def-LE) 开发并投入使用。 参见 [GitHub 代码仓库](https://github.com/letsencrypt/boulder)。 {{% /def %}} +{{% def id="boulder" english="Boulder" %}} 一款实现了 ACME 协议的软件，由 [Let's Encrypt](#def-LE) 开发并投入使用。参见 [GitHub 代码仓库](https://github.com/letsencrypt/boulder)。 {{% /def %}} -{{% def id="BRs" name="底线要求" english="Baseline Requirements" abbr="BRs" %}} 一组针对 CA 的技术和政策上的要求。 由于所有[根证书项目](#def-root-program)都包含了底线要求，CA 若要被大多数浏览器信任就必须遵循这些要求。 {{% /def %}} +{{% def id="BRs" name="底线要求" english="Baseline Requirements" abbr="BRs" %}} 一组针对 CA 的技术和政策上的要求。由于所有[根证书项目](#def-root-program)都包含了底线要求，CA 若要被大多数浏览器信任就必须遵循这些要求。 {{% /def %}} -{{% def id="CAA" name="证书颁发机构授权" english="Certificate Authority Authorization" abbr="CAA" abbr_first="1" %}} 一类 DNS 记录，用于指定哪些 [CA](#def-CA) 有权为相应的域名颁发证书。 CAA 记录需要 CA 遵守，而非由浏览器检查。 按照[底线要求](#def-BRs)的规定，[Let's Encrypt](#def-LE)[ 严格遵循 CAA 记录](/docs/caa)。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/DNS%E8%AF%81%E4%B9%A6%E9%A2%81%E5%8F%91%E6%9C%BA%E6%9E%84%E6%8E%88%E6%9D%83)。 {{% /def %}} +{{% def id="CAA" name="证书颁发机构授权" english="Certificate Authority Authorization" abbr="CAA" abbr_first="1" %}} 一类 DNS 记录，用于指定哪些 [CA](#def-CA) 有权为相应的域名颁发证书。 CAA 记录需要 CA 遵守，而非由浏览器检查。按照[底线要求](#def-BRs)的规定，[Let's Encrypt](#def-LE)[ 严格遵循 CAA 记录](/docs/caa)。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/DNS%E8%AF%81%E4%B9%A6%E9%A2%81%E5%8F%91%E6%9C%BA%E6%9E%84%E6%8E%88%E6%9D%83)。 {{% /def %}} -{{% def id="CNAME" name="真实名称记录" english="Canonical Name record" abbr="CNAME" %}} 将一个域名映射到另一个域名（称为真实名称）的 DNS 记录。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/CNAME%E8%AE%B0%E5%BD%95)。 {{% /def %}} +{{% def id="CNAME" name="真实名称记录" english="Canonical Name record" abbr="CNAME" %}} 将一个域名映射到另一个域名（称为真实名称）的 DNS 记录。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/CNAME%E8%AE%B0%E5%BD%95)。 {{% /def %}} -{{% def id="CA" name="证书颁发机构" english="Certificate Authority" abbr="CA" %}} 颁发[证书](#def-leaf)的组织。 [Let's Encrypt](#def-LE) 就是一家证书颁发机构。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%AF%81%E4%B9%A6%E9%A2%81%E5%8F%91%E6%9C%BA%E6%9E%84)。 {{% /def %}} +{{% def id="CA" name="证书颁发机构" english="Certificate Authority" abbr="CA" %}} 颁发[证书](#def-leaf)的组织。 [Let's Encrypt](#def-LE) 就是一家证书颁发机构。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%AF%81%E4%B9%A6%E9%A2%81%E5%8F%91%E6%9C%BA%E6%9E%84)。 {{% /def %}} -{{% def id="CAI" name="CA 颁发者" english="CA Issuers" %}}[AIA](#def-AIA) 字段的一部分，包含[证书](#def-leaf)颁发者的信息。 如果[网页服务器](#def-web-server)没有提供可信的[证书链](#def-chain)，这一信息可能会有用。 {{% /def %}} +{{% def id="CAI" name="CA 颁发者" english="CA Issuers" %}}[AIA](#def-AIA) 字段的一部分，包含[证书](#def-leaf)颁发者的信息。如果[网页服务器](#def-web-server)没有提供可信的[证书链](#def-chain)，这一信息可能会有用。 {{% /def %}} -{{% def id="certificate" name="证书" english="Certificate" %}} 包含公钥以及其他一些描述何时使用该公钥的信息的[特定格式](#def-X509)的文件。 [叶证书](#def-leaf)是最常见的证书类型。 另外还有[中间证书](#def-intermediate)和[根证书](#def-root)这两种证书。 {{% /def %}} +{{% def id="certificate" name="证书" english="Certificate" %}} 包含公钥以及其他一些描述何时使用该公钥的信息的[特定格式](#def-X509)的文件。[叶证书](#def-leaf)是最常见的证书类型。另外还有[中间证书](#def-intermediate)和[根证书](#def-root)这两种证书。 {{% /def %}} -{{% def id="extension" name="证书扩展" english="Certificate extension" %}} 在证书中，大多数字段都是由扩展来定义的。 例如，[主体备用名称](#def-SAN)和 [AIA](#def-AIA) 都属于扩展。 [X.509](#def-X509) 标准最初没有定义的字段可以通过扩展机制得到应用。 {{% /def %}} +{{% def id="extension" name="证书扩展" english="Certificate extension" %}} 在证书中，大多数字段都是由扩展来定义的。例如，[主体备用名称](#def-SAN)和 [AIA](#def-AIA) 都属于扩展。 [X.509](#def-X509) 标准最初没有定义的字段可以通过扩展机制得到应用。 {{% /def %}} -{{% def id="CABF" name="CA/浏览器论坛" english="CA/Browser Forum" %}} 由证书颁发机构、互联网浏览器软件的供应商、操作系统和其他使用 PKI 的应用程序组成的志愿团体。 CA/浏览器论坛发布了[底线要求](#def-BRs)。 [Let's Encrypt](#def-LE) 也是 CA/浏览器论坛的成员。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/CA/%E6%B5%8F%E8%A7%88%E5%99%A8%E8%AE%BA%E5%9D%9B)。 {{% /def %}} +{{% def id="CABF" name="CA/浏览器论坛" english="CA/Browser Forum" %}} 由证书颁发机构、互联网浏览器软件的供应商、操作系统和其他使用 PKI 的应用程序组成的志愿团体。 CA/浏览器论坛发布了[底线要求](#def-BRs)。 [Let's Encrypt](#def-LE) 也是 CA/浏览器论坛的成员。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/CA/%E6%B5%8F%E8%A7%88%E5%99%A8%E8%AE%BA%E5%9D%9B)。 {{% /def %}} -{{% def id="chain" name="证书链" english="Certificate chain" %}} 包含一系列[中间证书](#def-intermediate)，将[叶证书](#def-leaf)逐步连接到[证书库](#def-store)中的[根证书](#def-root)，从而协助[用户代理](#def-user-agent)确认叶证书是否可信。 注意：证书链并不总是唯一的，即使网站提供了一条证书链，用户代理也可以选择另一条证书链执行验证。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89)。 {{% /def %}} +{{% def id="chain" name="证书链" english="Certificate chain" %}} 包含一系列[中间证书](#def-intermediate)，将[叶证书](#def-leaf)逐步连接到[证书库](#def-store)中的[根证书](#def-root)，从而协助[用户代理](#def-user-agent)确认叶证书是否可信。注意：证书链并不总是唯一的，即使网站提供了一条证书链，用户代理也可以选择另一条证书链执行验证。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89)。 {{% /def %}} -{{% def id="CP" name="证书管理制度" english="Certificate Policy" abbr="CP" %}} 一系列具体的规定，表明证书是否适用于具备一定安全需求的某一类社群和/或应用类型。 证书颁发流程的细节则由 [CPS](#def-CPS) 描述。 CP 和 CPS 可以合并为一份文档。 参见 [ISRG 合并后的 CP/CPS 文件](/repository#isrg-certificate-policy)、[RFC 3647](https://tools.ietf.org/html/rfc3647) 和[英文维基百科条目](https://en.wikipedia.org/wiki/Certificate_policy)。 {{% /def %}} +{{% def id="CP" name="证书管理制度" english="Certificate Policy" abbr="CP" %}} 一系列具体的规定，表明证书是否适用于具备一定安全需求的某一类社群和/或应用类型。证书颁发流程的细节则由 [CPS](#def-CPS) 描述。 CP 和 CPS 可以合并为一份文档。参见 [ISRG 合并后的 CP/CPS 文件](/repository#isrg-certificate-policy)、[RFC 3647](https://tools.ietf.org/html/rfc3647) 和[英文维基百科条目](https://en.wikipedia.org/wiki/Certificate_policy)。 {{% /def %}} -{{% def id="CPS" name="证书运作声明" english="Certification Practice Statement" abbr="CPS" %}} 证书颁发机构对于证书颁发、管理、吊销、续期、更换密钥的流程所作的声明。 CPS 必须遵循[证书管理制度](#def-CP)的规定。 CP 和 CPS 可以合并为一份文档。 参见 [ISRG 合并后的 CP/CPS 文件](/repository#isrg-certificate-policy)、[RFC 3647 第 3.4 节](https://tools.ietf.org/html/rfc3647#section-3.4)和[英文维基百科条目](https://en.wikipedia.org/wiki/Certification_Practice_Statement)。 {{% /def %}} +{{% def id="CPS" name="证书运作声明" english="Certification Practice Statement" abbr="CPS" %}} 证书颁发机构对于证书颁发、管理、吊销、续期、更换密钥的流程所作的声明。 CPS 必须遵循[证书管理制度](#def-CP)的规定。 CP 和 CPS 可以合并为一份文档。参见 [ISRG 合并后的 CP/CPS 文件](/repository#isrg-certificate-policy)、[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="关键扩展" english="Critical extension" %}} 证书中的[扩展](#def-extension)可以标记为“关键”扩展，如果软件不知道如何处理此扩展，就必须拒绝使用该证书。这使得对于安全性至关重要的功能也可以通过扩展的形式实现，不会在旧版本软件中造成风险。 {{% /def %}} -{{% def id="CRL" name="证书吊销列表" english="Certificate Revocation List" abbr="CRL" %}} 一种将[证书](#def-leaf)的[吊销](#def-revocation)情况告知[用户代理](#def-user-agent)的方式。 列表中包含某一 CA 吊销的所有证书的序列号，由该 CA 加以数字签名。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%AF%81%E4%B9%A6%E5%90%8A%E9%94%80%E5%88%97%E8%A1%A8)。 {{% /def %}} +{{% def id="CRL" name="证书吊销列表" english="Certificate Revocation List" abbr="CRL" %}} 一种将[证书](#def-leaf)的[吊销](#def-revocation)情况告知[用户代理](#def-user-agent)的方式。列表中包含某一 CA 吊销的所有证书的序列号，由该 CA 加以数字签名。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%AF%81%E4%B9%A6%E5%90%8A%E9%94%80%E5%88%97%E8%A1%A8)。 {{% /def %}} -{{% def id="CSR" name="证书签名请求" english="Certificate Signing Request" abbr="CSR" %}} 一份经过数字签名的文件，包含 [CA](#def-CA) 生成证书所需的信息。 [Let's Encrypt](#def-LE) 所需的信息包括[通用名称](#def-CN)、[主体备用名称](#def-SAN)以及主体公钥信息。 通常，[客户端应用程序](#def-ACME-client)会自动为用户生成 CSR，Web 托管提供商或相关设备也可能会生成 CSR。 参见[英文维基百科条目](https://en.wikipedia.org/wiki/Certificate_signing_request)。 {{% /def %}} +{{% def id="CSR" name="证书签名请求" english="Certificate Signing Request" abbr="CSR" %}} 一份经过数字签名的文件，包含 [CA](#def-CA) 生成证书所需的信息。 [Let's Encrypt](#def-LE) 所需的信息包括[通用名称](#def-CN)、[主体备用名称](#def-SAN)以及主体公钥信息。通常，[客户端应用程序](#def-ACME-client)会自动为用户生成 CSR，Web 托管提供商或相关设备也可能会生成 CSR。参见[英文维基百科条目](https://en.wikipedia.org/wiki/Certificate_signing_request)。 {{% /def %}} -{{% def id="store" name="证书库" english="Certificate Store" %}} 证书库包含一系列受信任的[根证书](#def-root)。 操作系统（如 Windows、Android、Debian）和[网页浏览器](#def-web-browser)（如 Firefox）厂商通常会维护各自的证书库， 但也有一些浏览器直接使用操作系统的证书库。 [Let's Encrypt](#def-LE) 提供的[证书](#def-leaf)已得到[大多数证书库的信任](/certificates)。 {{% /def %}} +{{% def id="store" name="证书库" english="Certificate Store" %}} 证书库包含一系列受信任的[根证书](#def-root)。操作系统（如 Windows、Android、Debian）和[网页浏览器](#def-web-browser)（如 Firefox）厂商通常会维护各自的证书库，但也有一些浏览器直接使用操作系统的证书库。 [Let's Encrypt](#def-LE) 提供的[证书](#def-leaf)已得到[大多数证书库的信任](/certificates)。 {{% /def %}} -{{% def id="subject" name="证书主体" english="Certificate subject" %}} 证书的“主体”表示这份证书是授予谁的， 其中常包括[通用名称](#def-CN)、国家、组织等字段。 {{% /def %}} +{{% def id="subject" name="证书主体" english="Certificate subject" %}} 证书的“主体”表示这份证书是授予谁的，其中常包括[通用名称](#def-CN)、国家、组织等字段。 {{% /def %}} -{{% def id="CT" name="证书透明化" english="Certificate Transparency" abbr="CT" %}} 为了增强安全性，证书（以及[准证书](#def-precertificate)）必须通过证书透明化日志公开发布：https://www.certificate-transparency.org/。 [Let's Encrypt](#def-LE) 会先生成并发布[准证书](#def-precertificate)，随后在实际[证书](#def-leaf)中列出准证书的 [SCT](#def-SCT)。 部分[浏览器](#def-web-browser)（如 Google Chrome）要求这一可验证的承诺必须出现在证书中，以便其验证该证书。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%AF%81%E4%B9%A6%E9%80%8F%E6%98%8E%E5%BA%A6)。 {{% /def %}} +{{% def id="CT" name="证书透明化" english="Certificate Transparency" abbr="CT" %}} 为了增强安全性，证书（以及[准证书](#def-precertificate)）必须通过证书透明化日志公开发布：https://www.certificate-transparency.org/。 [Let's Encrypt](#def-LE) 会先生成并发布[准证书](#def-precertificate)，随后在实际[证书](#def-leaf)中列出准证书的 [SCT](#def-SCT)。部分[浏览器](#def-web-browser)（如 Google Chrome）要求这一可验证的承诺必须出现在证书中，以便其验证该证书。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%AF%81%E4%B9%A6%E9%80%8F%E6%98%8E%E5%BA%A6)。 {{% /def %}} {{% def id="CT-log" name="证书透明化日志" english="Certificate Transparency Log" %}} [证书透明化](#def-CT)机制的一部分，将接收到的证书和[准证书](#def-precertificate)加入一份永久、公开且可验证的列表中。 {{% /def %}} -{{% def id="CN" name="通用名称" english="Common Name" abbr="CN" %}} 证书[主体](#def-subject)信息的一部分，表示证书的所有者。 在[根证书](#def-root)和[中间证书](#def-intermediate)中，通用名称即为[证书颁发机构](#def-CA)面向用户的名称， 而在[叶证书](#def-leaf)中则是证书包含的一个域名。 注意：通用名称不能超过 64 个字符。 在过去，通用名称还用于表示证书对应的域名，但在现行的互联网标准中，软件只会通过[主体备用名称](#def-SAN)确定证书的有效性。 {{% /def %}} +{{% def id="CN" name="通用名称" english="Common Name" abbr="CN" %}} 证书[主体](#def-subject)信息的一部分，表示证书的所有者。在[根证书](#def-root)和[中间证书](#def-intermediate)中，通用名称即为[证书颁发机构](#def-CA)面向用户的名称，而在[叶证书](#def-leaf)中则是证书包含的一个域名。注意：通用名称不能超过 64 个字符。在过去，通用名称还用于表示证书对应的域名，但在现行的互联网标准中，软件只会通过[主体备用名称](#def-SAN)确定证书的有效性。 {{% /def %}} -{{% def id="cross-signing" name="交叉签名" english="Cross Signing" %}} 一份具备证书签发能力的证书可以由若干份[根证书](#def-root)签名，这些根证书也可以来自不同的 CA。 一家 CA 为另一家 CA 的证书签名就称为交叉签名。 {{% /def %}} +{{% def id="cross-signing" name="交叉签名" english="Cross Signing" %}} 一份具备证书签发能力的证书可以由若干份[根证书](#def-root)签名，这些根证书也可以来自不同的 CA。一家 CA 为另一家 CA 的证书签名就称为交叉签名。 {{% /def %}} -{{% def id="DANE" name="基于 DNS 的实体认证" english="DNS-based Authentication of Named Entities" abbr="DANE" abbr_first="1" %}} 一种通过 DNS 表明[证书](#def-leaf)或密钥验证方式的机制。 参见[英文维基百科条目](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities)。 {{% /def %}} +{{% def id="DANE" name="基于 DNS 的实体认证" english="DNS-based Authentication of Named Entities" abbr="DANE" abbr_first="1" %}} 一种通过 DNS 表明[证书](#def-leaf)或密钥验证方式的机制。参见[英文维基百科条目](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities)。 {{% /def %}} -{{% def id="DNSSEC" name="域名系统安全扩展" english="Domain Name System Security Extensions" abbr="DNSSEC" abbr_first="1" %}} 一种使用密码学验证 DNS 应答的机制。 要使 DNSSEC 生效，必须在 TLD、域名所有者以及递归解析服务器上都进行部署。 目前其采用率较低。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%9F%9F%E5%90%8D%E7%B3%BB%E7%BB%9F%E5%AE%89%E5%85%A8%E6%89%A9%E5%B1%95)。 {{% /def %}} +{{% def id="DNSSEC" name="域名系统安全扩展" english="Domain Name System Security Extensions" abbr="DNSSEC" abbr_first="1" %}} 一种使用密码学验证 DNS 应答的机制。要使 DNSSEC 生效，必须在 TLD、域名所有者以及递归解析服务器上都进行部署。目前其采用率较低。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%9F%9F%E5%90%8D%E7%B3%BB%E7%BB%9F%E5%AE%89%E5%85%A8%E6%89%A9%E5%B1%95)。 {{% /def %}} {{% def id="DV" name="域名验证型证书" english="Domain-validated certificate" abbr="DV 证书" abbr_first="1" %}} 此类[证书](#def-leaf)的申请者仅证明了其对域名（而非自称的组织团体）的控制权。 [Let's Encrypt](#def-LE) 只提供 DV 证书，不提供 [OV](#def-OV) 及 [EV](#def-EV) 证书。参见[常见问题](/docs/faq)和[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%9F%9F%E5%90%8D%E9%AA%8C%E8%AF%81%E5%9E%8B%E8%AF%81%E4%B9%A6)。 {{% /def %}} -{{% def id="ECDSA" name="椭圆曲线数字签名算法" english="Elliptic Curve Digital Signature Algorithm" abbr="ECDSA" abbr_first="1" %}} 一种采用[椭圆曲线密码学](#def-ECC)的数字签名算法。 参见[维基百科条目](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 %}} +{{% def id="ECDSA" name="椭圆曲线数字签名算法" english="Elliptic Curve Digital Signature Algorithm" abbr="ECDSA" abbr_first="1" %}} 一种采用[椭圆曲线密码学](#def-ECC)的数字签名算法。参见[维基百科条目](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 %}} -{{% def id="ECC" name="椭圆曲线密码学" english="Elliptic Curve Cryptography" abbr="ECC" abbr_first="1" %}} 基于椭圆曲线的一种公钥密码学。 相较于非椭圆曲线的加密方式，ECC 在提供同等的安全性的前提下使用更小的密钥。 参见 [Cloudflare 博客文章](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/)和[维基百科条目](https://zh.wikipedia.org/zh-cn/%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" abbr_first="1" %}} 基于椭圆曲线的一种公钥密码学。相较于非椭圆曲线的加密方式，ECC 在提供同等的安全性的前提下使用更小的密钥。参见 [Cloudflare 博客文章](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/)和[维基百科条目](https://zh.wikipedia.org/zh-cn/%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" abbr_first="1" %}} [CA](#def-CA) 在颁发证书前核实对网站具有控制权的法人， 证书中包含法人的具体信息。 [CA](#def-CA) 对此类证书的控制比 [OV](#def-OV) 证书更为严格。 [Let's Encrypt](#def-LE) 不提供 EV 证书。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E6%89%A9%E5%B1%95%E9%AA%8C%E8%AF%81%E8%AF%81%E4%B9%A6)。 {{% /def %}} +{{% def id="EV" name="扩展验证" english="Extended Validation" abbr="EV" abbr_first="1" %}} [CA](#def-CA) 在颁发证书前核实对网站具有控制权的法人，证书中包含法人的具体信息。 [CA](#def-CA) 对此类证书的控制比 [OV](#def-OV) 证书更为严格。 [Let's Encrypt](#def-LE) 不提供 EV 证书。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E6%89%A9%E5%B1%95%E9%AA%8C%E8%AF%81%E8%AF%81%E4%B9%A6)。 {{% /def %}} -{{% def id="FQDN" name="完全限定域名" english="Fully qualified domain name" abbr="FQDN" abbr_first="1" %}} 网站的完整域名。 例如，`www.example.com` 就是一个 *FQDN*。 {{% /def %}} +{{% def id="FQDN" name="完全限定域名" english="Fully qualified domain name" abbr="FQDN" abbr_first="1" %}} 网站的完整域名。例如，`www.example.com` 就是一个 *FQDN*。 {{% /def %}} -{{% def id="intermediate" name="中间证书" english="Intermediate certificate" %}} 由[根证书](#def-root)或另一中间证书签名的、能够为其他证书签名的证书。 此类证书用于为叶证书签名，从而使根证书的私钥可以在离线环境下安全存储。 中间证书会包含在[证书链](#def-chain)中。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89#%E8%AD%89%E6%9B%B8%E7%A8%AE%E9%A1%9E)。 {{% /def %}} +{{% def id="intermediate" name="中间证书" english="Intermediate certificate" %}} 由[根证书](#def-root)或另一中间证书签名的、能够为其他证书签名的证书。此类证书用于为叶证书签名，从而使根证书的私钥可以在离线环境下安全存储。中间证书会包含在[证书链](#def-chain)中。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89#%E8%AD%89%E6%9B%B8%E7%A8%AE%E9%A1%9E)。 {{% /def %}} {{% def id="IDNA" name="应用程序中的国际化域名" english="Internationalized Domain Names for Applications" abbr="IDNA" abbr_first="1" %}} 参见[国际化域名](#def-IDN)。 {{% /def %}} -{{% def id="IDN" name="国际化域名" english="Internationalized Domain Name" abbr="IDN" abbr_first="1" %}} 含有 `a` 到 `z`、`0` 到 `9`、短横线（`-`）以外字符的域名。 此类域名中可以使用带有变音符或连字的拉丁字母，也可以使用汉字、阿拉伯文、西里尔文、泰米尔文、希伯来文等文字。 编码后的 IDN 以 `xn--` 开头。 [Let's Encrypt](#def-LE) 支持 IDN：https://letsencrypt.org/2016/10/21/introducing-idn-support.html。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%9B%BD%E9%99%85%E5%8C%96%E5%9F%9F%E5%90%8D)、[RFC 5890](https://tools.ietf.org/html/rfc5890) 和 [RFC 5891](https://tools.ietf.org/html/rfc5891)。 {{% /def %}} +{{% def id="IDN" name="国际化域名" english="Internationalized Domain Name" abbr="IDN" abbr_first="1" %}} 含有 `a` 到 `z`、`0` 到 `9`、短横线（`-`）以外字符的域名。此类域名中可以使用带有变音符或连字的拉丁字母，也可以使用汉字、阿拉伯文、西里尔文、泰米尔文、希伯来文等文字。编码后的 IDN 以 `xn--` 开头。 [Let's Encrypt](#def-LE) 支持 IDN：https://letsencrypt.org/2016/10/21/introducing-idn-support.html。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%9B%BD%E9%99%85%E5%8C%96%E5%9F%9F%E5%90%8D)、[RFC 5890](https://tools.ietf.org/html/rfc5890) 和 [RFC 5891](https://tools.ietf.org/html/rfc5891)。 {{% /def %}} -{{% def id="ISRG" name="互联网安全研究组" english="Internet Security Research Group" abbr="ISRG" abbr_first="1" %}} [Let's Encrypt](#def-LE) 背后的运作机构：[https://www.abetterinternet.org/about/](https://www.abetterinternet.org/about/)。 参见[英文维基百科条目](https://en.wikipedia.org/wiki/Internet_Security_Research_Group)。 {{% /def %}} +{{% def id="ISRG" name="互联网安全研究组" english="Internet Security Research Group" abbr="ISRG" abbr_first="1" %}} [Let's Encrypt](#def-LE) 背后的运作机构：[https://www.abetterinternet.org/about/](https://www.abetterinternet.org/about/)。参见[英文维基百科条目](https://en.wikipedia.org/wiki/Internet_Security_Research_Group)。 {{% /def %}} -{{% def id="issuer" name="证书颁发者" english="Certificate issuer" %}} 证书的“颁发者”字段表示这份证书是由谁签名的。 例如，Let's Encrypt 颁发的终端实体证书的颁发者字段可能是：“Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3”。 颁发者通常包含[通用名称](#def-CN)、国家、组织等字段， 且必须和某一份证书的[主体](#def-subject)字段一致。 [自签名](#def-self-signed)证书（如[根证书](#def-root)）的颁发者与主体字段内容相同。 “颁发者”一词也泛指所有能够签发其他证书的证书（包括[中间证书](#def-intermediate)和根证书），或者有资格颁发证书的机构。 {{% /def %}} +{{% def id="issuer" name="证书颁发者" english="Certificate issuer" %}} 证书的“颁发者”字段表示这份证书是由谁签名的。例如，Let's Encrypt 颁发的终端实体证书的颁发者字段可能是：“Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3”。颁发者通常包含[通用名称](#def-CN)、国家、组织等字段，且必须和某一份证书的[主体](#def-subject)字段一致。[自签名](#def-self-signed)证书（如[根证书](#def-root)）的颁发者与主体字段内容相同。“颁发者”一词也泛指所有能够签发其他证书的证书（包括[中间证书](#def-intermediate)和根证书），或者有资格颁发证书的机构。 {{% /def %}} -{{% def id="key-pair" name="密钥对" english="Key-pair" %}} 用于签名或加密的公钥和私钥的组合。 公钥通常嵌入在证书中，而私钥则独立保密存储。 根据不同的应用情况，密钥对可以用于加密和解密、签名和验证数据或是协商二级密钥。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86)。 {{% /def %}} +{{% def id="key-pair" name="密钥对" english="Key-pair" %}} 用于签名或加密的公钥和私钥的组合。公钥通常嵌入在证书中，而私钥则独立保密存储。根据不同的应用情况，密钥对可以用于加密和解密、签名和验证数据或是协商二级密钥。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86)。 {{% /def %}} -{{% def id="leaf" name="叶证书（最终实体证书）" english="Leaf certificate (end-entity certificate)" %}} 一般是由[中间证书](#def-intermediate)签名的一份证书，仅对一系列域名有效，且不能用于签发其他证书。 [ACME 客户端](#def-ACME-client)申请及[网页服务器](#def-web-server)使用的都是此类证书。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89#%E7%B5%82%E7%AB%AF%E5%AF%A6%E9%AB%94%E8%AD%89%E6%9B%B8)。 {{% /def %}} +{{% def id="leaf" name="叶证书（最终实体证书）" english="Leaf certificate (end-entity certificate)" %}} 一般是由[中间证书](#def-intermediate)签名的一份证书，仅对一系列域名有效，且不能用于签发其他证书。 [ACME 客户端](#def-ACME-client)申请及[网页服务器](#def-web-server)使用的都是此类证书。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89#%E7%B5%82%E7%AB%AF%E5%AF%A6%E9%AB%94%E8%AD%89%E6%9B%B8)。 {{% /def %}} -{{% def id="LE" english="Let's Encrypt" abbr="LE" %}} 一家由 [ISRG](#def-ISRG) 运营的[证书颁发机构](#def-CA)。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/Let%27s_Encrypt)。 {{% /def %}} +{{% def id="LE" english="Let's Encrypt" abbr="LE" %}} 一家由 [ISRG](#def-ISRG) 运营的[证书颁发机构](#def-CA)。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/Let%27s_Encrypt)。 {{% /def %}} -{{% def id="mixed-content" name="混合内容" english="Mixed content" %}} 在 HTTPS 网页中通过 HTTP 加载子资源（JavaScript、CSS 或图片）。 [浏览器](#def-web-browser)可能会屏蔽混合内容，或将含有混合内容的页面标为不安全：https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content。 要解决混合内容的问题，网页开发者必须把所有资源都改为使用 HTTPS 链接。 通过浏览器内置的[开发者工具](https://developer.mozilla.org/zh-CN/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools)可以找到哪些资源存在混合内容的问题。 {{% /def %}} +{{% def id="mixed-content" name="混合内容" english="Mixed content" %}} 在 HTTPS 网页中通过 HTTP 加载子资源（JavaScript、CSS 或图片）。[浏览器](#def-web-browser)可能会屏蔽混合内容，或将含有混合内容的页面标为不安全：https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content。要解决混合内容的问题，网页开发者必须把所有资源都改为使用 HTTPS 链接。通过浏览器内置的[开发者工具](https://developer.mozilla.org/zh-CN/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools)可以找到哪些资源存在混合内容的问题。 {{% /def %}} -{{% def id="OCSP" name="在线证书状态协议" english="Online Certificate Status Protocol" abbr="OCSP" abbr_first="1" %}} 一种检查[证书](#def-leaf)是否已被[吊销](#def-revocation)的方式。 也就是询问[证书颁发机构](#def-CA)，某一份证书是否尚未到期就已提前失效。 这种方式存在隐私问题，因为证书颁发机构和网络运营商都能得知谁访问了哪些网站。 [Let's Encrypt](#def-LE) 现已停止提供 OCSP 服务。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%9C%A8%E7%BA%BF%E8%AF%81%E4%B9%A6%E7%8A%B6%E6%80%81%E5%8D%8F%E8%AE%AE)。 {{% /def %}} +{{% def id="OCSP" name="在线证书状态协议" english="Online Certificate Status Protocol" abbr="OCSP" abbr_first="1" %}} 一种检查[证书](#def-leaf)是否已被[吊销](#def-revocation)的方式。也就是询问[证书颁发机构](#def-CA)，某一份证书是否尚未到期就已提前失效。这种方式存在隐私问题，因为证书颁发机构和网络运营商都能得知谁访问了哪些网站。 [Let's Encrypt](#def-LE) 现已停止提供 OCSP 服务。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%9C%A8%E7%BA%BF%E8%AF%81%E4%B9%A6%E7%8A%B6%E6%80%81%E5%8D%8F%E8%AE%AE)。 {{% /def %}} -{{% def id="OCSP-must-staple" name="OCSP 强制装订" english="OCSP Must-Staple" %}} 一种[证书](#def-leaf)扩展，告知[浏览器](#def-web-browser)使用此证书的[网页服务器](#def-web-server)必须采用 [OCSP 装订](#def-OCSP-stapling)。 这能保证每次连接时[证书](#def-leaf)的实时[吊销](#def-revocation)状态都能得到服务器确认，使吊销机制更加可靠。 [Let's Encrypt](#def-LE) 现已不再支持此功能。 [RFC 7633](https://tools.ietf.org/html/rfc7633) {{% /def %}} +{{% def id="OCSP-must-staple" name="OCSP 强制装订" english="OCSP Must-Staple" %}} 一种[证书](#def-leaf)扩展，告知[浏览器](#def-web-browser)使用此证书的[网页服务器](#def-web-server)必须采用 [OCSP 装订](#def-OCSP-stapling)。这能保证每次连接时[证书](#def-leaf)的实时[吊销](#def-revocation)状态都能得到服务器确认，使吊销机制更加可靠。 [Let's Encrypt](#def-LE) 现已不再支持此功能。 [RFC 7633](https://tools.ietf.org/html/rfc7633) {{% /def %}} -{{% def id="OCSP-stapling" name="OCSP 装订" english="OCSP stapling" %}} [网页服务器](#def-web-server)将[证书颁发机构](#def-CA)签名的 [OCSP](#def-OCSP) 响应直接发送给[浏览器](#def-web-browser)，使浏览器不必再自行询问证书颁发机构，从而提升网页加载速度并保护用户隐私。 这种方式也称为 TLS 证书状态请求扩展。 需要注意的是 [Let's Encrypt](#def-LE) 现已不再支持 OCSP。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/OCSP%E8%A3%85%E8%AE%A2)和 [Cloudflare 博客文章](https://blog.cloudflare.com/high-reliability-ocsp-stapling/)。 {{% /def %}} +{{% def id="OCSP-stapling" name="OCSP 装订" english="OCSP stapling" %}} [网页服务器](#def-web-server)将[证书颁发机构](#def-CA)签名的 [OCSP](#def-OCSP) 响应直接发送给[浏览器](#def-web-browser)，使浏览器不必再自行询问证书颁发机构，从而提升网页加载速度并保护用户隐私。这种方式也称为 TLS 证书状态请求扩展。需要注意的是 [Let's Encrypt](#def-LE) 现已不再支持 OCSP。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/OCSP%E8%A3%85%E8%AE%A2)和 [Cloudflare 博客文章](https://blog.cloudflare.com/high-reliability-ocsp-stapling/)。 {{% /def %}} -{{% def id="OID" name="对象标识符" english="Object identifier" abbr="OID" abbr_first="1" %}} 一种全球唯一的数字型标识符，由国际电信联盟 (ITU) 和 ISO/IEC 标准化。 OID 在证书中用于定义扩展、字段和制度声明， 具体用法由互联网协议、[证书颁发制度](#def-CP)和[证书运作声明](#def-CPS)规定。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E7%89%A9%E4%BB%B6%E8%AD%98%E8%BE%A8%E7%AC%A6)。 {{% /def %}} +{{% def id="OID" name="对象标识符" english="Object identifier" abbr="OID" abbr_first="1" %}} 一种全球唯一的数字型标识符，由国际电信联盟 (ITU) 和 ISO/IEC 标准化。 OID 在证书中用于定义扩展、字段和制度声明，具体用法由互联网协议、[证书颁发制度](#def-CP)和[证书运作声明](#def-CPS)规定。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E7%89%A9%E4%BB%B6%E8%AD%98%E8%BE%A8%E7%AC%A6)。 {{% /def %}} -{{% def id="OV" name="组织验证" english="Organization Validation" abbr="OV" abbr_first="1" %}} [CA](#def-CA) 核实[用户](#def-subscriber)的法人身份后颁发的证书， 此类证书含有该法人的相关信息。 [Let's Encrypt](#def-LE) 不提供 OV 证书。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89#%E7%B5%84%E7%B9%94%E9%A9%97%E8%AD%89%EF%BC%88OV%EF%BC%89)。 {{% /def %}} +{{% def id="OV" name="组织验证" english="Organization Validation" abbr="OV" abbr_first="1" %}} [CA](#def-CA) 核实[用户](#def-subscriber)的法人身份后颁发的证书，此类证书含有该法人的相关信息。 [Let's Encrypt](#def-LE) 不提供 OV 证书。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89#%E7%B5%84%E7%B9%94%E9%A9%97%E8%AD%89%EF%BC%88OV%EF%BC%89)。 {{% /def %}} -{{% def id="pem" name="PEM 文件（.pem）" english="PEM file (.pem)" %}} 一种密码学信息的格式（原来作为“隐私增强型邮件”互联网标准的一部分被用于保护电子邮件）。 PEM 文档可以用于表示私钥、公钥、数字证书等信息。 这些文件以“-----BEGIN”加上数据类型开头。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/Pem%E6%A0%BC%E5%BC%8F)。 {{% /def %}} +{{% def id="pem" name="PEM 文件（.pem）" english="PEM file (.pem)" %}} 一种密码学信息的格式（原来作为“隐私增强型邮件”互联网标准的一部分被用于保护电子邮件）。 PEM 文档可以用于表示私钥、公钥、数字证书等信息。这些文件以“-----BEGIN”加上数据类型开头。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/Pem%E6%A0%BC%E5%BC%8F)。 {{% /def %}} -{{% def id="pfx" name="个人信息交换文件（.pfx）" english="Personal Information Exchange Files" %}} 一种文件格式，其中可包含[叶证书](#def-leaf)及其私钥，以及该证书到根证书的[证书链](#def-chain)。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/PKCS_12)和 [Microsoft 硬件开发者中心文章](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/personal-information-exchange---pfx--files)。 {{% /def %}} +{{% def id="pfx" name="个人信息交换文件（.pfx）" english="Personal Information Exchange Files" %}} 一种文件格式，其中可包含[叶证书](#def-leaf)及其私钥，以及该证书到根证书的[证书链](#def-chain)。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/PKCS_12)和 [Microsoft 硬件开发者中心文章](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/personal-information-exchange---pfx--files)。 {{% /def %}} -{{% def id="precertificate" name="准证书" english="Precertificate" %}} [证书透明化](#def-CT)系统的一部分。 准证书由 CA 即将颁发的[证书](#def-leaf)外加一项[关键](#def-critical)扩展组成，该扩展用于防止一般软件将准证书作为正常证书使用。 CA 将生成的准证书提交至 [CT 日志](#def-CT-log)系统，从而获得 [SCT](#def-SCT)。 由于准证书与其对应的证书并不完全相同，二者最终可能都会录入证书透明化日志系统中。 参见 [RFC 6962 第 3.1 节](https://tools.ietf.org/html/rfc6962#section-3.1)。 {{% /def %}} +{{% def id="precertificate" name="准证书" english="Precertificate" %}} [证书透明化](#def-CT)系统的一部分。准证书由 CA 即将颁发的[证书](#def-leaf)外加一项[关键](#def-critical)扩展组成，该扩展用于防止一般软件将准证书作为正常证书使用。 CA 将生成的准证书提交至 [CT 日志](#def-CT-log)系统，从而获得 [SCT](#def-SCT)。由于准证书与其对应的证书并不完全相同，二者最终可能都会录入证书透明化日志系统中。参见 [RFC 6962 第 3.1 节](https://tools.ietf.org/html/rfc6962#section-3.1)。 {{% /def %}} -{{% def id="profile" name="证书配置" english="Profile" %}} 证书的配置包含一系列属性，对证书的验证流程和最终内容都有影响。 请参阅[证书配置文档](/docs/profiles)了解各种可用的配置及其影响，以及如何选择配置。 {{% /def %}} +{{% def id="profile" name="证书配置" english="Profile" %}} 证书的配置包含一系列属性，对证书的验证流程和最终内容都有影响。请参阅[证书配置文档](/docs/profiles)了解各种可用的配置及其影响，以及如何选择配置。 {{% /def %}} -{{% def id="HPKP" name="HTTP 公钥固定" english="HTTP Public Key Pinning" abbr="HPKP" %}} 一种安全机制，要求浏览器连接网站时确保[证书链](#def-chain)必须使用特定的公钥。 Chrome 浏览器曾引入这一机制应对 CA 被入侵的情况，但网站常因此出现问题，最终 Chrome [废除了该功能](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/he9tr7p3rZ8)。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/HTTP%E5%85%AC%E9%92%A5%E5%9B%BA%E5%AE%9A)。 {{% /def %}} +{{% def id="HPKP" name="HTTP 公钥固定" english="HTTP Public Key Pinning" abbr="HPKP" %}} 一种安全机制，要求浏览器连接网站时确保[证书链](#def-chain)必须使用特定的公钥。 Chrome 浏览器曾引入这一机制应对 CA 被入侵的情况，但网站常因此出现问题，最终 Chrome [废除了该功能](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/he9tr7p3rZ8)。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/HTTP%E5%85%AC%E9%92%A5%E5%9B%BA%E5%AE%9A)。 {{% /def %}} -{{% def id="PSL" name="公共后缀列表" english="Public Suffix List" abbr="PSL" %}} 由 Mozilla 整理并维护的一份*公共域名后缀*的名单，这些域名的子域名是对外开放注册的，可以由大量不相关的团体和个人使用。 例如，`com` 和 `co.uk` 都在这一列表中，虽然 `co.uk` 并不是顶级域名。 网页浏览器使用这个列表和其他一些方法来防止可能是不同实体运营的网站互相共享 Cookies。 [Let's Encrypt](#def-LE) 也使用了这一列表，用于实施[速率限制](/docs/rate-limits)。 https://publicsuffix.org/ {{% /def %}} +{{% def id="PSL" name="公共后缀列表" english="Public Suffix List" abbr="PSL" %}} 由 Mozilla 整理并维护的一份*公共域名后缀*的名单，这些域名的子域名是对外开放注册的，可以由大量不相关的团体和个人使用。例如，`com` 和 `co.uk` 都在这一列表中，虽然 `co.uk` 并不是顶级域名。网页浏览器使用这个列表和其他一些方法来防止可能是不同实体运营的网站互相共享 Cookies。 [Let's Encrypt](#def-LE) 也使用了这一列表，用于实施[速率限制](/docs/rate-limits)。 https://publicsuffix.org/ {{% /def %}} -{{% def id="relying-party" name="依赖方" english="Relying Party" %}} 需要使用证书中的信息的人， 例如 HTTPS 网站的用户。 {{% /def %}} +{{% def id="relying-party" name="依赖方" english="Relying Party" %}} 需要使用证书中的信息的人，例如 HTTPS 网站的用户。 {{% /def %}} -{{% def id="revocation" name="吊销" english="Revocation" %}} 证书在到期前始终有效，除非 [CA](#def-CA) 声明该证书已被提前吊销。 吊销的原因有很多种，比如私钥泄露。 浏览器可以通过 [CRL](#def-CRL) 或 [CRLite](https://github.com/mozilla/crlite/)、[CRLSets](https://dev.chromium.org/Home/chromium-security/crlsets) 等新兴的方式核实证书是否已被吊销。 需要注意的是，[证书吊销在很多情况下达不到预期的效果](https://www.imperialviolet.org/2011/03/18/revocation.html)。 \[/docs/revoking\](/docs/revoking) {{% /def %}} +{{% def id="revocation" name="吊销" english="Revocation" %}} 证书在到期前始终有效，除非 [CA](#def-CA) 声明该证书已被提前吊销。吊销的原因有很多种，比如私钥泄露。浏览器可以通过 [CRL](#def-CRL) 或 [CRLite](https://github.com/mozilla/crlite/)、[CRLSets](https://dev.chromium.org/Home/chromium-security/crlsets) 等新兴的方式核实证书是否已被吊销。需要注意的是，[证书吊销在很多情况下达不到预期的效果](https://www.imperialviolet.org/2011/03/18/revocation.html)。 \[/docs/revoking\](/docs/revoking) {{% /def %}} -{{% def id="root" name="根证书" english="Root certificate" %}} 一份由[证书颁发机构](#def-CA)控制的[自签名证书](#def-self-signed)，收录于各[证书库](#def-store)中，用于签发其[中间证书](#def-intermediate)。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E6%A0%B9%E8%AF%81%E4%B9%A6)。 {{% /def %}} +{{% def id="root" name="根证书" english="Root certificate" %}} 一份由[证书颁发机构](#def-CA)控制的[自签名证书](#def-self-signed)，收录于各[证书库](#def-store)中，用于签发其[中间证书](#def-intermediate)。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E6%A0%B9%E8%AF%81%E4%B9%A6)。 {{% /def %}} {{% def id="root-program" name="根证书项目" english="Root Program" %}} 组织机构对于哪些证书可收录于其[证书库](#def-store)中所作的规定，即哪些 CA 可得到其软件的信任。 {{% /def %}} -{{% def id="RSA" abbr="RSA" %}} 一种用于加密和数字签名证书的公钥加密算法。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/RSA%E5%8A%A0%E5%AF%86%E6%BC%94%E7%AE%97%E6%B3%95)。 {{% /def %}} +{{% def id="RSA" abbr="RSA" %}} 一种用于加密和数字签名证书的公钥加密算法。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/RSA%E5%8A%A0%E5%AF%86%E6%BC%94%E7%AE%97%E6%B3%95)。 {{% /def %}} -{{% def id="self-signed" name="自签名证书" english="Self-signed certificate" %}} 一份[主体](#def-subject)和[颁发者](#def-issuer)相同的证书，由其自身的私钥签名。 自签名证书只能通过现实中的事先安排得到信任，例如收录于[可信根证书列表](#def-store)中。 所有[根证书](#def-root)都是自签名证书。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%87%AA%E7%AD%BE%E5%90%8D%E8%AF%81%E4%B9%A6)。 {{% /def %}} +{{% def id="self-signed" name="自签名证书" english="Self-signed certificate" %}} 一份[主体](#def-subject)和[颁发者](#def-issuer)相同的证书，由其自身的私钥签名。自签名证书只能通过现实中的事先安排得到信任，例如收录于[可信根证书列表](#def-store)中。所有[根证书](#def-root)都是自签名证书。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E8%87%AA%E7%AD%BE%E5%90%8D%E8%AF%81%E4%B9%A6)。 {{% /def %}} -{{% def id="SNI" name="服务器名称指示" english="Server Name Indication" abbr="SNI" abbr_first="1" %}} [用户代理](#def-user-agent)在 [TLS](#def-TLS) 握手过程中发送给[服务器](#def-web-server)的一个字段，表示其正在连接的域名。 如果一个 IP 地址有多个域名，服务器可以借助 SNI 提供合适的[证书](#def-leaf)。 例如，网页服务器可以根据客户端指定的 SNI 域名发送不同的证书并展示相应的内容。 SNI 是明文传输的，但新推出的 TLS 扩展 [Encrypted Client Hello (ECH)](https://zh.wikipedia.org/zh-cn/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA#%E5%8A%A0%E5%AF%86%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA) 能够予以加密。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA)。 {{% /def %}} +{{% def id="SNI" name="服务器名称指示" english="Server Name Indication" abbr="SNI" abbr_first="1" %}} [用户代理](#def-user-agent)在 [TLS](#def-TLS) 握手过程中发送给[服务器](#def-web-server)的一个字段，表示其正在连接的域名。如果一个 IP 地址有多个域名，服务器可以借助 SNI 提供合适的[证书](#def-leaf)。例如，网页服务器可以根据客户端指定的 SNI 域名发送不同的证书并展示相应的内容。 SNI 是明文传输的，但新推出的 TLS 扩展 [Encrypted Client Hello (ECH)](https://zh.wikipedia.org/zh-cn/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA#%E5%8A%A0%E5%AF%86%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA) 能够予以加密。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA)。 {{% /def %}} -{{% def id="SCT" name="签名证书时间戳" english="Signed Certificate Timestamp" abbr="SCT" abbr_first="1" %}} 一种经过数字签名的、可验证的承诺，保证将证书发布至[证书透明化日志](#def-CT-log)系统。 严格遵循 [CT](#def-CT) 的浏览器会检查所有网站证书或 [TLS](#def-TLS) 握手过程中的 SCT 字段，如果不符合其日志要求则拒绝连接。 这使得欺诈性的或错误的证书更容易被检测出来。 https://www.certificate-transparency.org/how-ct-works {{% /def %}} +{{% def id="SCT" name="签名证书时间戳" english="Signed Certificate Timestamp" abbr="SCT" abbr_first="1" %}} 一种经过数字签名的、可验证的承诺，保证将证书发布至[证书透明化日志](#def-CT-log)系统。严格遵循 [CT](#def-CT) 的浏览器会检查所有网站证书或 [TLS](#def-TLS) 握手过程中的 SCT 字段，如果不符合其日志要求则拒绝连接。这使得欺诈性的或错误的证书更容易被检测出来。 https://www.certificate-transparency.org/how-ct-works {{% /def %}} {{% def id="SSL" name="安全套接字层" english="Secure Sockets Layer" abbr="SSL" abbr_first="1" %}} [TLS](#def-TLS) 的原名，至今仍然很常用。 {{% /def %}} -{{% def id="staging" name="测试环境" english="Staging" %}} [Let's Encrypt](#def-LE) 提供的接口，可用于调试证书申请流程，避免触发速率限制。 测试环境中生成的证书是*不会*被广泛信任的， 因此测试环境只应在测试、调试和 ACME 客户端开发过程中使用。 参见[测试环境文档](/docs/staging-environment)。 {{% /def %}} +{{% def id="staging" name="测试环境" english="Staging" %}} [Let's Encrypt](#def-LE) 提供的接口，可用于调试证书申请流程，避免触发速率限制。测试环境中生成的证书是*不会*被广泛信任的，因此测试环境只应在测试、调试和 ACME 客户端开发过程中使用。参见[测试环境文档](/docs/staging-environment)。 {{% /def %}} -{{% def id="SAN" name="主体备用名称" english="Subject Alternative Name" abbr="SAN" %}} [证书](#def-leaf)中的一个字段，表明该证书对哪些域名有效。 这一功能原先由[通用名称](#def-CN)提供，但该字段已取而代之，通用名称的这一功能也只因兼容性得以保留。 一份证书可以包含多个 SAN，从而对多个域名有效。 [Wikipedia](https://en.wikipedia.org/wiki/Subject_Alternative_Name) [/docs/profiles/#max-names](/docs/profiles/#max-names) {{% /def %}} +{{% def id="SAN" name="主体备用名称" english="Subject Alternative Name" abbr="SAN" %}} [证书](#def-leaf)中的一个字段，表明该证书对哪些域名有效。这一功能原先由[通用名称](#def-CN)提供，但该字段已取而代之，通用名称的这一功能也只因兼容性得以保留。一份证书可以包含多个 SAN，从而对多个域名有效。 [Wikipedia](https://en.wikipedia.org/wiki/Subject_Alternative_Name) [/docs/profiles/#max-names](/docs/profiles/#max-names) {{% /def %}} {{% def id="subscriber" name="用户" english="Subscriber" %}} 申请证书的个人或组织。 {{% /def %}} -{{% def id="TLD" name="顶级域名" english="Top-Level Domain" abbr="TLD" abbr_first="1" %}} 域名系统中的最高层级，例如德国的 `.de`、中国的 `.cn` 等国家顶级域名 (ccTLD)，又如 `.com`、`.org` 等通用顶级域名 (gTLD)。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E9%A0%82%E7%B4%9A%E5%9F%9F)。 {{% /def %}} +{{% def id="TLD" name="顶级域名" english="Top-Level Domain" abbr="TLD" abbr_first="1" %}} 域名系统中的最高层级，例如德国的 `.de`、中国的 `.cn` 等国家顶级域名 (ccTLD)，又如 `.com`、`.org` 等通用顶级域名 (gTLD)。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E9%A0%82%E7%B4%9A%E5%9F%9F)。 {{% /def %}} {{% def id="TLS" name="传输层安全" english="Transport Layer Security" abbr="TLS" abbr_first="1" %}} HTTPS 用于加密和认证网页访问的协议。 {{% /def %}} @@ -161,15 +161,15 @@ Note for translators: {{% def id="UCC" name="统一通信证书" english="Unified Communications Certificate" abbr="UCC" abbr_first="1" %}} 对包含多个[主体备用名称 (SAN)](#def-SAN) 的证书的一种称呼。 {{% /def %}} -{{% def id="web-browser" name="网页浏览器" english="Web Browser" %}} 一类用于显示网页内容的[用户代理](#def-user-agent)， 例如 *Mozilla Firefox*、*Google Chrome* 和 *Safari*。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E7%BD%91%E9%A1%B5%E6%B5%8F%E8%A7%88%E5%99%A8)。{{% /def %}} +{{% def id="web-browser" name="网页浏览器" english="Web Browser" %}} 一类用于显示网页内容的[用户代理](#def-user-agent)，例如 *Mozilla Firefox*、*Google Chrome* 和 *Safari*。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E7%BD%91%E9%A1%B5%E6%B5%8F%E8%A7%88%E5%99%A8)。{{% /def %}} -{{% def id="user-agent" name="用户代理" english="User Agent" %}} 能够与[网页服务器](#def-web-server)通信的软件， 例如[网页浏览器](#def-web-browser)和 [cURL](https://zh.wikipedia.org/zh-cn/CURL)。 {{% /def %}} +{{% def id="user-agent" name="用户代理" english="User Agent" %}} 能够与[网页服务器](#def-web-server)通信的软件，例如[网页浏览器](#def-web-browser)和 [cURL](https://zh.wikipedia.org/zh-cn/CURL)。 {{% /def %}} -{{% def id="web-server" name="网页服务器" english="Web server" %}} 提供网页服务的软件，广义上也可以指运行该软件的硬件。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E7%B6%B2%E9%A0%81%E4%BC%BA%E6%9C%8D%E5%99%A8)。 {{% /def %}} +{{% def id="web-server" name="网页服务器" english="Web server" %}} 提供网页服务的软件，广义上也可以指运行该软件的硬件。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E7%B6%B2%E9%A0%81%E4%BC%BA%E6%9C%8D%E5%99%A8)。 {{% /def %}} -{{% def id="wildcard" name="通配符证书" english="Wildcard Certificate" %}} 对下一级子域名有效的证书。 例如，[SAN](#def-SAN) 只包含 `*.example.com` 的证书对 `blog.example.com` 和 `www.example.com` 都有效，但对 `bork.bork.example.com` 和 `example.com` 都**无效**。 在子域名处使用星号（*）即表示通配符。 [Let's Encrypt](#def-LE) [从 2018 年 3 月起提供通配符证书](https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579)。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E9%80%9A%E9%85%8D%E7%AC%A6%E8%AF%81%E4%B9%A6)。 {{% /def %}} +{{% def id="wildcard" name="通配符证书" english="Wildcard Certificate" %}} 对下一级子域名有效的证书。例如，[SAN](#def-SAN) 只包含 `*.example.com` 的证书对 `blog.example.com` 和 `www.example.com` 都有效，但对 `bork.bork.example.com` 和 `example.com` 都**无效**。在子域名处使用星号（*）即表示通配符。 [Let's Encrypt](#def-LE) [从 2018 年 3 月起提供通配符证书](https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579)。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/%E9%80%9A%E9%85%8D%E7%AC%A6%E8%AF%81%E4%B9%A6)。 {{% /def %}} -{{% def id="X509" abbr="X.509" %}} 定义了公钥证书格式的标准。 参见[维基百科条目](https://zh.wikipedia.org/zh-cn/X.509)。 {{% /def %}} +{{% def id="X509" abbr="X.509" %}} 定义了公钥证书格式的标准。参见[维基百科条目](https://zh.wikipedia.org/zh-cn/X.509)。 {{% /def %}} {{% renderglossary %}} diff --git a/content/zh-cn/docs/godaddy.md b/content/zh-cn/docs/godaddy.md index aca8d490f2..446f1ba4fd 100644 --- a/content/zh-cn/docs/godaddy.md +++ b/content/zh-cn/docs/godaddy.md @@ -5,11 +5,11 @@ lastmod: 2025-08-11 show_lastmod: 1 --- -我们收到了很多关于如何在 GoDaddy 平台上使用 Let’s Encrypt 证书的问题。 GoDaddy 不支持通过 [ACME 协议](https://tools.ietf.org/html/rfc8555)自动完成证书的申请与续期， 而是提供了一项自动续期的[付费功能](https://www.godaddy.com/web-security/ssl-certificate)，只能用于由他们所签发的证书。 +我们收到了很多关于如何在 GoDaddy 平台上使用 Let’s Encrypt 证书的问题。 GoDaddy 不支持通过 [ACME 协议](https://tools.ietf.org/html/rfc8555)自动完成证书的申请与续期，而是提供了一项自动续期的[付费功能](https://www.godaddy.com/web-security/ssl-certificate)，只能用于由他们所签发的证书。 -目前我们不建议在 GoDaddy 上使用我们的证书，因为其操作流程复杂，且无法自动化实现。 但我们认为，自动续期是证书管理中至关重要的一部分， 由软件实现的自动续期能够大幅降低证书过期失效的风险。 +目前我们不建议在 GoDaddy 上使用我们的证书，因为其操作流程复杂，且无法自动化实现。但我们认为，自动续期是证书管理中至关重要的一部分，由软件实现的自动续期能够大幅降低证书过期失效的风险。 如果您仍想尝试在 GoDaddy 平台上使用 Let’s Encrypt 证书，有以下途径可以考虑： 1. 使用 Griffin Software 开发的 [CertSage](https://certsage.com/) 软件。 GoDaddy 平台上的其他 Let's Encrypt 用户已有成功的先例。 -2. 遵循 GoDaddy 提供的[操作指引](https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023)， 但我们无法保证其信息的准确性和正确性。 请注意，该流程非常耗时，并且每次证书到期前都需要您手动执行。 +2. 遵循 GoDaddy 提供的[操作指引](https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023)，但我们无法保证其信息的准确性和正确性。请注意，该流程非常耗时，并且每次证书到期前都需要您手动执行。 diff --git a/content/zh-cn/docs/integration-guide.md b/content/zh-cn/docs/integration-guide.md index f7c00eb20d..f9c0d7841b 100644 --- a/content/zh-cn/docs/integration-guide.md +++ b/content/zh-cn/docs/integration-guide.md @@ -10,7 +10,7 @@ show_lastmod: 1 # 做好更改准备 -Let's Encrypt 和 Web PKI 都将随着时间的推移而不断发展。 您应该确保能够轻松更新所有使用 Let's Encrypt 的服务。 如果您还要部署依赖于 Let's Encrypt 证书的客户端，请特别确保这些客户端定期收到更新。 +Let's Encrypt 和 Web PKI 都将随着时间的推移而不断发展。您应该确保能够轻松更新所有使用 Let's Encrypt 的服务。如果您还要部署依赖于 Let's Encrypt 证书的客户端，请特别确保这些客户端定期收到更新。 将来，这些事情可能会发生变化： @@ -19,102 +19,102 @@ Let's Encrypt 和 Web PKI 都将随着时间的推移而不断发展。 您应 * 我们愿意用于对终端实体证书进行签名的密钥类型和密钥强度 * ACME 协议 -我们将始终尽可能提前通知此类更改，但如果在某些组件中发现严重的安全漏洞，我们可能需要在短期内或立即进行更改。 特别是对于中间证书改变，你不应该硬编码中间证书，而应该使用 ACME 协议中的 [`Link: rel="up"`](https://tools.ietf.org/html/rfc8555#section-7.4.2)标头，因为中间证书很可能会改变。 +我们将始终尽可能提前通知此类更改，但如果在某些组件中发现严重的安全漏洞，我们可能需要在短期内或立即进行更改。特别是对于中间证书改变，你不应该硬编码中间证书，而应该使用 ACME 协议中的 [`Link: rel="up"`](https://tools.ietf.org/html/rfc8555#section-7.4.2)标头，因为中间证书很可能会改变。 -类似地，服务条款 (ToS) 变更时，其网址也很有可能发生变化。 请避免硬编码 ToS 链接，而是使用 [`Link：rel =“terms-of-service”`](https://tools.ietf.org/html/rfc8555#section-7.3.3) 标头确定要使用的 ToS 链接。 +类似地，服务条款 (ToS) 变更时，其网址也很有可能发生变化。请避免硬编码 ToS 链接，而是使用 [`Link：rel =“terms-of-service”`](https://tools.ietf.org/html/rfc8555#section-7.3.3) 标头确定要使用的 ToS 链接。 要接收有关上述重要更改的小批量更新，请订阅我们的 [API 公告](https://community.letsencrypt.org/t/about-the-api-announcements-category/23836)分类。这对客户端开发人员和托管提供商都很有用。 # 获取更新 -要接收有关上述重要更改的小批量更新，请订阅我们的 \[API 公告\](https://community.letsencrypt.org/t/about-the-api-announcements-category/23836)分类。 这对客户端开发人员和托管提供商都很有用。 +要接收有关上述重要更改的小批量更新，请订阅我们的 \[API 公告\](https://community.letsencrypt.org/t/about-the-api-announcements-category/23836)分类。这对客户端开发人员和托管提供商都很有用。 -有关维护和停机的更高容量更新，请访问我们的\[状态页面\](https://letsencrypt.status.io/)并点击右上方的"订阅"按钮。 这对托管服务提供商最为有用。 +有关维护和停机的更高容量更新，请访问我们的\[状态页面\](https://letsencrypt.status.io/)并点击右上方的"订阅"按钮。这对托管服务提供商最为有用。 # 谁是用户 -正如我们的 [CP/CPS 和用户协议](/repository)所述，用户指的是私钥的持有者。 因此，对于托管服务提供商而言，用户是提供商自身，而非其客户。 如果您正在编写允许人们自行部署的软件，那用户就是部署软件的人。 +正如我们的 [CP/CPS 和用户协议](/repository)所述，用户指的是私钥的持有者。因此，对于托管服务提供商而言，用户是提供商自身，而非其客户。如果您正在编写允许人们自行部署的软件，那用户就是部署软件的人。 -这意味着如果您是托管服务提供商，无需要求客户同意我们的用户协议， 只需为您持有的域名申请证书并使用即可。 +这意味着如果您是托管服务提供商，无需要求客户同意我们的用户协议，只需为您持有的域名申请证书并使用即可。 # 使用一个还是多个账户？ -在 ACME 中，可以创建一个帐户并将其用于所有授权和颁发，或者为每个客户创建一个帐户。 这种灵活性可能很有价值。 例如，一些主机提供商可能希望每个客户使用一个帐户，并将帐户密钥存储在不同的地方中，这样即使帐户密钥泄露也不会允许攻击者给所有用户颁发证书。 +在 ACME 中，可以创建一个帐户并将其用于所有授权和颁发，或者为每个客户创建一个帐户。这种灵活性可能很有价值。例如，一些主机提供商可能希望每个客户使用一个帐户，并将帐户密钥存储在不同的地方中，这样即使帐户密钥泄露也不会允许攻击者给所有用户颁发证书。 -但是，对于大多数大型托管服务提供商，我们建议使用单个帐户并保护相应的帐户密钥。 从而明确证书归属，且便于按需调整速率限制。 如果您使用许多不同的帐户，我们将无法有效调整速率限制。 +但是，对于大多数大型托管服务提供商，我们建议使用单个帐户并保护相应的帐户密钥。从而明确证书归属，且便于按需调整速率限制。如果您使用许多不同的帐户，我们将无法有效调整速率限制。 # 多域名 (SAN) 证书 -我们每份证书最多支持 100 个域名，具体取决于您所选的[证书配置](/docs/profiles/)。 您可以为每个域名都申请一份证书，也可以只用几份证书覆盖大量域名。 +我们每份证书最多支持 100 个域名，具体取决于您所选的[证书配置](/docs/profiles/)。您可以为每个域名都申请一份证书，也可以只用几份证书覆盖大量域名。 -每个域名使用单独的证书可以简化域名增删的流程， 同时减小证书体积，从而在带宽较低的网络上缩短建立 HTTPS 连接所需的时间。 您可以查看[速率限制](/docs/rate-limits)了解可申请的证书数量。 +每个域名使用单独的证书可以简化域名增删的流程，同时减小证书体积，从而在带宽较低的网络上缩短建立 HTTPS 连接所需的时间。您可以查看[速率限制](/docs/rate-limits)了解可申请的证书数量。 -另一方面，一份证书也可以包含大量域名，从而减少需要管理的证书数量。 如果您需要兼容 Windows XP 等不支持 TLS [服务器名称指示](https://zh.wikipedia.org/wiki/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA) (SNI) 的早期客户端，则每份证书都必须由不同的 IP 地址提供服务，因此每份证书包含的域名越多，您所需要的 IP 地址就越少。 +另一方面，一份证书也可以包含大量域名，从而减少需要管理的证书数量。如果您需要兼容 Windows XP 等不支持 TLS [服务器名称指示](https://zh.wikipedia.org/wiki/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA) (SNI) 的早期客户端，则每份证书都必须由不同的 IP 地址提供服务，因此每份证书包含的域名越多，您所需要的 IP 地址就越少。 绝大多数情况下，这两种证书管理方式都是安全的。 # 存储和重用证书和密钥 -Let's Encrypt 的主要价值在于我们允许在创建新网站时自动颁发证书。 但是，如果您的基础架构可能会为同一网站重复创建新的前端服务器，那么这些前端应该首先尝试使用来自持久性存储的证书和私钥，并且只在没有可用的证书或者所有现有的证书都已过期的情况下颁发新证书。 +Let's Encrypt 的主要价值在于我们允许在创建新网站时自动颁发证书。但是，如果您的基础架构可能会为同一网站重复创建新的前端服务器，那么这些前端应该首先尝试使用来自持久性存储的证书和私钥，并且只在没有可用的证书或者所有现有的证书都已过期的情况下颁发新证书。 -对于 Let's Encrypt，这有助于我们为尽可能多的人高效地提供服务。 对您而言，这可以确保您能够随时随地部署您的网站，无论 Let's Encrypt 的状态如何。 +对于 Let's Encrypt，这有助于我们为尽可能多的人高效地提供服务。对您而言，这可以确保您能够随时随地部署您的网站，无论 Let's Encrypt 的状态如何。 -例如，许多站点正在开始使用 Docker 按需配置新的前端实例。 如果您将 Docker 容器设置为在启动时颁发证书，并且您没有持久性地存储证书和密钥，那么您如果一次启动太多实例，就可能会达到速率限制。 在最坏情况下，如果您一次性销毁并重新创建所有实例，就有可能导致所有实例都无法获取证书，您的网站可能会停摆数天，直至速率限制解除。 而且不仅仅是速率限制会导致这类问题。 如果在需要启动前端时 Let's Encrypt 出于任何原因不可用，您就会遇到同样的问题。 +例如，许多站点正在开始使用 Docker 按需配置新的前端实例。如果您将 Docker 容器设置为在启动时颁发证书，并且您没有持久性地存储证书和密钥，那么您如果一次启动太多实例，就可能会达到速率限制。在最坏情况下，如果您一次性销毁并重新创建所有实例，就有可能导致所有实例都无法获取证书，您的网站可能会停摆数天，直至速率限制解除。而且不仅仅是速率限制会导致这类问题。如果在需要启动前端时 Let's Encrypt 出于任何原因不可用，您就会遇到同样的问题。 -请注意，某些部署原则指出加密密钥永远不能离开生成它们的物理机器。 只要您确保机器及其数据可以长期使用，并且您仔细管理速率限制，此模型就可以正常使用 Let's Encrypt。 +请注意，某些部署原则指出加密密钥永远不能离开生成它们的物理机器。只要您确保机器及其数据可以长期使用，并且您仔细管理速率限制，此模型就可以正常使用 Let's Encrypt。 # 选择验证方式 -您如果正在使用 http-01 ACME 进行验证，则需要先向每个前端提供验证用的回复，然后才能通知 Let's Encrypt 您已准备好进行验证。 如果您有很多前端服务器，这么做可能非常困难。 在这种情况下，使用 dns-01 进行验证可能会更容易。 当然，您如果有许多地理位置分散的 DNS 响应服务器，则必须确保每个响应服务器上都有验证所需的 TXT 记录。 +您如果正在使用 http-01 ACME 进行验证，则需要先向每个前端提供验证用的回复，然后才能通知 Let's Encrypt 您已准备好进行验证。如果您有很多前端服务器，这么做可能非常困难。在这种情况下，使用 dns-01 进行验证可能会更容易。当然，您如果有许多地理位置分散的 DNS 响应服务器，则必须确保每个响应服务器上都有验证所需的 TXT 记录。 此外，在使用 dns-01 进行验证时，请务必清理旧的 TXT 记录，以确保对 Let's Encrypt 的查询的回复不会太大。 -如果您想无论如何都要使用 http-01 进行验证，您也许可以利用 HTTP 重定向。 例如，对于任意的 `XYZ` 字符串，您可以让所有前端的 `/.well-known/acme-challenge/XYZ` 路径都跳转至 `validation-server.example.com/XYZ`。 此时 `validation-server` 也承担了申请证书的部分职责，故该服务器的安全同样需要妥善保护。 +如果您想无论如何都要使用 http-01 进行验证，您也许可以利用 HTTP 重定向。例如，对于任意的 `XYZ` 字符串，您可以让所有前端的 `/.well-known/acme-challenge/XYZ` 路径都跳转至 `validation-server.example.com/XYZ`。此时 `validation-server` 也承担了申请证书的部分职责，故该服务器的安全同样需要妥善保护。 # 中央验证服务器 -与上述两点相关，您如果有很多前端服务器，可能需要使用较小的服务器子集来管理证书颁发。 这样可以更轻松地使用重定向进行 http-01 验证，并提供长期存储证书和密钥的位置。 +与上述两点相关，您如果有很多前端服务器，可能需要使用较小的服务器子集来管理证书颁发。这样可以更轻松地使用重定向进行 http-01 验证，并提供长期存储证书和密钥的位置。 # 防火墙配置 -为了正常使用 Let's Encrypt，您需要允许运行 ACME 客户端的设备向外与 443 端口建立连接。 我们的 ACME 服务的 IP 地址范围不对外公开，并且随时可能变动，恕不另行告知。 +为了正常使用 Let's Encrypt，您需要允许运行 ACME 客户端的设备向外与 443 端口建立连接。我们的 ACME 服务的 IP 地址范围不对外公开，并且随时可能变动，恕不另行告知。 -如果您 “http-01” ACME 验证方法，您需要允许 80 端口上的入站通信。 我们发起测试所使用的 IP 地址范围同样不公开，且随时可能变动，恕不另行告知。 +如果您 “http-01” ACME 验证方法，您需要允许 80 端口上的入站通信。我们发起测试所使用的 IP 地址范围同样不公开，且随时可能变动，恕不另行告知。 -注意：我们建议您的网页服务器始终允许无加密的明文 HTTP 连接，并重定向至 HTTPS。 相比直接拒绝对 80 端口的连接，这种方式能够提升用户体验，并且不会影响安全性。 +注意：我们建议您的网页服务器始终允许无加密的明文 HTTP 连接，并重定向至 HTTPS。相比直接拒绝对 80 端口的连接，这种方式能够提升用户体验，并且不会影响安全性。 对于所有的验证方式，您的权威 DNS 服务器都必须能够在 53 端口（包括 TCP 和 UDP）上接收流量。 # 支持的密钥算法 -Let's Encrypt 接受 2048、3072 或 4096 位的 RSA 密钥以及 P-256 或 P-384 曲线的 ECDSA 密钥。 对于帐户密钥和证书密钥来说都是如此。 您不能将帐户密钥重用为证书密钥。 +Let's Encrypt 接受 2048、3072 或 4096 位的 RSA 密钥以及 P-256 或 P-384 曲线的 ECDSA 密钥。对于帐户密钥和证书密钥来说都是如此。您不能将帐户密钥重用为证书密钥。 我们建议托管服务提供商自动颁发证书并为其控制的所有主机名配置 HTTPS，并且允许用户选择是否将 HTTP 链接重定向到等效的 HTTPS 链接。我们建议为现有帐户在默认情况下禁用该设置，但为新帐户在默认情况下启用该设置。 # 默认使用 HTTPS -对于网站托管服务商，我们建议为您所控制的所有域名自动申请证书并配置 HTTPS，同时允许用户选择是否将 HTTP 网址重定向至对应的 HTTPS 路径。 对于现有的账户，我们建议默认关闭这一选项，但新账户则建议默认开启。 +对于网站托管服务商，我们建议为您所控制的所有域名自动申请证书并配置 HTTPS，同时允许用户选择是否将 HTTP 网址重定向至对应的 HTTPS 路径。对于现有的账户，我们建议默认关闭这一选项，但新账户则建议默认开启。 -上述建议的理由在于，现有的网站可能包含部分未加密的 HTTP 资源（如脚本、样式表和图片）， 如果贸然重定向至 HTTPS，浏览器可能会因为协议混用而屏蔽这些资源， 从而影响网站的功能。 但新建网站的用户发现重定向至 HTTPS 后会自然地使用 HTTPS 资源，因为一旦使用未加密的 HTTP 资源就会注意到问题所在。 +上述建议的理由在于，现有的网站可能包含部分未加密的 HTTP 资源（如脚本、样式表和图片），如果贸然重定向至 HTTPS，浏览器可能会因为协议混用而屏蔽这些资源，从而影响网站的功能。但新建网站的用户发现重定向至 HTTPS 后会自然地使用 HTTPS 资源，因为一旦使用未加密的 HTTP 资源就会注意到问题所在。 -我们建议允许客户配置 HTTP 的 Strict-Transport-Security (HSTS) 标头，并将默认的 max-age 设为 60 天。 然而，此类设置也应当附有警告，如果客户将来切换至不支持 HTTPS 的托管服务商，那么访客浏览器所缓存的 HSTS 设置将导致网站无法正常访问。 此外，客户与服务商均应注意，HSTS 标头会导致所有证书错误都演变为硬性故障。 例如在通常情况下，即使证书已过期或名称不匹配，用户也可以在浏览器中点击忽略错误，但 HSTS 生效后浏览器就不会再允许此类操作。 +我们建议允许客户配置 HTTP 的 Strict-Transport-Security (HSTS) 标头，并将默认的 max-age 设为 60 天。然而，此类设置也应当附有警告，如果客户将来切换至不支持 HTTPS 的托管服务商，那么访客浏览器所缓存的 HSTS 设置将导致网站无法正常访问。此外，客户与服务商均应注意，HSTS 标头会导致所有证书错误都演变为硬性故障。例如在通常情况下，即使证书已过期或名称不匹配，用户也可以在浏览器中点击忽略错误，但 HSTS 生效后浏览器就不会再允许此类操作。 # 续期时间 我们建议每天至少[查询 ACME 更新信息](https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients/) (ARI) 两次， ARI 接口会给出推荐的续期时间。 -若不使用 ARI，我们建议在证书有效期剩余三分之一时自动续期。 对于有效期不足十天的证书，我们建议在有效期剩余一半时续期。 也就是说，对于 Let's Encrypt 当前颁发的有效期 90 天的证书，建议在到期前第 30 天续期。 +若不使用 ARI，我们建议在证书有效期剩余三分之一时自动续期。对于有效期不足十天的证书，我们建议在有效期剩余一半时续期。也就是说，对于 Let's Encrypt 当前颁发的有效期 90 天的证书，建议在到期前第 30 天续期。 -另外，如果您需要为超过 10000 个域名申请证书，我们建议分批依次执行续期，而非大规模集中完成。 这是为了降低风险：即使 Let's Encrypt 在您需要续期时服务中断，或者您的证书续期系统暂时故障，也只有一部分证书会受影响。 另一方面，这样做也便于我们预测服务负载。 +另外，如果您需要为超过 10000 个域名申请证书，我们建议分批依次执行续期，而非大规模集中完成。这是为了降低风险：即使 Let's Encrypt 在您需要续期时服务中断，或者您的证书续期系统暂时故障，也只有一部分证书会受影响。另一方面，这样做也便于我们预测服务负载。 -首次获取证书时您可以一次性为所有域名完成申请， 然后将第一次续期时间错开，例如部分证书提前一天续期、另一部分证书提前两天续期等等。 +首次获取证书时您可以一次性为所有域名完成申请，然后将第一次续期时间错开，例如部分证书提前一天续期、另一部分证书提前两天续期等等。 -如果您开发的客户端软件会自动创建定时任务，请务必随机设置其执行的时间点，而非统一设为某个固定时刻。 这可以防止 Let's Encrypt 在每小时或每分钟的第一秒遭遇流量突增。 由于 Let's Encrypt 需要根据峰值负载规划服务器资源分配，避免流量突增可以帮助我们降低成本。 +如果您开发的客户端软件会自动创建定时任务，请务必随机设置其执行的时间点，而非统一设为某个固定时刻。这可以防止 Let's Encrypt 在每小时或每分钟的第一秒遭遇流量突增。由于 Let's Encrypt 需要根据峰值负载规划服务器资源分配，避免流量突增可以帮助我们降低成本。 # 验证失败后重试 -续期失败不应被视为无法解决的错误， 您应当采用指数退避的方式实现平滑的重试逻辑，使频率最终收敛至每份证书每天重试一次。 例如，一种合理的重试方式为：第一次重试前等待 1 分钟，第二次重试前等待 10 分钟，第三次重试前等待 100 分钟，第四次及后续重试前均等待一天。 当然，您也应当允许系统管理员提前对部分或所有域名发起重试。 +续期失败不应被视为无法解决的错误，您应当采用指数退避的方式实现平滑的重试逻辑，使频率最终收敛至每份证书每天重试一次。例如，一种合理的重试方式为：第一次重试前等待 1 分钟，第二次重试前等待 10 分钟，第三次重试前等待 100 分钟，第四次及后续重试前均等待一天。当然，您也应当允许系统管理员提前对部分或所有域名发起重试。 -采用退避机制意味着您的软件不仅需要记录成功的操作，还需要记录失败的操作，从而决定能否发起新的证书申请。 每小时尝试申请上百次是没有意义的，因为重复的失败往往会不断持续。 +采用退避机制意味着您的软件不仅需要记录成功的操作，还需要记录失败的操作，从而决定能否发起新的证书申请。每小时尝试申请上百次是没有意义的，因为重复的失败往往会不断持续。 另外，所有的错误信息均应发送给相应的系统管理员，以便解决可能存在的问题。 diff --git a/content/zh-cn/docs/ipv6.md b/content/zh-cn/docs/ipv6.md index c988b54608..5177828d77 100644 --- a/content/zh-cn/docs/ipv6.md +++ b/content/zh-cn/docs/ipv6.md @@ -10,13 +10,13 @@ Let's Encrypt既支持在IPv6环境下使用ACME客户端访问ACME API，也支 ## 域名验证 -当对同时具有IPv4和IPv6地址的域发出出站域验证请求时（例如，`A`和`AAAA`记录），Let's Encrypt将始终用IPv6地址进行初始连接。 如果IPv6连接在网络级别失败（例如超时），并且有可用的IPv4地址，则我们将使用其中一个IPv4地址重试该请求。 +当对同时具有IPv4和IPv6地址的域发出出站域验证请求时（例如，`A`和`AAAA`记录），Let's Encrypt将始终用IPv6地址进行初始连接。如果IPv6连接在网络级别失败（例如超时），并且有可用的IPv4地址，则我们将使用其中一个IPv4地址重试该请求。 ## IPv6地址错误 -有些时候，域名所有者不会知道其域名的`AAAA`记录。 如果`AAAA`记录中的IPv6地址不正确，将影响域验证过程。 +有些时候，域名所有者不会知道其域名的`AAAA`记录。如果`AAAA`记录中的IPv6地址不正确，将影响域验证过程。 -通常情况下，IPv6地址将与运行ACME客户端的IPv4地址不在同一服务器。 由于ACME客户端仅将IPv4服务器配置为响应质询，因此在使用IPv6服务器时，域名验证将失败。 +通常情况下，IPv6地址将与运行ACME客户端的IPv4地址不在同一服务器。由于ACME客户端仅将IPv4服务器配置为响应质询，因此在使用IPv6服务器时，域名验证将失败。 在大多数情况下，正确的解决方法是更新IPv6地址以指向运行ACME客户端的服务器。如果该域名不打算使用IPv6，则删除`AAAA`记录。 Let's Encrypt没有办法强制使用IPv4记录验证域名所有权，您必须解决错误的配置问题。 @@ -24,11 +24,11 @@ Let's Encrypt既支持在IPv6环境下使用ACME客户端访问ACME API，也支 IPv6到IPv4重试仅在连接超时时发生，而不在其他类型的错误时发生。 -例如，在上述场景中，如果有一台网页服务器通过 IPv6 地址提供服务，但不支持处理 ACME 质询，则我们不会再尝试连接 IPv4 地址， 因为这种情况下 IPv6 连接并没有超时，质询会由于响应错误直接失败，没有重试的机会。 +例如，在上述场景中，如果有一台网页服务器通过 IPv6 地址提供服务，但不支持处理 ACME 质询，则我们不会再尝试连接 IPv4 地址，因为这种情况下 IPv6 连接并没有超时，质询会由于响应错误直接失败，没有重试的机会。 -为了简化我们的CA软件，我们仅在验证"http-01"挑战时才对第一个请求执行IPv6到IPv4重试。 如果您使用重定向，则重定向将不会得到重试处理。 +为了简化我们的CA软件，我们仅在验证"http-01"挑战时才对第一个请求执行IPv6到IPv4重试。如果您使用重定向，则重定向将不会得到重试处理。 -例如，如果该域名的`AAAA`记录总是超时，并且网络服务器的`A`记录从HTTP重定向到HTTPS，则IPv6将无法正常倒退至IPv4。 对该域的第一个请求将正确的退回IPv4， 从而接收到从HTTP至HTTPS的重定向， 后续请求将仍旧优先使用IPv6地址，但是将访问超时并不会倒退会IPv4。 您可以通过解决IPv6配置错误或删除对ACME HTTP-01请求的重定向来解决这种情况。 +例如，如果该域名的`AAAA`记录总是超时，并且网络服务器的`A`记录从HTTP重定向到HTTPS，则IPv6将无法正常倒退至IPv4。对该域的第一个请求将正确的退回IPv4， 从而接收到从HTTP至HTTPS的重定向，后续请求将仍旧优先使用IPv6地址，但是将访问超时并不会倒退会IPv4。您可以通过解决IPv6配置错误或删除对ACME HTTP-01请求的重定向来解决这种情况。 ## 寻求帮助 diff --git a/content/zh-cn/docs/lencr-org.md b/content/zh-cn/docs/lencr-org.md index afd171a989..00d3ec6625 100644 --- a/content/zh-cn/docs/lencr-org.md +++ b/content/zh-cn/docs/lencr-org.md @@ -8,27 +8,27 @@ show_lastmod: 1 # `lencr.org` 是什么？ -`lencr.org` 是 Let's Encrypt 旗下的一个域名。 我们颁发的证书中有部分数据指向该域名。 +`lencr.org` 是 Let's Encrypt 旗下的一个域名。我们颁发的证书中有部分数据指向该域名。 -# 我的电脑为什么会从这个网站获取数据？ 这是恶意的吗？ +# 我的电脑为什么会从这个网站获取数据？这是恶意的吗？ -不，`lencr.org` 网站上没有任何恶意数据。 设备会连接到 `lencr.org` 是因为设备上的软件（比如浏览器或应用）连接了另外一个使用 Let's Encrypt 证书的网站，正在核实证书是否有效。 这是很多客户端的正常流程。 +不，`lencr.org` 网站上没有任何恶意数据。设备会连接到 `lencr.org` 是因为设备上的软件（比如浏览器或应用）连接了另外一个使用 Let's Encrypt 证书的网站，正在核实证书是否有效。这是很多客户端的正常流程。 -我们无法断言上述的*另外一个网站*是否存在风险， 如果您正在调查异常的网络活动，或许应该关注与 `lencr.org` 紧邻的上一条连接。 +我们无法断言上述的*另外一个网站*是否存在风险，如果您正在调查异常的网络活动，或许应该关注与 `lencr.org` 紧邻的上一条连接。 -客户端与 `lencr.org` 之间的连接模式可能较为反常，没有规律可循。 有些客户端从来不会从该网站获取数据，有些则只下载部分数据，或者出于性能考虑缓存了部分数据，因此只会偶尔（首次下载以及数据过期后）建立连接。 +客户端与 `lencr.org` 之间的连接模式可能较为反常，没有规律可循。有些客户端从来不会从该网站获取数据，有些则只下载部分数据，或者出于性能考虑缓存了部分数据，因此只会偶尔（首次下载以及数据过期后）建立连接。 # 数据内容究竟是什么？ -客户端程序（比如浏览器或应用）连接网站并收到一份证书时，需要核实证书是否真实有效。 以下数据可以从各个角度帮助客户端达成这一目的。 +客户端程序（比如浏览器或应用）连接网站并收到一份证书时，需要核实证书是否真实有效。以下数据可以从各个角度帮助客户端达成这一目的。 * `c.lencr.org` 提供了证书吊销列表 (CRL)，包含我们颁发后未过期就被提前吊销的所有证书。 -* `i.lencr.org` 提供了我们的“颁发者”中间证书，经过我们的根证书签名，或是由其他证书颁发机构 (CA) “交叉签名”。 客户端可以依据此信息通过一份或多份中间证书追溯至其认可的根证书，从而确认待核实的证书的“信任链”。 +* `i.lencr.org` 提供了我们的“颁发者”中间证书，经过我们的根证书签名，或是由其他证书颁发机构 (CA) “交叉签名”。客户端可以依据此信息通过一份或多份中间证书追溯至其认可的根证书，从而确认待核实的证书的“信任链”。 # 为什么用 "`lencr.org`"？ -我们也用过更长的网址，比如 `http://example.int-x3.letsencrypt.org/`。 但在颁发[新的根证书和中间证书][1]时，我们决定尽可能缩短网址的长度。 每天有数十亿 HTTPS 连接在互联网上建立，每条连接都要传输一份证书，因此证书的每个字节都举足轻重。 我们选择 `lencr.org` 因为它与我们的名称相似： **L**et's **ENCR**ypt。 其读法类似 Terry Pratchett 所著小说《碟形世界》中名为 [Lancre][] 的虚构地区。 +我们也用过更长的网址，比如 `http://example.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 [Lancre]: https://wiki.lspace.org/Lancre diff --git a/content/zh-cn/docs/monitoring-options.md b/content/zh-cn/docs/monitoring-options.md index ad18d4b1ac..75461ff51d 100644 --- a/content/zh-cn/docs/monitoring-options.md +++ b/content/zh-cn/docs/monitoring-options.md @@ -5,9 +5,9 @@ lastmod: 2026-07-13 show_lastmod: 1 --- -许多用户都希望能够监测 TLS 证书的状态， 这时专业的证书监测服务就可以派上用场，例如在证书即将到期时发出提醒，并为您留意是否有异常的证书签发活动。 +许多用户都希望能够监测 TLS 证书的状态，这时专业的证书监测服务就可以派上用场，例如在证书即将到期时发出提醒，并为您留意是否有异常的证书签发活动。 -Let’s Encrypt 较为推荐的服务是 [Red Sift Certificates Lite](https://redsift.com/pulse-platform/certificates-lite)（过去名为 Hardenize）， 您可以通过 Red Sift 免费监测 250 份证书。 +Let’s Encrypt 较为推荐的服务是 [Red Sift Certificates Lite](https://redsift.com/pulse-platform/certificates-lite)（过去名为 Hardenize），您可以通过 Red Sift 免费监测 250 份证书。 市面上有多款监测服务可供选择，包括： @@ -23,4 +23,4 @@ Let’s Encrypt 较为推荐的服务是 [Red Sift Certificates Lite](https://re 请注意，以上服务均由第三方提供，与 ISRG / Let's Encrypt 无关。 -本页面提供的信息仅供参考， ISRG 不为上述任何服务背书，也不保证其安全性、可靠性或有效性， 建议用户自行调研后谨慎选择。 ISRG 对使用此类服务所产生的一切后果概不负责。 +本页面提供的信息仅供参考， ISRG 不为上述任何服务背书，也不保证其安全性、可靠性或有效性，建议用户自行调研后谨慎选择。 ISRG 对使用此类服务所产生的一切后果概不负责。 diff --git a/content/zh-cn/docs/oids.md b/content/zh-cn/docs/oids.md index 81d7233e10..763c83e104 100644 --- a/content/zh-cn/docs/oids.md +++ b/content/zh-cn/docs/oids.md @@ -5,42 +5,42 @@ lastmod: 2025-09-25 show_lastmod: false --- -对象标识符 (OID) 是一串由圆点分隔的数字，在 WebPKI 中用于唯一地标识各类对象。 例如，X.509 中的每种扩展字段都由一个 OID 唯一标识，比如 OID `2.5.29.15` 表示这是[密钥用途](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)扩展。 类似地，在[证书策略](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4)扩展中，OID `2.23.140.1.2.1` 则表示该证书已根据 [CA/浏览器论坛的“域名验证”标准](https://github.com/cabforum/servercert/blob/main/docs/BR.md#12-document-name-and-identification)签发。 +对象标识符 (OID) 是一串由圆点分隔的数字，在 WebPKI 中用于唯一地标识各类对象。例如，X.509 中的每种扩展字段都由一个 OID 唯一标识，比如 OID `2.5.29.15` 表示这是[密钥用途](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)扩展。类似地，在[证书策略](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4)扩展中，OID `2.23.140.1.2.1` 则表示该证书已根据 [CA/浏览器论坛的“域名验证”标准](https://github.com/cabforum/servercert/blob/main/docs/BR.md#12-document-name-and-identification)签发。 本页面记载了 Let's Encrypt 所使用的各类 OID 及其含义和使用场景。 -| OID | 描述 | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1.3.6.1.4.1.44947 | 互联网安全研究组。 这是 ISRG 的顶层 OID。 | -| 1.3.6.1.4.1.44947.1 | 未赋予任何含义。 这一遗留的 OID 从未被单独使用过。 | -| 1.3.6.1.4.1.44947.1.1 | 未赋予任何含义。 这一遗留的 OID 从未被单独使用过。 | -| 1.3.6.1.4.1.44947.1.1.1 | 经过 ISRG 域名验证。 这一遗留的 OID 和 [CA/BF 域名验证证书策略的 OID](https://github.com/cabforum/servercert/blob/main/docs/BR.md#12-document-name-and-identification) 2.23.140.1.2.1 的含义相同， 过去曾在我们的[中间证书](/certs/lets-encrypt-e1.txt)中出现，但为了减小证书大小，现已不再使用。 | -| 1.3.6.1.4.1.44947.2 | Let's Encrypt 信任锚点 ID。 这是所有“信任锚点”（即 [CA 密钥](/certificates)）的顶层 OID，可用于[信任锚点标识符](https://datatracker.ietf.org/doc/draft-ietf-tls-trust-anchor-ids/)和 [Merkle 树证书](https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/)互联网标准草案中。 下级 OID 大致按照对应证书的签发时间分配。 | -| 1.3.6.1.4.1.44947.2.1 | ISRG Root X1 | -| 1.3.6.1.4.1.44947.2.2 | Let's Encrypt Authority X1 | -| 1.3.6.1.4.1.44947.2.3 | Let's Encrypt Authority X2 | -| 1.3.6.1.4.1.44947.2.4 | Let's Encrypt Authority X3 | -| 1.3.6.1.4.1.44947.2.5 | Let's Encrypt Authority X4 | -| 1.3.6.1.4.1.44947.2.6 | ISRG Root X2 | -| 1.3.6.1.4.1.44947.2.7 | Let's Encrypt E1 | -| 1.3.6.1.4.1.44947.2.8 | Let's Encrypt E2 | -| 1.3.6.1.4.1.44947.2.9 | Let's Encrypt R3 | -| 1.3.6.1.4.1.44947.2.10 | Let's Encrypt R4 | -| 1.3.6.1.4.1.44947.2.11 | Let's Encrypt E5 | -| 1.3.6.1.4.1.44947.2.12 | Let's Encrypt E6 | -| 1.3.6.1.4.1.44947.2.13 | Let's Encrypt E7 | -| 1.3.6.1.4.1.44947.2.14 | Let's Encrypt E8 | -| 1.3.6.1.4.1.44947.2.15 | Let's Encrypt E9 | -| 1.3.6.1.4.1.44947.2.16 | Let's Encrypt R10 | -| 1.3.6.1.4.1.44947.2.17 | Let's Encrypt R11 | -| 1.3.6.1.4.1.44947.2.18 | Let's Encrypt R12 | -| 1.3.6.1.4.1.44947.2.19 | Let's Encrypt R13 | -| 1.3.6.1.4.1.44947.2.20 | Let's Encrypt R14 | -| 1.3.6.1.4.1.44947.2.21 | ISRG Root YE | -| 1.3.6.1.4.1.44947.2.22 | ISRG Root YR | -| 1.3.6.1.4.1.44947.2.23 | Let's Encrypt YE1 | -| 1.3.6.1.4.1.44947.2.24 | Let's Encrypt YE2 | -| 1.3.6.1.4.1.44947.2.25 | Let's Encrypt YE3 | -| 1.3.6.1.4.1.44947.2.26 | Let's Encrypt YR1 | -| 1.3.6.1.4.1.44947.2.27 | Let's Encrypt YR2 | -| 1.3.6.1.4.1.44947.2.28 | Let's Encrypt YR3 | +| OID | 描述 | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1.3.6.1.4.1.44947 | 互联网安全研究组。这是 ISRG 的顶层 OID。 | +| 1.3.6.1.4.1.44947.1 | 未赋予任何含义。这一遗留的 OID 从未被单独使用过。 | +| 1.3.6.1.4.1.44947.1.1 | 未赋予任何含义。这一遗留的 OID 从未被单独使用过。 | +| 1.3.6.1.4.1.44947.1.1.1 | 经过 ISRG 域名验证。这一遗留的 OID 和 [CA/BF 域名验证证书策略的 OID](https://github.com/cabforum/servercert/blob/main/docs/BR.md#12-document-name-and-identification) 2.23.140.1.2.1 的含义相同，过去曾在我们的[中间证书](/certs/lets-encrypt-e1.txt)中出现，但为了减小证书大小，现已不再使用。 | +| 1.3.6.1.4.1.44947.2 | Let's Encrypt 信任锚点 ID。这是所有“信任锚点”（即 [CA 密钥](/certificates)）的顶层 OID，可用于[信任锚点标识符](https://datatracker.ietf.org/doc/draft-ietf-tls-trust-anchor-ids/)和 [Merkle 树证书](https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/)互联网标准草案中。下级 OID 大致按照对应证书的签发时间分配。 | +| 1.3.6.1.4.1.44947.2.1 | ISRG Root X1 | +| 1.3.6.1.4.1.44947.2.2 | Let's Encrypt Authority X1 | +| 1.3.6.1.4.1.44947.2.3 | Let's Encrypt Authority X2 | +| 1.3.6.1.4.1.44947.2.4 | Let's Encrypt Authority X3 | +| 1.3.6.1.4.1.44947.2.5 | Let's Encrypt Authority X4 | +| 1.3.6.1.4.1.44947.2.6 | ISRG Root X2 | +| 1.3.6.1.4.1.44947.2.7 | Let's Encrypt E1 | +| 1.3.6.1.4.1.44947.2.8 | Let's Encrypt E2 | +| 1.3.6.1.4.1.44947.2.9 | Let's Encrypt R3 | +| 1.3.6.1.4.1.44947.2.10 | Let's Encrypt R4 | +| 1.3.6.1.4.1.44947.2.11 | Let's Encrypt E5 | +| 1.3.6.1.4.1.44947.2.12 | Let's Encrypt E6 | +| 1.3.6.1.4.1.44947.2.13 | Let's Encrypt E7 | +| 1.3.6.1.4.1.44947.2.14 | Let's Encrypt E8 | +| 1.3.6.1.4.1.44947.2.15 | Let's Encrypt E9 | +| 1.3.6.1.4.1.44947.2.16 | Let's Encrypt R10 | +| 1.3.6.1.4.1.44947.2.17 | Let's Encrypt R11 | +| 1.3.6.1.4.1.44947.2.18 | Let's Encrypt R12 | +| 1.3.6.1.4.1.44947.2.19 | Let's Encrypt R13 | +| 1.3.6.1.4.1.44947.2.20 | Let's Encrypt R14 | +| 1.3.6.1.4.1.44947.2.21 | ISRG Root YE | +| 1.3.6.1.4.1.44947.2.22 | ISRG Root YR | +| 1.3.6.1.4.1.44947.2.23 | Let's Encrypt YE1 | +| 1.3.6.1.4.1.44947.2.24 | Let's Encrypt YE2 | +| 1.3.6.1.4.1.44947.2.25 | Let's Encrypt YE3 | +| 1.3.6.1.4.1.44947.2.26 | Let's Encrypt YR1 | +| 1.3.6.1.4.1.44947.2.27 | Let's Encrypt YR2 | +| 1.3.6.1.4.1.44947.2.28 | Let's Encrypt YR3 | diff --git a/content/zh-cn/docs/profiles.md b/content/zh-cn/docs/profiles.md index b89df91802..e85afaac37 100644 --- a/content/zh-cn/docs/profiles.md +++ b/content/zh-cn/docs/profiles.md @@ -1,15 +1,15 @@ --- title: 证书配置 slug: profiles -lastmod: 2026-09-08 +lastmod: 2026-10-04 show_lastmod: false --- -证书的配置包含一系列属性，对证书的验证流程和最终内容都有影响。 大多数 Let's Encrypt 用户无需关注于此，我们会自动为您选择最合适的配置，并确保能够满足互联网公钥加密体系的各项要求和最佳实践。 然而，部分用户可能倾向于主动选择某种特定的配置，故此页面提供了相关信息以供参考。 +证书的配置包含一系列属性，对证书的验证流程和最终内容都有影响。大多数 Let's Encrypt 用户无需关注于此，我们会自动为您选择最合适的配置，并确保能够满足互联网公钥加密体系的各项要求和最佳实践。然而，部分用户可能倾向于主动选择某种特定的配置，故此页面提供了相关信息以供参考。 # 我们提供的配置 -以下是每种配置的详细信息，包括对于验证流程和证书内容的影响。 请注意，并非所有配置都能在任意环境中使用：部分配置可能只支持测试环境或只支持生产环境，也可能（暂时）受白名单限制，我们将逐步对外开放。 实际可用的配置以 ACME 服务器 `directory` 接口响应的信息为准。 +以下是每种配置的详细信息，包括对于验证流程和证书内容的影响。请注意，并非所有配置都能在任意环境中使用：部分配置可能只支持测试环境或只支持生产环境，也可能（暂时）受白名单限制，我们将逐步对外开放。实际可用的配置以 ACME 服务器 `directory` 接口响应的信息为准。 您可以在本页面的末尾查看配置中各类属性的详细含义。 @@ -17,7 +17,7 @@ show_lastmod: false ## classic -所有未明确指定配置的订单都会采用 classic 作为默认配置， 其验证流程和最终的证书内容延续了近年来 Let's Encrypt 一贯的运作方式。 如果您倾向于先让他人体验新的功能，我们推荐使用这种比较保守的配置。 +所有未明确指定配置的订单都会采用 classic 作为默认配置，其验证流程和最终的证书内容延续了近年来 Let's Encrypt 一贯的运作方式。如果您倾向于先让他人体验新的功能，我们推荐使用这种比较保守的配置。 | 属性 | 数据 | | ----------------------- | ---------------------------------------- | @@ -32,7 +32,7 @@ show_lastmod: false | [名称数量上限](#名称数量上限) | 100 | | [标识符类型](#标识符类型) | 域名 | -\*: 如果在证书签发的最后阶段提交的 CSR 中指定了通用名称，并且该名称是主体备用名称中的一个域名，则我们将采纳该名称。 反之，如果 CSR 没有指定通用名称，则我们将把主体备用名称中的第一个域名作为主体通用名称。 通用名称不能超过 64 个字符， 如果长度达到 65 个字符以上，该字段将被留空。 +\*: 如果在证书签发的最后阶段提交的 CSR 中指定了通用名称，并且该名称是主体备用名称中的一个域名，则我们将采纳该名称。反之，如果 CSR 没有指定通用名称，则我们将把主体备用名称中的第一个域名作为主体通用名称。通用名称不能超过 64 个字符，如果长度达到 65 个字符以上，该字段将被留空。 †: 只包含在使用 RSA 公钥的证书中。 @@ -41,11 +41,11 @@ show_lastmod: false ## tlsserver -新推出的 tlsserver 配置在验证流程和证书内容上有所变化，旨在更好地满足 CA/浏览器论坛最新的底线要求，以及 WebPKI 社群的整体发展态势。 我们建议想压缩证书大小或已具备完善的自动化机制的用户选择此配置。 +新推出的 tlsserver 配置在验证流程和证书内容上有所变化，旨在更好地满足 CA/浏览器论坛最新的底线要求，以及 WebPKI 社群的整体发展态势。我们建议想压缩证书大小或已具备完善的自动化机制的用户选择此配置。 -为了进一步鼓励用户实现自动化，域名验证时限相比以往大幅缩短，但自动化完善的系统能够在数秒内完成域名验证，因此一个小时绰绰有余。 验证结果复用时限缩短到了七个小时， 这是因为底线要求规定八小时后我们就必须重新检查证书颁发机构授权 (CAA) 记录，所以缩短复用时限意味着我们可以省去重新检查的步骤。 订单有效期也缩短到了两次域名验证时限的总和，因为验证过期后即使订单有效也没有什么意义。 +为了进一步鼓励用户实现自动化，域名验证时限相比以往大幅缩短，但自动化完善的系统能够在数秒内完成域名验证，因此一个小时绰绰有余。验证结果复用时限缩短到了七个小时，这是因为底线要求规定八小时后我们就必须重新检查证书颁发机构授权 (CAA) 记录，所以缩短复用时限意味着我们可以省去重新检查的步骤。订单有效期也缩短到了两次域名验证时限的总和，因为验证过期后即使订单有效也没有什么意义。 -最终发放的证书将省略通用名称，因为有主体备用名称足矣，底线要求也不推荐使用通用名称。 密钥用途中不再包含“密钥加密”，因为该用途只用于非前向保密的 TLS 加密算法，但由于前向保密的重要性，所有主流浏览器都已不再支持这些算法。 主体密钥标识符扩展将被省略，因为它在最终实体证书中并没有作用，底线要求也不推荐保留。 另外，证书有效期也将缩短至 45 天，以应对将来所有证书有效期都不能超过 47 天的限制。 +最终发放的证书将省略通用名称，因为有主体备用名称足矣，底线要求也不推荐使用通用名称。密钥用途中不再包含“密钥加密”，因为该用途只用于非前向保密的 TLS 加密算法，但由于前向保密的重要性，所有主流浏览器都已不再支持这些算法。主体密钥标识符扩展将被省略，因为它在最终实体证书中并没有作用，底线要求也不推荐保留。另外，证书有效期也将缩短至 45 天，以应对将来所有证书有效期都不能超过 47 天的限制。 | 属性 | 数据 | | ----------------------- | ---- | @@ -65,9 +65,9 @@ show_lastmod: false ## shortlived -shortlived 配置与 tlsserver 相同，只有一个重要的区别：证书有效期只有大约 6 天。 这样的证书符合底线要求中的“短期用户证书”标准，因此无需包含任何吊销信息。 这意味着证书大小可以进一步压缩，并且杜绝了证书吊销后仍受部分客户端信任的可能性。 如下表所示，目前这些证书仍然带有 CRL 网址，但[未来情况可能会有所变化](https://github.com/letsencrypt/boulder/issues/7673)。 +shortlived 配置与 tlsserver 相同，只有一个重要的区别：证书有效期只有大约 6 天。这样的证书符合底线要求中的“短期用户证书”标准，因此无需包含任何吊销信息。这意味着证书大小可以进一步压缩，并且杜绝了证书吊销后仍受部分客户端信任的可能性。如下表所示，目前这些证书仍然带有 CRL 网址，但[未来情况可能会有所变化](https://github.com/letsencrypt/boulder/issues/7673)。 -对于完全信任其自动化机制能够及时为证书续期的用户，我们推荐使用这种配置。 但该配置并不适合所有用户， +对于完全信任其自动化机制能够及时为证书续期的用户，我们推荐使用这种配置。但该配置并不适合所有用户， | 属性 | 数据 | | ----------------------- | --------- | @@ -89,14 +89,13 @@ shortlived 配置与 tlsserver 相同，只有一个重要的区别：证书有 自 2026 年 7 月 8 日起，此配置已不再可用。 -采用 tlsclient 配置颁发的证书带有 TLS 客户端认证 EKU， -除此之外与 classic 配置完全相同。 +采用 tlsclient 配置颁发的证书带有 TLS 客户端认证 EKU，除此之外与 classic 配置完全相同。
# 选择配置 -[这份互联网标准草案](https://datatracker.ietf.org/doc/draft-aaron-acme-profiles/)描述了选择配置的流程，我们计划与 IETF 的 ACME 工作组共同将该草案进一步转变为完整的 RFC 标准。 并非所有 ACME 客户端都已实现该草案，所以您使用的客户端可能尚不支持选择配置。 +[这份互联网标准草案](https://datatracker.ietf.org/doc/draft-aaron-acme-profiles/)描述了选择配置的流程，我们计划与 IETF 的 ACME 工作组共同将该草案进一步转变为完整的 RFC 标准。并非所有 ACME 客户端都已实现该草案，所以您使用的客户端可能尚不支持选择配置。 一般而言，如果您需要选择配置，应当： @@ -112,15 +111,15 @@ shortlived 配置与 tlsserver 相同，只有一个重要的区别：证书有 ### 域名验证时限 -即 ACME 客户端必须在多长的时间内完成对域名所有权的证明， 从 ACME 协议中 Authorization 对象创建时（通常也是 Order 对象生成时）开始计算，在接口中由处于 pending 状态的 Authorization 对象的 [`expires` 时间戳](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4)表示。 底线要求规定这一时限[不得超过 30 天](https://github.com/cabforum/servercert/blob/main/docs/BR.md#322419-agreed-upon-change-to-website---acme)。 +即 ACME 客户端必须在多长的时间内完成对域名所有权的证明，从 ACME 协议中 Authorization 对象创建时（通常也是 Order 对象生成时）开始计算，在接口中由处于 pending 状态的 Authorization 对象的 [`expires` 时间戳](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4)表示。底线要求规定这一时限[不得超过 30 天](https://github.com/cabforum/servercert/blob/main/docs/BR.md#322419-agreed-upon-change-to-website---acme)。 ### 验证结果复用时限 -即在多长的时间内对相同域名或 IP 地址的新申请无需重复验证， 从上一次验证通过开始计算，在接口中由处于 valid 状态的 Authorization 对象的 [`expires` 时间戳](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4)表示。 [底线要求](https://github.com/cabforum/servercert/blob/main/docs/BR.md#421-performing-identification-and-authentication-functions)规定这一时限不得超过 200 天，且对于 2027 年 3 月 15 日起签发的证书而言不得超过 100 天，2029 年 3 月 15 日起还将进一步缩短至 10 天。 +即在多长的时间内对相同域名或 IP 地址的新申请无需重复验证，从上一次验证通过开始计算，在接口中由处于 valid 状态的 Authorization 对象的 [`expires` 时间戳](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4)表示。[底线要求](https://github.com/cabforum/servercert/blob/main/docs/BR.md#421-performing-identification-and-authentication-functions)规定这一时限不得超过 200 天，且对于 2027 年 3 月 15 日起签发的证书而言不得超过 100 天，2029 年 3 月 15 日起还将进一步缩短至 10 天。 ### 订单有效期 -即 ACME 客户端需要在多长的时间内完成证书申请的全流程，包括提交订单、完成验证并确认签发。 订单的有效期从 ACME 协议中 Order 对象创建开始计算，并由该对象的 [`expires` 时间戳](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.3)表示。 +即 ACME 客户端需要在多长的时间内完成证书申请的全流程，包括提交订单、完成验证并确认签发。订单的有效期从 ACME 协议中 Order 对象创建开始计算，并由该对象的 [`expires` 时间戳](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.3)表示。 ## 证书内容属性 @@ -128,23 +127,23 @@ shortlived 配置与 tlsserver 相同，只有一个重要的区别：证书有 ### 证书通用名称 -TLS 证书中有两个字段包含所谓的名称（域名和 IP 地址都属于名称）：[主体通用名称](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6)和[主体备用名称](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6)。 以往域名大多都记录在通用名称中，许多证书解析工具显示的也都是这一名称， 但通用名称只能有一个，而许多证书需要包含多个名称（如 `example.com`、`www.example.com` 和 `blog.example.com`）。 如今通用名称已颇为多余，因为该名称的内容仍需包含在主体备用名称中。 [底线要求现已不再推荐](https://github.com/cabforum/servercert/blob/main/docs/BR.md#71272-domain-validated)在证书中填写通用名称。 +TLS 证书中有两个字段包含所谓的名称（域名和 IP 地址都属于名称）：[主体通用名称](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6)和[主体备用名称](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6)。以往域名大多都记录在通用名称中，许多证书解析工具显示的也都是这一名称，但通用名称只能有一个，而许多证书需要包含多个名称（如 `example.com`、`www.example.com` 和 `blog.example.com`）。如今通用名称已颇为多余，因为该名称的内容仍需包含在主体备用名称中。[底线要求现已不再推荐](https://github.com/cabforum/servercert/blob/main/docs/BR.md#71272-domain-validated)在证书中填写通用名称。 ### 密钥的加密用途 -TLS 证书包含一个[“密钥用途”字段](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)，表示该证书的密钥允许执行哪些密码学操作。 Let's Encrypt 签发的所有证书都包含“数字签名”用途，这是进行 TLS 握手所必需的。 “密钥加密”这一用途则在旧版本的 TLS 协议中用于某些基于 RSA 密钥的握手机制， 并且这些机制已被证明并不安全，各大浏览器早在数年前就已停止支持。 [底线要求也已经不再推荐](https://github.com/cabforum/servercert/blob/main/docs/BR.md#712711-subscriber-certificate-key-usage)在证书中允许“密钥加密”这一用途。 +TLS 证书包含一个[“密钥用途”字段](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)，表示该证书的密钥允许执行哪些密码学操作。 Let's Encrypt 签发的所有证书都包含“数字签名”用途，这是进行 TLS 握手所必需的。“密钥加密”这一用途则在旧版本的 TLS 协议中用于某些基于 RSA 密钥的握手机制，并且这些机制已被证明并不安全，各大浏览器早在数年前就已停止支持。[底线要求也已经不再推荐](https://github.com/cabforum/servercert/blob/main/docs/BR.md#712711-subscriber-certificate-key-usage)在证书中允许“密钥加密”这一用途。 ### 主体密钥标识符扩展字段 -TLS 证书可以包含一个[“主体密钥标识符”字段](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2)，以一个简短的字符串来代表该证书的密钥。 这对于 CA 证书而言至关重要，因为浏览器需要借助这一字段快速判断网站的最终实体证书是由哪一份 CA 证书签发的。 但在最终实体证书中这一字段并没有实际作用，底线要求也不推荐将其加入证书中。 +TLS 证书可以包含一个[“主体密钥标识符”字段](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2)，以一个简短的字符串来代表该证书的密钥。这对于 CA 证书而言至关重要，因为浏览器需要借助这一字段快速判断网站的最终实体证书是由哪一份 CA 证书签发的。但在最终实体证书中这一字段并没有实际作用，底线要求也不推荐将其加入证书中。 ### 有效期 -有效期决定了 TLS 证书中 [`notBefore` 和 `notAfter` 时间戳](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5)之间的间隔，也就是该证书在多长的时间内能够被信任。 [底线要求](https://github.com/cabforum/servercert/blob/main/docs/BR.md#632-certificate-operational-periods-and-key-pair-usage-periods)规定有效期不得超过 200 天，且 2027 年 3 月 15 日起签发的证书不得超过 100 天，2029 年 3 月 15 日起还将进一步缩短至 47 天。 +有效期决定了 TLS 证书中 [`notBefore` 和 `notAfter` 时间戳](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5)之间的间隔，也就是该证书在多长的时间内能够被信任。[底线要求](https://github.com/cabforum/servercert/blob/main/docs/BR.md#632-certificate-operational-periods-and-key-pair-usage-periods)规定有效期不得超过 200 天，且 2027 年 3 月 15 日起签发的证书不得超过 100 天，2029 年 3 月 15 日起还将进一步缩短至 47 天。 ### 吊销信息来源 -TLS 客户端需要通过某种方式查询证书是否已被提前吊销。 一般而言，在互联网公钥加密体系中有三种方式可以选择：在线证书状态协议 (OCSP)、证书吊销列表 (CRL)，以及采用极短的有效期来规避吊销证书的必要性。 Let's Encrypt 现已不再支持 OCSP。 此字段仅表明相应配置下生成的证书是否包含 CRL 网址。 +TLS 客户端需要通过某种方式查询证书是否已被提前吊销。一般而言，在互联网公钥加密体系中有三种方式可以选择：在线证书状态协议 (OCSP)、证书吊销列表 (CRL)，以及采用极短的有效期来规避吊销证书的必要性。 Let's Encrypt 现已不再支持 OCSP。此字段仅表明相应配置下生成的证书是否包含 CRL 网址。 ### 名称数量上限 diff --git a/content/zh-cn/docs/rate-limits.md b/content/zh-cn/docs/rate-limits.md index d58678a0fb..9a368d556a 100644 --- a/content/zh-cn/docs/rate-limits.md +++ b/content/zh-cn/docs/rate-limits.md @@ -5,25 +5,25 @@ lastmod: 2026-08-05 show_lastmod: true --- -为保证尽可能多的人可以公平使用我们的服务，Let's Encrypt 采取了速率限制措施。 我们相信这一限制足以满足大多数人的正常需求。 此外，我们的设计使得证书续期几乎不可能触发速率限制，即使是大型机构也可以逐步增加证书数量，无需 Let's Encrypt 干预。 +为保证尽可能多的人可以公平使用我们的服务，Let's Encrypt 采取了速率限制措施。我们相信这一限制足以满足大多数人的正常需求。此外，我们的设计使得证书续期几乎不可能触发速率限制，即使是大型机构也可以逐步增加证书数量，无需 Let's Encrypt 干预。 -如果您正在开发或测试一款 Let’s Encrypt 客户端，请使用我们的[测试环境](/docs/staging-environment)，而不要使用生产环境的接口。 如果您准备将 Let’s Encrypt 作为证书提供商或用于大型网站中，请查阅我们的[集成指南](/docs/integration-guide)。 +如果您正在开发或测试一款 Let’s Encrypt 客户端，请使用我们的[测试环境](/docs/staging-environment)，而不要使用生产环境的接口。如果您准备将 Let’s Encrypt 作为证书提供商或用于大型网站中，请查阅我们的[集成指南](/docs/integration-guide)。 # 速率限制的方式 -我们采用[令牌桶算法](https://en.wikipedia.org/wiki/Token_bucket)限制请求速率， 因此您可以自由选择调用策略， 既可以在不超过数量上限的前提下一次性发起大量请求，也可以分批次完成接口调用以避免触发速率限制。 +我们采用[令牌桶算法](https://en.wikipedia.org/wiki/Token_bucket)限制请求速率，因此您可以自由选择调用策略，既可以在不超过数量上限的前提下一次性发起大量请求，也可以分批次完成接口调用以避免触发速率限制。 -如果您不慎触发了速率限制，我们无法临时为您解除。 但不必担心，您的请求额度将随时间逐渐恢复，无需任何操作就能继续发起新的请求。 吊销现有证书**并不能**解除速率限制，因为我们签发证书所消耗的资源已经无法回收。 请参阅下文[触发速率限制后如何重试](#触发速率限制后如何重试)了解详情。 +如果您不慎触发了速率限制，我们无法临时为您解除。但不必担心，您的请求额度将随时间逐渐恢复，无需任何操作就能继续发起新的请求。吊销现有证书**并不能**解除速率限制，因为我们签发证书所消耗的资源已经无法回收。请参阅下文[触发速率限制后如何重试](#触发速率限制后如何重试)了解详情。 # 账户注册限制 -以下是我们对于 `new-account` 接口所设置的速率限制。 此类限制极少被触发， 我们建议大型集成商采取[多个客户对应一个账户](/docs/integration-guide)的设计。 +以下是我们对于 `new-account` 接口所设置的速率限制。此类限制极少被触发，我们建议大型集成商采取[多个客户对应一个账户](/docs/integration-guide)的设计。
## 单个 IP 地址注册限制 -每个 IP 地址每 3 个小时最多可注册 10 个账户。 注册额度的恢复速率为每 18 分钟可再创建 1 个账户。 +每个 IP 地址每 3 个小时最多可注册 10 个账户。注册额度的恢复速率为每 18 分钟可再创建 1 个账户。 ### 豁免 @@ -34,8 +34,7 @@ show_lastmod: true ## 单个 IPv6 子网注册限制 -每个 /48 的 IPv6 子网每 3 个小时最多可注册 500 个账户。 -注册额度的恢复速率为每 22 秒可再创建 1 个账户。 +每个 /48 的 IPv6 子网每 3 个小时最多可注册 500 个账户。注册额度的恢复速率为每 22 秒可再创建 1 个账户。 ### 豁免 @@ -45,18 +44,17 @@ show_lastmod: true # 证书签发限制 -以下是我们对于 `new-order` 接口所设置的速率限制。 触发此类限制较为常见，尤其是在大型托管服务商及需要为大量域名申请证书的机构中。 +以下是我们对于 `new-order` 接口所设置的速率限制。触发此类限制较为常见，尤其是在大型托管服务商及需要为大量域名申请证书的机构中。
## 单个账户证书申请限制 -每次请求 Let’s Encrypt 签发一份证书即视为一次申请。 -每份证书最多可包含 100 个标识符（域名或 IP 地址），具体取决于所选的[证书配置](/docs/profiles/)。 但出于性能考虑，一份证书中的标识符越少越好。 +每次请求 Let’s Encrypt 签发一份证书即视为一次申请。每份证书最多可包含 100 个标识符（域名或 IP 地址），具体取决于所选的[证书配置](/docs/profiles/)。但出于性能考虑，一份证书中的标识符越少越好。 ### 限制 -每个账户每 3 个小时最多可申请 300 份证书。 申请额度的恢复速率为每 36 秒可再申请一份证书。 +每个账户每 3 个小时最多可申请 300 份证书。申请额度的恢复速率为每 36 秒可再申请一份证书。 ### 豁免 @@ -67,16 +65,15 @@ show_lastmod: true ## 单个注册域名证书申请限制 -一般而言，注册域名即您向域名注册商购买的那一部分域名。 例如，`www.example.com` 对应的注册域名为 `example.com`， 而 `new.blog.example.co.uk` 对应的注册域名则为 `example.co.uk`。 我们依据[公共后缀列表](https://publicsuffix.org/)来确定注册域名。 +一般而言，注册域名即您向域名注册商购买的那一部分域名。例如，`www.example.com` 对应的注册域名为 `example.com`，而 `new.blog.example.co.uk` 对应的注册域名则为 `example.co.uk`。我们依据[公共后缀列表](https://publicsuffix.org/)来确定注册域名。 -对于 IP 地址证书，我们将最常见的分配粒度（即您从运营商或托管服务商一次性获得的 IP 地址数量）视作注册域名。 对于 IPv4 地址，每个地址等同于一个注册域名； 而对于 IPv6 地址，每个 /64 子网等同于一个注册域名。 +对于 IP 地址证书，我们将最常见的分配粒度（即您从运营商或托管服务商一次性获得的 IP 地址数量）视作注册域名。对于 IPv4 地址，每个地址等同于一个注册域名；而对于 IPv6 地址，每个 /64 子网等同于一个注册域名。 您还可以在 [crt.sh](https://crt.sh/) 或 [Censys](https://search.censys.io/#) 中通过[证书透明化](https://www.certificate-transparency.org/)日志搜索您注册的域名已经获得了哪些证书。 ### 限制 -每个注册域名（或 IPv4 地址，或 IPv6 的 /64 子网）每 7 天最多可申请 50 份证书。 这一限制全局有效，即使是其他账户申请的证书也计算在内。 -申请额度的恢复速率为每 202 分钟可再申请一份证书。 +每个注册域名（或 IPv4 地址，或 IPv6 的 /64 子网）每 7 天最多可申请 50 份证书。这一限制全局有效，即使是其他账户申请的证书也计算在内。申请额度的恢复速率为每 202 分钟可再申请一份证书。 ### 豁免 @@ -87,21 +84,21 @@ show_lastmod: true ## 相同标识符集合证书申请限制 -假设您申请了一份对 `192.168.1.1`、`example.com` 和 `login.example.com` 都有效的证书，则该证书的「标识符集合」为 `[192.168.1.1, example.com, login.example.com]`。 倘若您申请的证书只对 `example.co.uk` 有效，那么标识符集合就是 `[example.co.uk]`。 +假设您申请了一份对 `192.168.1.1`、`example.com` 和 `login.example.com` 都有效的证书，则该证书的「标识符集合」为 `[192.168.1.1, example.com, login.example.com]`。倘若您申请的证书只对 `example.co.uk` 有效，那么标识符集合就是 `[example.co.uk]`。 ### 限制 -同一标识符集合每 7 天最多可申请 5 份证书。 这一限制全局有效，即使是其他账户申请的证书也计算在内。 申请额度的恢复速率为每 34 小时可再申请一份证书。 +同一标识符集合每 7 天最多可申请 5 份证书。这一限制全局有效，即使是其他账户申请的证书也计算在内。申请额度的恢复速率为每 34 小时可再申请一份证书。 ### 常见原因 -反复重装客户端程序来排查问题或者频繁删除 ACME 客户端配置信息都是触发此限制的常见原因。 为此我们有意将此限制设定得较为严苛，以防故障的系统或不完善的软件将其他速率限制的额度迅速耗尽。 +反复重装客户端程序来排查问题或者频繁删除 ACME 客户端配置信息都是触发此限制的常见原因。为此我们有意将此限制设定得较为严苛，以防故障的系统或不完善的软件将其他速率限制的额度迅速耗尽。 测试或调试应用程序时建议使用[测试环境](/docs/staging-environment)，其速率限制会[宽松很多](/docs/staging-environment/#速率限制)。 ### 解决方法 -触发此限制后可以通过添加额外的标识符（如 `blog.example.com`）继续申请证书， 但需要注意此类证书不会被视为对已有证书的续期， 因此将受到[单个账户证书申请限制](#单个账户证书申请限制)和[单个注册域名证书申请限制](#单个注册域名证书申请限制)的约束。 +触发此限制后可以通过添加额外的标识符（如 `blog.example.com`）继续申请证书，但需要注意此类证书不会被视为对已有证书的续期，因此将受到[单个账户证书申请限制](#单个账户证书申请限制)和[单个注册域名证书申请限制](#单个注册域名证书申请限制)的约束。 ### 豁免 @@ -112,19 +109,19 @@ show_lastmod: true ## 单个账户同一标识符验证失败次数限制 -证书申请中每个标识符（域名或 IP 地址）的有效性都需要验证， 所有验证均通过后证书才能签发。 验证失败意味着 Let’s Encrypt 成功发出了验证请求，但未得到任何能证明标识符归属的信息。 +证书申请中每个标识符（域名或 IP 地址）的有效性都需要验证，所有验证均通过后证书才能签发。验证失败意味着 Let’s Encrypt 成功发出了验证请求，但未得到任何能证明标识符归属的信息。 ### 限制 -每个账户下每个标识符每小时最多可验证失败 5 次。 验证额度的恢复速率为每个标识符每 12 分钟可再验证一次。 触发这一限制后，该账户就无法再为此标识符申请任何证书，直到限制解除。 +每个账户下每个标识符每小时最多可验证失败 5 次。验证额度的恢复速率为每个标识符每 12 分钟可再验证一次。触发这一限制后，该账户就无法再为此标识符申请任何证书，直到限制解除。 ### 常见原因 -排查问题前建议先将客户端配置改为使用[测试环境](/docs/staging-environment)， 其速率限制会[宽松很多](/docs/staging-environment/#速率限制)，可以避免定位及解决问题的过程中消耗生产环境的请求额度。 +排查问题前建议先将客户端配置改为使用[测试环境](/docs/staging-environment)，其速率限制会[宽松很多](/docs/staging-environment/#速率限制)，可以避免定位及解决问题的过程中消耗生产环境的请求额度。 - `HTTP-01` 和 `TLS-ALPN-01` 验证失败的原因通常是网络或防火墙配置导致 Let's Encrypt 无法与您的服务器建立连接。 -- `DNS-01` 验证失败则一般是由于配置过程中遗漏了步骤或输入的内容有误。 这种验证方式往往需要您先在主 DNS 域中创建 CNAME 记录，以便客户端在验证过程中进一步设置其他 DNS 记录。 +- `DNS-01` 验证失败则一般是由于配置过程中遗漏了步骤或输入的内容有误。这种验证方式往往需要您先在主 DNS 域中创建 CNAME 记录，以便客户端在验证过程中进一步设置其他 DNS 记录。 ### 豁免 @@ -135,11 +132,11 @@ show_lastmod: true ## 单个账户同一标识符连续验证失败次数限制 -与[单个账户同一标识符验证失败次数限制](#单个账户同一标识符验证失败次数限制)类似，但只针对连续验证失败的情况。 此限制旨在防止客户端陷入验证失败的无限循环中。 +与[单个账户同一标识符验证失败次数限制](#单个账户同一标识符验证失败次数限制)类似，但只针对连续验证失败的情况。此限制旨在防止客户端陷入验证失败的无限循环中。 ### 限制 -每个账户下每个标识符最多可连续验证失败 1152 次。 验证额度的恢复速率为每天可再验证一次，验证成功后限制随即解除。 超过限制后，该账户就无法再为此标识符申请证书。 这种情况下，用户可以通过接口报错信息中的链接前往我们的自助服务页面手动恢复验证，并且可以额外为账户关联的最多 49999 个标识符同时解除限制。 +每个账户下每个标识符最多可连续验证失败 1152 次。验证额度的恢复速率为每天可再验证一次，验证成功后限制随即解除。超过限制后，该账户就无法再为此标识符申请证书。这种情况下，用户可以通过接口报错信息中的链接前往我们的自助服务页面手动恢复验证，并且可以额外为账户关联的最多 49999 个标识符同时解除限制。 | 每日失败次数 | 触发限制所需的时间 | | ------ | ------------------------------ | @@ -155,11 +152,11 @@ show_lastmod: true ### 常见原因 -排查问题前建议先将客户端配置改为使用[测试环境](/docs/staging-environment)， 其速率限制会[宽松很多](/docs/staging-environment/#速率限制)，可以避免定位及解决问题的过程中消耗生产环境的请求额度。 +排查问题前建议先将客户端配置改为使用[测试环境](/docs/staging-environment)，其速率限制会[宽松很多](/docs/staging-environment/#速率限制)，可以避免定位及解决问题的过程中消耗生产环境的请求额度。 - `HTTP-01` 和 `TLS-ALPN-01` 验证失败的原因通常是网络或防火墙配置导致 Let's Encrypt 无法与您的服务器建立连接。 -- `DNS-01` 验证失败则一般是由于配置过程中遗漏了步骤或输入的内容有误。 这种验证方式往往需要您先在主 DNS 域中创建 CNAME 记录，以便客户端在验证过程中进一步设置其他 DNS 记录。 +- `DNS-01` 验证失败则一般是由于配置过程中遗漏了步骤或输入的内容有误。这种验证方式往往需要您先在主 DNS 域中创建 CNAME 记录，以便客户端在验证过程中进一步设置其他 DNS 记录。 ### 豁免 @@ -169,7 +166,7 @@ show_lastmod: true # 整体请求频率限制 -除了[账户注册](#账户注册限制)和[证书签发](#证书签发限制)的限制，每个 IP 地址对各接口的调用频率也有上限。 此类限制由我们的负载均衡器实现，旨在避免 ACME 接口因部分客户端的频繁调用而超负荷运转。 +除了[账户注册](#账户注册限制)和[证书签发](#证书签发限制)的限制，每个 IP 地址对各接口的调用频率也有上限。此类限制由我们的负载均衡器实现，旨在避免 ACME 接口因部分客户端的频繁调用而超负荷运转。 | 接口 | 单 IP 每秒请求上限 | 突发容量 | | ------------------ | ----------- | ---- | @@ -181,7 +178,7 @@ show_lastmod: true | /acme/\* | 250 | 125 | | /directory | 40 | 40 | -超过以上限制的请求将收到代码为 `503 Service Unavailable` 的 HTTP 响应， 响应中包含 `Retry-After` 标头。 +超过以上限制的请求将收到代码为 `503 Service Unavailable` 的 HTTP 响应，响应中包含 `Retry-After` 标头。 # 证书续期的例外条件 @@ -189,23 +186,22 @@ Let's Encrypt 有两种方式认定证书申请是否属于续期：推荐的方 ## ARI 续期 -通过 ARI 完成续期的特有优势就是不受任何速率限制约束。 支持 ARI 的客户端会定期向 Let's Encrypt 确认您现有的证书是否需要续期， 达到续期的最佳时间窗口后就会自动申请新证书，并指明其替代的是哪一份旧证书。 只要新证书中至少有一个标识符与旧证书相同，且旧证书尚未通过 ARI 续期，此次申请就不受任何速率限制。 +通过 ARI 完成续期的特有优势就是不受任何速率限制约束。支持 ARI 的客户端会定期向 Let's Encrypt 确认您现有的证书是否需要续期，达到续期的最佳时间窗口后就会自动申请新证书，并指明其替代的是哪一份旧证书。只要新证书中至少有一个标识符与旧证书相同，且旧证书尚未通过 ARI 续期，此次申请就不受任何速率限制。 ## 非 ARI 续期 -如果您的客户端或托管服务商尚未支持 ARI，但您申请的新证书标识符集合与某一现有证书完全相同（不考虑大小写和顺序），那么此次申请也可以被视为续期。 例如，假设您为 `[192.168.1.1, www.example.com, example.com]` 申请了一份证书，那么您还可以再为 `[192.168.1.1, www.example.com, example.com]` 一次性申请四份证书，直到触发[相同标识符集合证书申请限制](#相同标识符集合证书申请限制)。 这四份新证书的申请都将被视为续期，不受[单个账户证书申请限制](#单个账户证书申请限制)和[单个注册域名证书申请限制](#单个注册域名证书申请限制)。 -但与 ARI 续期不同，此类申请仍将受到[单个账户同一标识符验证失败次数限制](#单个账户同一标识符验证失败次数限制)和[相同标识符集合证书申请限制](#相同标识符集合证书申请限制)的约束。 +如果您的客户端或托管服务商尚未支持 ARI，但您申请的新证书标识符集合与某一现有证书完全相同（不考虑大小写和顺序），那么此次申请也可以被视为续期。例如，假设您为 `[192.168.1.1, www.example.com, example.com]` 申请了一份证书，那么您还可以再为 `[192.168.1.1, www.example.com, example.com]` 一次性申请四份证书，直到触发[相同标识符集合证书申请限制](#相同标识符集合证书申请限制)。这四份新证书的申请都将被视为续期，不受[单个账户证书申请限制](#单个账户证书申请限制)和[单个注册域名证书申请限制](#单个注册域名证书申请限制)。但与 ARI 续期不同，此类申请仍将受到[单个账户同一标识符验证失败次数限制](#单个账户同一标识符验证失败次数限制)和[相同标识符集合证书申请限制](#相同标识符集合证书申请限制)的约束。 # 触发速率限制后如何重试 -触发速率限制后的错误提示信息均遵循相同的格式， 例如： +触发速率限制后的错误提示信息均遵循相同的格式，例如： ``` too many new registrations (10) from this IP address in the last 3h0m0s, retry after 1970-01-01 00:18:15 UTC. ``` -在给定的日期和时间之后即可再次执行相同的操作。 如果您的请求超过了不止一项速率限制，提示信息将始终显示最后解除的限制项。 +在给定的日期和时间之后即可再次执行相同的操作。如果您的请求超过了不止一项速率限制，提示信息将始终显示最后解除的限制项。 ## Retry-After 标头 @@ -213,4 +209,4 @@ retry after 1970-01-01 00:18:15 UTC. # 申请豁免 -如果您是需要集成 Let's Encrypt 的大型托管服务提供商或机构，可以通过[速率限制表单](https://isrg.formstack.com/forms/rate_limit_adjustment_request)申请放宽限制。 处理申请需要数周的时间，因此填写此表单并不能为您提前解除已经触发的速率限制。 +如果您是需要集成 Let's Encrypt 的大型托管服务提供商或机构，可以通过[速率限制表单](https://isrg.formstack.com/forms/rate_limit_adjustment_request)申请放宽限制。处理申请需要数周的时间，因此填写此表单并不能为您提前解除已经触发的速率限制。 diff --git a/content/zh-cn/docs/revoking.md b/content/zh-cn/docs/revoking.md index 27945938d9..7b6ccce8e1 100644 --- a/content/zh-cn/docs/revoking.md +++ b/content/zh-cn/docs/revoking.md @@ -6,11 +6,11 @@ show_lastmod: 1 --- -当证书不再安全使用时，您应该吊销它。 该情况可能由很多原因造成。 例如， 您可能意外的在某些公共网站上上传了您的私钥信息；黑客可能进入了您的服务器并复制了私钥；黑客可能暂时获取了您的服务器或 DNS 配置的控制权，并验证、颁发了他们控制私钥的证书。 +当证书不再安全使用时，您应该吊销它。该情况可能由很多原因造成。例如， 您可能意外的在某些公共网站上上传了您的私钥信息；黑客可能进入了您的服务器并复制了私钥；黑客可能暂时获取了您的服务器或 DNS 配置的控制权，并验证、颁发了他们控制私钥的证书。 -当您吊销 Let's Encrypt 证书后，Let's Encrypt 就可以通过[证书吊销列表](https://en.wikipedia.org/wiki/Certificate_revocation_list) (CRL) 发布吊销信息，部分浏览器会根据 CRL 决定是否信任该证书。 如果私钥泄露，吊销其相应的证书不仅对于安全而言至关重要，同时也是 Let's Encrypt [用户协议](/repository)所规定的义务。 +当您吊销 Let's Encrypt 证书后，Let's Encrypt 就可以通过[证书吊销列表](https://en.wikipedia.org/wiki/Certificate_revocation_list) (CRL) 发布吊销信息，部分浏览器会根据 CRL 决定是否信任该证书。如果私钥泄露，吊销其相应的证书不仅对于安全而言至关重要，同时也是 Let's Encrypt [用户协议](/repository)所规定的义务。 -若您要吊销 Let's Encrypt 颁发的证书，您需要通过 [Certbot](https://certbot.eff.org/) 之类的 ACME 客户端使用 [ACME API](https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md) 进行操作。 您需要向 Let's Encrypt 证明您有权吊销证书。 有三种方法可以验证所有权：使用签发证书的原帐户，使用另一个授权签发的帐户，或使用证书私钥。 +若您要吊销 Let's Encrypt 颁发的证书，您需要通过 [Certbot](https://certbot.eff.org/) 之类的 ACME 客户端使用 [ACME API](https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md) 进行操作。您需要向 Let's Encrypt 证明您有权吊销证书。有三种方法可以验证所有权：使用签发证书的原帐户，使用另一个授权签发的帐户，或使用证书私钥。 # 指定吊销原因代码 @@ -31,7 +31,7 @@ show_lastmod: 1 # 用颁发证书的账户吊销证书 -如果最初是您自己颁发了证书，并且您仍然控制用于颁发该证书的帐户，则可以使用您的帐户凭据吊销该证书。 Certbot 将默认尝试使用该方法吊销证书。 例如： +如果最初是您自己颁发了证书，并且您仍然控制用于颁发该证书的帐户，则可以使用您的帐户凭据吊销该证书。 Certbot 将默认尝试使用该方法吊销证书。例如： ```bash certbot revoke --cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem @@ -39,17 +39,17 @@ certbot revoke --cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem # 使用其他授权帐户吊销证书 -如果有人入侵了您的主机或 DNS 后颁发了证书，那么您一旦重新获得控制权，就会想要吊销该证书。 要吊销证书，Let's Encrypt 将需要确保您控制该证书中的域名（否则人们可以在未经许可的情况下吊销彼此的证书）！ +如果有人入侵了您的主机或 DNS 后颁发了证书，那么您一旦重新获得控制权，就会想要吊销该证书。要吊销证书，Let's Encrypt 将需要确保您控制该证书中的域名（否则人们可以在未经许可的情况下吊销彼此的证书）！ -为了验证您对该域名的控制权，您需要使用和您申请 Let's Encrypt 证书时相同的流程：您可以[添加一条 DNS TXT 记录](https://tools.ietf.org/html/rfc8555#section-8.4)或在[HTTP 服务器上放置指定文件](https://tools.ietf.org/html/rfc8555#section-8.3)。 通常情况下，ACME 客户端将为您处理这些工作。 然而，大多数 ACME 客户端将验证控制权和颁发证书这两个操作捆绑在一起，因此若要验证控制权您必须尝试颁发新证书。 若您不需要颁发的新证书，您可以将其吊销或删除证书私钥。 +为了验证您对该域名的控制权，您需要使用和您申请 Let's Encrypt 证书时相同的流程：您可以[添加一条 DNS TXT 记录](https://tools.ietf.org/html/rfc8555#section-8.4)或在[HTTP 服务器上放置指定文件](https://tools.ietf.org/html/rfc8555#section-8.3)。通常情况下，ACME 客户端将为您处理这些工作。然而，大多数 ACME 客户端将验证控制权和颁发证书这两个操作捆绑在一起，因此若要验证控制权您必须尝试颁发新证书。若您不需要颁发的新证书，您可以将其吊销或删除证书私钥。 -若您完全不想颁发一张新的证书，您可以尝试在请求中添加一个不存在的域名，这将导致证书颁发失败，但是仍旧能够证明您对需要吊销的域名的控制权。 例如： +若您完全不想颁发一张新的证书，您可以尝试在请求中添加一个不存在的域名，这将导致证书颁发失败，但是仍旧能够证明您对需要吊销的域名的控制权。例如： ```bash certbot certonly --manual --preferred-challenges=dns -d ${YOUR_DOMAIN} -d nonexistent.${YOUR_DOMAIN} ``` -然后根据提示正常完成操作，但不要验证 `nonexistent.${YOUR_DOMAIN}` 域名。 若您想要使用 HTTP 文件（而不是 DNS）来进行验证，请将 `--preferred-challenges=dns` 替换为 `--preferred-challenges=http`。 需要注意的是，在通过 DNS 进行验证的情况下，如果您没有使用 `--manual` 选项，而是使用某些 Certbot 插件自动完成 DNS-01 验证，那么 Certbot 很有可能直接为 `_acme-challenge.nonexistent.${YOUR_DOMAIN}` 设置一条 TXT 记录，从而导致这种操作方法失效。 +然后根据提示正常完成操作，但不要验证 `nonexistent.${YOUR_DOMAIN}` 域名。若您想要使用 HTTP 文件（而不是 DNS）来进行验证，请将 `--preferred-challenges=dns` 替换为 `--preferred-challenges=http`。需要注意的是，在通过 DNS 进行验证的情况下，如果您没有使用 `--manual` 选项，而是使用某些 Certbot 插件自动完成 DNS-01 验证，那么 Certbot 很有可能直接为 `_acme-challenge.nonexistent.${YOUR_DOMAIN}` 设置一条 TXT 记录，从而导致这种操作方法失效。 一旦您验证了要吊销的证书中所有域名的控制权，您就可以从 [crt.sh](https://crt.sh/) 中下载证书，然后和您自己颁发了证书的情况一样，使用如下命令吊销证书： @@ -59,11 +59,11 @@ certbot revoke --cert-path /PATH/TO/downloaded-cert.pem # 使用证书私钥吊销证书 -如果最初不是您颁发了证书，但是您拥有相应私钥的副本，则您可以使用该私钥对吊销请求进行签名。 例如，如果您发现有私钥被意外公开，即使您不是最初颁发使用该私钥的证书的人，您也可以使用此方法吊销这些证书。 +如果最初不是您颁发了证书，但是您拥有相应私钥的副本，则您可以使用该私钥对吊销请求进行签名。例如，如果您发现有私钥被意外公开，即使您不是最初颁发使用该私钥的证书的人，您也可以使用此方法吊销这些证书。 若要使用此方法，您将首先需要以PEM格式复制私钥。 -然后，如果您还没做，请下载要吊销的证书。 Let's Encrypt 颁发的所有证书都会录入[证书透明化](https://www.certificate-transparency.org/)日志，所以您可以在 [crt.sh](https://crt.sh/) 等日志监视系统中查找并下载证书。 搜索匹配 `SubjectPublicKeyInfo` (SPKI) 字段将找到使用私钥的所有证书。 从私钥中提取SPKI哈希值： +然后，如果您还没做，请下载要吊销的证书。 Let's Encrypt 颁发的所有证书都会录入[证书透明化](https://www.certificate-transparency.org/)日志，所以您可以在 [crt.sh](https://crt.sh/) 等日志监视系统中查找并下载证书。搜索匹配 `SubjectPublicKeyInfo` (SPKI) 字段将找到使用私钥的所有证书。从私钥中提取SPKI哈希值： ```bash openssl pkey -outform DER -in /PATH/TO/privkey.pem -pubout | openssl sha256 ``` diff --git a/content/zh-cn/docs/staging-environment.md b/content/zh-cn/docs/staging-environment.md index 4c2af4f5e0..dd0dd93db6 100644 --- a/content/zh-cn/docs/staging-environment.md +++ b/content/zh-cn/docs/staging-environment.md @@ -6,13 +6,13 @@ show_lastmod: 1 --- -在使用我们的正式环境以前，我们强烈建议您使用我们的测试环境进行测试性部署， 这将允许您在颁发受信任的证书前确保一切正常，并且降低您受到速率限制的可能性。 +在使用我们的正式环境以前，我们强烈建议您使用我们的测试环境进行测试性部署，这将允许您在颁发受信任的证书前确保一切正常，并且降低您受到速率限制的可能性。 我们的 [ACME v2 测试环境](https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605)的网址为： `https://acme-staging-v02.api.letsencrypt.org/directory` -如果您使用的是 [Certbot](https://certbot.eff.org/)，可以通过 `--test-cert` 或 `--dry-run` 命令行选项使用我们的测试环境。 如果您使用的是其他 ACME 客户端，请阅读他们有关使用我们的测试环境进行测试的说明。 +如果您使用的是 [Certbot](https://certbot.eff.org/)，可以通过 `--test-cert` 或 `--dry-run` 命令行选项使用我们的测试环境。如果您使用的是其他 ACME 客户端，请阅读他们有关使用我们的测试环境进行测试的说明。 注意：不同环境的 ACME 账户也是独立的，因此使用测试环境需要另外注册账户。 Certbot 会自动为您处理这一问题。 @@ -42,13 +42,13 @@ show_lastmod: 1 # 测试证书层次结构 -测试环境的证书结构[与生产环境相似](/certificates)。 但测试证书的名称开头有 (STAGING) 字样，且命名方式也与生产环境中的证书截然不同，以示区分。 +测试环境的证书结构[与生产环境相似](/certificates)。但测试证书的名称开头有 (STAGING) 字样，且命名方式也与生产环境中的证书截然不同，以示区分。 ## 根证书颁发机构 测试环境目前启用了四份根证书：“(STAGING) Pretend Pear X1”、“(STAGING) Bogus Broccoli X2”、“(STAGING) Yearning Yucca Root YE”和“(STAGING) Yonder Yam Root YR”。这些根证书**没有收录**至各类浏览器和客户端的证书库中。 -如果您想在仅用作测试的客户端软件中信任测试环境的证书，可以将证书加入该客户端的证书库中。 **重要提示**：请勿将测试环境的根证书或中间证书加入您日常使用的证书库中，因为这些证书没有经过审计，安全标准也不及生产环境的根证书，用于测试以外的任何目的都是不安全的。 +如果您想在仅用作测试的客户端软件中信任测试环境的证书，可以将证书加入该客户端的证书库中。**重要提示**：请勿将测试环境的根证书或中间证书加入您日常使用的证书库中，因为这些证书没有经过审计，安全标准也不及生产环境的根证书，用于测试以外的任何目的都是不安全的。 * **Pretend Pear X1** * 证书主体：`O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1` @@ -76,7 +76,7 @@ show_lastmod: 1 ## 中间证书颁发机构 -测试环境的中间证书与生产环境类似，但由上述的不可信根证书签发。 和生产环境一样，并非所有中间证书都会同时投入使用。 以下是现存的所有中间证书： +测试环境的中间证书与生产环境类似，但由上述的不可信根证书签发。和生产环境一样，并非所有中间证书都会同时投入使用。以下是现存的所有中间证书： * (STAGING) Pseudo Plum E5 * (STAGING) False Fennel E6 @@ -95,11 +95,11 @@ show_lastmod: 1 * (STAGING) Ersatz Emmer YR2 * (STAGING) Fake Farro YR3 -这些中间证书随时可能变更，任何系统都不应加以固定或信任。 一般而言，您可以认为测试环境的中间证书与生产环境中可信的中间证书一一对应。 如果确有必要，您还可以在[此处](https://github.com/letsencrypt/website/blob/main/static/certs/staging)获取详尽的证书信息。 +这些中间证书随时可能变更，任何系统都不应加以固定或信任。一般而言，您可以认为测试环境的中间证书与生产环境中可信的中间证书一一对应。如果确有必要，您还可以在[此处](https://github.com/letsencrypt/website/blob/main/static/certs/staging)获取详尽的证书信息。 # 证书透明化 -测试环境也有专门用于测试的证书透明化日志系统， 为测试环境签发的证书提供 SCT。 但由于该环境仅供测试，通过证书透明化系统追踪证书的签发流程并不可靠。 +测试环境也有专门用于测试的证书透明化日志系统，为测试环境签发的证书提供 SCT。但由于该环境仅供测试，通过证书透明化系统追踪证书的签发流程并不可靠。 测试环境中的日志系统既包括 Let's Encrypt 自身运作的[测试日志](/docs/ct-logs#testing)，也包括其他团体运作的用于测试目的的证书透明化日志。 @@ -107,6 +107,6 @@ show_lastmod: 1 # 持续集成/开发测试 -测试环境的速率限制较为宽松，但并不适合用于软件开发或持续集成 (CI)。 向外部服务器发出网络请求可能会导致网络不稳定，并且测试环境无法“伪造” DNS或强制其他验证成功通过，这会使测试设置更加复杂。 +测试环境的速率限制较为宽松，但并不适合用于软件开发或持续集成 (CI)。向外部服务器发出网络请求可能会导致网络不稳定，并且测试环境无法“伪造” DNS或强制其他验证成功通过，这会使测试设置更加复杂。 -除了测试环境外，Let's Encrypt还提供了一个专用于CI和开发环境的小型ACME服务器，称为[Pebble](https://github.com/letsencrypt/pebble)。 您可以[快速而简单的](https://github.com/letsencrypt/pebble#docker)在开发机器或CI环境中运行Pebble。 +除了测试环境外，Let's Encrypt还提供了一个专用于CI和开发环境的小型ACME服务器，称为[Pebble](https://github.com/letsencrypt/pebble)。您可以[快速而简单的](https://github.com/letsencrypt/pebble#docker)在开发机器或CI环境中运行Pebble。 diff --git a/content/zh-cn/docs/why-all-https.md b/content/zh-cn/docs/why-all-https.md index 3b1ced915b..4a67820d65 100644 --- a/content/zh-cn/docs/why-all-https.md +++ b/content/zh-cn/docs/why-all-https.md @@ -5,20 +5,20 @@ lastmod: 2025-08-03 show_lastmod: 1 --- -过去有些网站运营者声称他们的网站没有任何敏感信息，因此也就没有保密的需求。 然而，这种论调并不有力。我们认为所有网站都应当使用 HTTPS，原因有以下几点： +过去有些网站运营者声称他们的网站没有任何敏感信息，因此也就没有保密的需求。然而，这种论调并不有力。我们认为所有网站都应当使用 HTTPS，原因有以下几点： ## HTTP 明文在传输过程中可能被窃听 -未经加密的流量在传输过程中可能被第三方窃取。 也就是说，网络链路上的任何组织或个人都能窥探用户通过网络上传和下载的所有数据，包括各种敏感数据。 这显然是严重的隐私问题，就像寄信不用信封一样。 +未经加密的流量在传输过程中可能被第三方窃取。也就是说，网络链路上的任何组织或个人都能窥探用户通过网络上传和下载的所有数据，包括各种敏感数据。这显然是严重的隐私问题，就像寄信不用信封一样。 -即使网站运营者认为他们的网站没有敏感信息，这种判断也有可能出错。 或许他们的网站确实_不该_传输敏感信息，但这不代表实际真的没有。 而 HTTPS 一定程度上能防止这种误判演变成隐私泄露。 +即使网站运营者认为他们的网站没有敏感信息，这种判断也有可能出错。或许他们的网站确实_不该_传输敏感信息，但这不代表实际真的没有。而 HTTPS 一定程度上能防止这种误判演变成隐私泄露。 -另一方面，网站运营者也不可能控制所有的出入流量：他们无法杜绝用户在网络请求中意外_发送_某些敏感信息，如果网页表单或客户端软件配置不当就有可能出现这种情况。 要指望他们永远不出错实在是强人所难。 +另一方面，网站运营者也不可能控制所有的出入流量：他们无法杜绝用户在网络请求中意外_发送_某些敏感信息，如果网页表单或客户端软件配置不当就有可能出现这种情况。要指望他们永远不出错实在是强人所难。 再者，光是浏览某网站这一行为本身就可能属于敏感信息，尤其是对于生活在威权统治下的人而言。 HTTPS 有一种名为[加密服务器名称指示 (ECH)](https://zh.wikipedia.org/wiki/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA#%E5%8A%A0%E5%AF%86%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87%E7%A4%BA) 的扩展能够隐藏这一信息，但使用明文 HTTP 的网站也无法开启这层额外的安全防护。 ## HTTP 明文在传输过程中可能被篡改 -更为严重的是，未经加密的流量在传输途中还可能被第三方篡改。 也就是说，没有人能确定自己收到的数据是否就是对方发送的，自己发送的数据被对方收到时也可能面目全非。 这样的通信既没有隐私，又不_可靠_。 +更为严重的是，未经加密的流量在传输途中还可能被第三方篡改。也就是说，没有人能确定自己收到的数据是否就是对方发送的，自己发送的数据被对方收到时也可能面目全非。这样的通信既没有隐私，又不_可靠_。 -最为常见的就是服务器响应被注入广告和/或恶意软件。 无论一个网站本身的内容是什么，只要不开启 HTTPS，就等于将访客置于这种风险之中。 +最为常见的就是服务器响应被注入广告和/或恶意软件。无论一个网站本身的内容是什么，只要不开启 HTTPS，就等于将访客置于这种风险之中。 diff --git a/content/zh-cn/getinvolved.md b/content/zh-cn/getinvolved.md index bad4cf68f7..ac2b62189a 100644 --- a/content/zh-cn/getinvolved.md +++ b/content/zh-cn/getinvolved.md @@ -11,7 +11,7 @@ show_lastmod: 1 ## 社区支持 -您可以帮助我们在[Let’s Encrypt 社区论坛](https://community.letsencrypt.org/)中回答问题。 参见[此博客文章](/2015/08/13/lets-encrypt-community-support.html)以了解社区支持为何如此重要。 +您可以帮助我们在[Let’s Encrypt 社区论坛](https://community.letsencrypt.org/)中回答问题。参见[此博客文章](/2015/08/13/lets-encrypt-community-support.html)以了解社区支持为何如此重要。 ## ACME 客户端软件 @@ -23,4 +23,4 @@ show_lastmod: 1 ## 服务器端证书签发软件 -我们的服务器端证书签发软件 [Boulder](https://github.com/letsencrypt/boulder) 是开源的， 该软件基于 [ACME](https://tools.ietf.org/html/rfc8555) 协议，主要使用 Go 语言编写。 [标注为“help wanted”的 issue 列表](https://github.com/letsencrypt/boulder/labels/help%20wanted)和[贡献者指南](https://github.com/letsencrypt/boulder/blob/main/docs/CONTRIBUTING.md)都是一个很好的起点。 +我们的服务器端证书签发软件 [Boulder](https://github.com/letsencrypt/boulder) 是开源的，该软件基于 [ACME](https://tools.ietf.org/html/rfc8555) 协议，主要使用 Go 语言编写。[标注为“help wanted”的 issue 列表](https://github.com/letsencrypt/boulder/labels/help%20wanted)和[贡献者指南](https://github.com/letsencrypt/boulder/blob/main/docs/CONTRIBUTING.md)都是一个很好的起点。 diff --git a/content/zh-cn/getting-started.md b/content/zh-cn/getting-started.md index b51d2df3f6..f80dfc8d42 100644 --- a/content/zh-cn/getting-started.md +++ b/content/zh-cn/getting-started.md @@ -6,21 +6,21 @@ lastmod: 2025-01-23 Let's Encrypt 通过 [ACME 协议](https://zh.wikipedia.org/zh-cn/%E8%87%AA%E5%8B%95%E6%86%91%E8%AD%89%E6%9B%B4%E6%96%B0%E7%92%B0%E5%A2%83)接口自动签发数字证书。 -调用 Let's Encrypt 接口获取证书需要使用一种名为“ACME 客户端”的软件， 而本网站仅提供相关信息，获取证书的过程中没有任何一个环节需要在网页上操作。 +调用 Let's Encrypt 接口获取证书需要使用一种名为“ACME 客户端”的软件，而本网站仅提供相关信息，获取证书的过程中没有任何一个环节需要在网页上操作。 使用 Let's Encrypt 前首先要考虑的问题是：网站托管服务商能否代为获取并管理证书？还是需要您自行部署 ACME 客户端？ # 通过托管服务商获取证书 -不少网站托管服务商都能替用户完成 Let's Encrypt 证书的获取与管理， 这种情况下 ACME 客户端由托管服务商运作，您不必关心如何获取及使用该软件。 +不少网站托管服务商都能替用户完成 Let's Encrypt 证书的获取与管理，这种情况下 ACME 客户端由托管服务商运作，您不必关心如何获取及使用该软件。 -如果您的服务商支持代为获取并管理证书，该功能可能会自动开启，也可能需要您手动配置。 请查阅服务商的文档和配置选项。 +如果您的服务商支持代为获取并管理证书，该功能可能会自动开启，也可能需要您手动配置。请查阅服务商的文档和配置选项。 # 自行挑选并运行 ACME 客户端 如果托管服务商不能为您获取并管理证书，但您能够在服务器上以足够的权限执行命令，那么您可以自行选取一款 ACME 客户端在服务器上运行，从而通过 Let's Encrypt 获取证书。 -对于大多数用户，我们推荐使用的 ACME 客户端是 [Certbot](https://certbot.eff.org/)， 其网站提供了优质的文档和操作说明。 +对于大多数用户，我们推荐使用的 ACME 客户端是 [Certbot](https://certbot.eff.org/)，其网站提供了优质的文档和操作说明。 如果 Certbot 由于某些原因无法满足您的需求，还有[很多 ACME 客户端](/docs/client-options/)可以选择。 diff --git a/content/zh-cn/how-it-works.md b/content/zh-cn/how-it-works.md index cb74bfac54..07651f5ed6 100644 --- a/content/zh-cn/how-it-works.md +++ b/content/zh-cn/how-it-works.md @@ -6,17 +6,17 @@ lastmod: 2025-08-02 show_lastmod: 1 --- -Let's Encrypt 和 [ACME 协议](https://tools.ietf.org/html/rfc8555)的目标是实现可信数字证书的自动获取，从而简化 HTTPS 服务器部署中的人工操作。 这一过程是由网页服务器上的 ACME 客户端完成的。 +Let's Encrypt 和 [ACME 协议](https://tools.ietf.org/html/rfc8555)的目标是实现可信数字证书的自动获取，从而简化 HTTPS 服务器部署中的人工操作。这一过程是由网页服务器上的 ACME 客户端完成的。 为了理解该技术的工作原理，让我们来了解一下使用 ACME 客户端为 `https://example.com/` 申请证书的流程。 -该流程分为两步。 首先 ACME 客户端需要向[证书颁发机构](https://zh.wikipedia.org/zh-cn/%E8%AF%81%E4%B9%A6%E9%A2%81%E5%8F%91%E6%9C%BA%E6%9E%84) (CA) 证明该服务器拥有域名的控制权， 然后客户端就可以为此域名申请或吊销证书了。 +该流程分为两步。首先 ACME 客户端需要向[证书颁发机构](https://zh.wikipedia.org/zh-cn/%E8%AF%81%E4%B9%A6%E9%A2%81%E5%8F%91%E6%9C%BA%E6%9E%84) (CA) 证明该服务器拥有域名的控制权，然后客户端就可以为此域名申请或吊销证书了。 ## 域名认证 -Let's Encrypt 通过[公钥](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86)识别不同的 ACME 客户端。 ACME 客户端首次与 Let's Encrypt 交互时会生成一对密钥，并向 Let's Encrypt 证明其用户对若干域名具有控制权。 这与创建账户并添加域名的传统证书颁发流程类似。 +Let's Encrypt 通过[公钥](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86)识别不同的 ACME 客户端。 ACME 客户端首次与 Let's Encrypt 交互时会生成一对密钥，并向 Let's Encrypt 证明其用户对若干域名具有控制权。这与创建账户并添加域名的传统证书颁发流程类似。 -首先，客户端会询问 Let's Encrypt CA 如何才能证明其对 `example.com` 的控制权。 Let's Encrypt CA 会根据申请的域名提供一种或多种验证方式， 客户端可以任选其一。 例如，CA 可能会让客户端选择： +首先，客户端会询问 Let's Encrypt CA 如何才能证明其对 `example.com` 的控制权。 Let's Encrypt CA 会根据申请的域名提供一种或多种验证方式，客户端可以任选其一。例如，CA 可能会让客户端选择： * 在 `example.com` 下配置 DNS 记录，或者 * 在 `http://example.com/` 下的指定网址放置一项 HTTP 资源 @@ -26,7 +26,7 @@ Let's Encrypt 通过[公钥](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E5%BC%80%E src="/images/howitworks_challenge.png"/>
-客户端需要选择一种验证方式完成验证。 假设它选择了第二种方式，在 `http://example.com` 的指定路径创建了一份文件， 完成这一步骤后，客户端就会通知 CA 准备就绪。 +客户端需要选择一种验证方式完成验证。假设它选择了第二种方式，在 `http://example.com` 的指定路径创建了一份文件，完成这一步骤后，客户端就会通知 CA 准备就绪。 接下来 CA 需要从[多个网络位置](/2020/02/19/multi-perspective-validation)进行核验。 @@ -37,7 +37,7 @@ Let's Encrypt 通过[公钥](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E5%BC%80%E 如果验证顺利通过，那么该公钥对应的客户端就有权管理 `example.com` 的数字证书。 -需要注意的是，这一过程不能通过 HTTPS 进行，否则会存在安全风险。 因此，Let's Encrypt 实际上会从多个网络位置同时进行验证， 从而有效防御验证过程中可能遭到的攻击。 +需要注意的是，这一过程不能通过 HTTPS 进行，否则会存在安全风险。因此，Let's Encrypt 实际上会从多个网络位置同时进行验证，从而有效防御验证过程中可能遭到的攻击。 ## 证书颁发和吊销 @@ -45,9 +45,9 @@ Let's Encrypt 通过[公钥](https://zh.wikipedia.org/zh-cn/%E5%85%AC%E5%BC%80%E ### 证书申请 -为了获得该域名的证书，客户端首先创建一份 PKCS#10 [证书签名请求](https://tools.ietf.org/html/rfc2986) (CSR)，向 Let's Encrypt CA 申请为 `example.com` 颁发一份使用指定公钥的证书。 CSR 本身已经由其私钥进行了一次签名， 而客户端还会用 `example.com` 的授权密钥对整个 CSR 再进行一次签名，以便 Let's Encrypt CA 验证其来源。 +为了获得该域名的证书，客户端首先创建一份 PKCS#10 [证书签名请求](https://tools.ietf.org/html/rfc2986) (CSR)，向 Let's Encrypt CA 申请为 `example.com` 颁发一份使用指定公钥的证书。 CSR 本身已经由其私钥进行了一次签名，而客户端还会用 `example.com` 的授权密钥对整个 CSR 再进行一次签名，以便 Let's Encrypt CA 验证其来源。 -Let's Encrypt CA 收到请求后对这两份签名进行验证， 如果全部通过，就为 CSR 中的公钥颁发 `example.com` 的证书，并将证书文件发给客户端。 CA 还会将证书上传至各类公开的证书透明化 (CT) 日志系统中， 详情可以在[此处](https://certificate.transparency.dev/howctworks/#pki)了解。 +Let's Encrypt CA 收到请求后对这两份签名进行验证，如果全部通过，就为 CSR 中的公钥颁发 `example.com` 的证书，并将证书文件发给客户端。 CA 还会将证书上传至各类公开的证书透明化 (CT) 日志系统中，详情可以在[此处](https://certificate.transparency.dev/howctworks/#pki)了解。
为 example.com 申请证书 申请吊销 example.com 的证书

感谢您的捐款

谨代表互联网安全研究组 (ISRG) 的所有成员，我们在此衷心感谢您对本项目的认可与支持。

-

一封包含捐款收据的邮件已发送至您先前提供的邮箱。 互联网安全研究组 (ISRG) 是一家 501(c)(3) 非营利公益组织。 我们的 EIN 是：46-3344200。

+

一封包含捐款收据的邮件已发送至您先前提供的邮箱。互联网安全研究组 (ISRG) 是一家 501(c)(3) 非营利公益组织。我们的 EIN 是：46-3344200。

多多益善

-

有些单位会有“员工捐多少，单位捐多少”的政策。 您可留意贵司是否有类似的政策，并让您的影响力加倍！

+

有些单位会有“员工捐多少，单位捐多少”的政策。您可留意贵司是否有类似的政策，并让您的影响力加倍！

{{< double_donation >}}
diff --git a/content/zh-cn/trademarks.md b/content/zh-cn/trademarks.md index 4cce6d9066..941a90be81 100644 --- a/content/zh-cn/trademarks.md +++ b/content/zh-cn/trademarks.md @@ -6,4 +6,4 @@ english_is_canonical: 1 show_lastmod: 1 --- -我们的商标政策已移至另一页面， 请查阅：[https://www.abetterinternet.org/trademarks](https://www.abetterinternet.org/trademarks) +我们的商标政策已移至另一页面，请查阅：[https://www.abetterinternet.org/trademarks](https://www.abetterinternet.org/trademarks) diff --git a/content/zh-cn/upcoming-features.md b/content/zh-cn/upcoming-features.md index 2600286c2d..61bc0a6b2b 100644 --- a/content/zh-cn/upcoming-features.md +++ b/content/zh-cn/upcoming-features.md @@ -11,13 +11,13 @@ show_lastmod: 1 ## 证书有效期缩短至 45 天 -为迎合 CA/浏览器论坛新的底线要求，我们计划逐步[将证书有效期缩短至 45 天](https://letsencrypt.org/2025/12/02/from-90-to-45)： 首先于 2027 年 2 月 10 日缩短至 64 天，再于 2028 年 2 月 16 日缩短至 45 天。 域名验证结果复用时限也将首先缩短至 10 天，再进一步缩短至七个小时。 +为迎合 CA/浏览器论坛新的底线要求，我们计划逐步[将证书有效期缩短至 45 天](https://letsencrypt.org/2025/12/02/from-90-to-45)：首先于 2027 年 2 月 10 日缩短至 64 天，再于 2028 年 2 月 16 日缩短至 45 天。域名验证结果复用时限也将首先缩短至 10 天，再进一步缩短至七个小时。 # 已实现的功能 ## 移除“TLS 客户端身份验证”扩展密钥用途 -自 2026 年 2 月 11 日起，我们的默认证书配置中[不再包含“TLS 客户端身份验证”扩展密钥用途 (EKU)](https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/)。 2026 年 7 月 8 日，我们已将临时的 [tlsclient](https://letsencrypt.org/docs/profiles/#tlsclient) 证书配置下线，从而彻底废除这一密钥用途。 今后我们签发的所有证书都不再包含 TLS 客户端身份验证 EKU。 +自 2026 年 2 月 11 日起，我们的默认证书配置中[不再包含“TLS 客户端身份验证”扩展密钥用途 (EKU)](https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/)。 2026 年 7 月 8 日，我们已将临时的 [tlsclient](https://letsencrypt.org/docs/profiles/#tlsclient) 证书配置下线，从而彻底废除这一密钥用途。今后我们签发的所有证书都不再包含 TLS 客户端身份验证 EKU。 ## 停止发送临期证书提醒邮件 @@ -27,7 +27,7 @@ show_lastmod: 1 上线日期：[2025 年 5 月 7 日](https://letsencrypt.org/2024/12/05/ending-ocsp/)。 -我们签发的证书已不再包含颁发机构信息访问 (AIA) 在线证书状态协议 (OCSP) 网址， 而是提供证书吊销列表 (CRL) 发布点 (CRLDP) 网址。 证书使用者可以通过 CRL 获取证书吊销状态信息，ACME 客户端则可以通过 ARI（见下）获取证书续期建议。 +我们签发的证书已不再包含颁发机构信息访问 (AIA) 在线证书状态协议 (OCSP) 网址，而是提供证书吊销列表 (CRL) 发布点 (CRLDP) 网址。证书使用者可以通过 CRL 获取证书吊销状态信息，ACME 客户端则可以通过 ARI（见下）获取证书续期建议。 ## ACME 证书配置 @@ -39,7 +39,7 @@ show_lastmod: 1 上线日期：[2024 年 3 月 14 日](https://letsencrypt.org/2024/03/14/introducing-sunlight/)。 -我们运作的证书透明化 (CT) 日志现已遵循新的[静态证书透明化接口规范](https://c2sp.org/static-ct-api)，由 [Sunlight](https://github.com/FiloSottile/sunlight) 软件提供服务。 目前新日志系统已全面上线，以满足浏览器对 CT 的要求。 [CT 日志文档](https://letsencrypt.org/docs/ct-logs/)中记载了我们当前所有的日志系统。 +我们运作的证书透明化 (CT) 日志现已遵循新的[静态证书透明化接口规范](https://c2sp.org/static-ct-api)，由 [Sunlight](https://github.com/FiloSottile/sunlight) 软件提供服务。目前新日志系统已全面上线，以满足浏览器对 CT 的要求。 [CT 日志文档](https://letsencrypt.org/docs/ct-logs/)中记载了我们当前所有的日志系统。 ## ACME更新信息 (ARI) @@ -49,8 +49,8 @@ show_lastmod: 1 ## 短期证书 -用户可以通过更改 ACME 配置[申请“短期”证书](https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued/)。 此类证书的有效期极短，因此不需要包含任何吊销相关的信息。 +用户可以通过更改 ACME 配置[申请“短期”证书](https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued/)。此类证书的有效期极短，因此不需要包含任何吊销相关的信息。 ## IP 地址证书 -申请短期证书（见上）时可以在主体备用名称中[包含 IP 地址](https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued/)。 其[验证方式](https://www.rfc-editor.org/rfc/rfc8738.html)与当下 DNS 域名的验证方式大体相同。 +申请短期证书（见上）时可以在主体备用名称中[包含 IP 地址](https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued/)。其[验证方式](https://www.rfc-editor.org/rfc/rfc8738.html)与当下 DNS 域名的验证方式大体相同。 diff --git a/content/zh-tw/about.md b/content/zh-tw/about.md index 63cef2d013..31f97e548b 100644 --- a/content/zh-tw/about.md +++ b/content/zh-tw/about.md @@ -9,9 +9,9 @@ menu: parent: about --- -Let's Encrypt 是一個免費、自動化、開放，為了公眾利益而運作的憑證頒發機構 (Certificate Authority, CA)。 它是由 [Internet Security Research Group (ISRG)](https://www.abetterinternet.org/)所提供的服務。 +Let's Encrypt 是一個免費、自動化、開放，為了公眾利益而運作的憑證頒發機構 (Certificate Authority, CA)。它是由 [Internet Security Research Group (ISRG)](https://www.abetterinternet.org/)所提供的服務。 -為了建立一個更加安全；更尊重隱私的網際網路，我們免費提供用戶數位憑證，並以最友善的方式替網站啟用 HTTPS (SSL/TLS)。 這麼做是因為我們想要建立一個更安全、更尊重隱私的網路環境。 +為了建立一個更加安全；更尊重隱私的網際網路，我們免費提供用戶數位憑證，並以最友善的方式替網站啟用 HTTPS (SSL/TLS)。這麼做是因為我們想要建立一個更安全、更尊重隱私的網路環境。 您可以下載我們的[年度報告](https://www.abetterinternet.org/annual-reports/)，了解我們最新一年的回顧。 diff --git a/content/zh-tw/docs/account-id.md b/content/zh-tw/docs/account-id.md index 6810b30d1f..308288bb47 100644 --- a/content/zh-tw/docs/account-id.md +++ b/content/zh-tw/docs/account-id.md @@ -6,10 +6,10 @@ show_lastmod: 1 --- -當你向 Let's Encrypt 回報問題時，如果你提供 Let's Encrypt 帳號 ID，這會對我們非常有幫助。 在大多數的情況下，ACME 客戶端會在與 Let's Encrypt 伺服器溝通的過程中，自動建立帳號。如果你在多個伺服器上運行 ACME 客戶端，你可能會有多個帳號。 +當你向 Let's Encrypt 回報問題時，如果你提供 Let's Encrypt 帳號 ID，這會對我們非常有幫助。在大多數的情況下，ACME 客戶端會在與 Let's Encrypt 伺服器溝通的過程中，自動建立帳號。如果你在多個伺服器上運行 ACME 客戶端，你可能會有多個帳號。 你的帳戶ID是 `https://acme-v02.api.letsencrypt.org/acme/acct/12345678` 格式的網址。 如果您有使用 [Certbot](https://certbot.eff.org/) 1.23.0 或更新的版本，您可以透過執行 `certbot show_account` 取得您的帳號 ID 如果您的版本低於 1.23.0 ，您可以在 `/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/regr.json`. 這個檔案的「uri」欄位中找到您的帳號 ID -如果你使用其他的 ACME 客戶端，請參考客戶端軟體的設定說明， 並在記錄檔中檢查上述提到的網址。 如果你的 ACME 客戶端沒有紀錄帳號 ID，你可以使用相同金鑰傳送一個申請帳號的請求，以取得你的帳號。 細節請參考[ACME 協定中申請帳號的部分](https://tools.ietf.org/html/rfc8555#section-7.3)。 你也可以在每個 ACME 客戶端向伺服器發出 POST 請求，伺服器回應 header 中 Boulder-Requester 的欄位找到數字格式的帳號 ID。 +如果你使用其他的 ACME 客戶端，請參考客戶端軟體的設定說明，並在記錄檔中檢查上述提到的網址。如果你的 ACME 客戶端沒有紀錄帳號 ID，你可以使用相同金鑰傳送一個申請帳號的請求，以取得你的帳號。細節請參考[ACME 協定中申請帳號的部分](https://tools.ietf.org/html/rfc8555#section-7.3)。你也可以在每個 ACME 客戶端向伺服器發出 POST 請求，伺服器回應 header 中 Boulder-Requester 的欄位找到數字格式的帳號 ID。 diff --git a/content/zh-tw/docs/allow-port-80.md b/content/zh-tw/docs/allow-port-80.md index c6c0bb08e3..23b3abfc2f 100644 --- a/content/zh-tw/docs/allow-port-80.md +++ b/content/zh-tw/docs/allow-port-80.md @@ -6,12 +6,12 @@ show_lastmod: 1 --- -我們有時會收到用戶使用 HTTP-01 遇到問題的報告，而問題原因是他們的防火牆阻擋了通訊埠 80。 我們建議所有的網頁伺服器應該同時在通訊埠 80 提供 HTTP 服務；以及在通訊埠 443 提供 HTTPS 服務。 此外也應該將所有發送到通訊埠 80 的請求，重新導向到通訊埠 443，並加上 HTTP 強制安全傳輸技術 (HTTP Strict Transport Security, HSTS)。 +我們有時會收到用戶使用 HTTP-01 遇到問題的報告，而問題原因是他們的防火牆阻擋了通訊埠 80。我們建議所有的網頁伺服器應該同時在通訊埠 80 提供 HTTP 服務；以及在通訊埠 443 提供 HTTPS 服務。此外也應該將所有發送到通訊埠 80 的請求，重新導向到通訊埠 443，並加上 HTTP 強制安全傳輸技術 (HTTP Strict Transport Security, HSTS)。 開啟通訊埠 80 並不會導致伺服器更容易受到攻擊，因為通常通訊埠 80 和通訊埠 443 背後的軟體服務都是同一個。 -將通訊埠 80 關閉並不會降低使用者意外地使用 HTTP 訪問網站的風險。 在正常情況下，使用者會收到重新導向至 HTTPS 的請求，並保護接下來的通訊。 如果使用者正受到中間人攻擊 (MITM)，攻擊者就可以在通訊埠 80 上代替伺服器回應請求，而你的網站無法對使用者回應"拒絕連線"。 +將通訊埠 80 關閉並不會降低使用者意外地使用 HTTP 訪問網站的風險。在正常情況下，使用者會收到重新導向至 HTTPS 的請求，並保護接下來的通訊。如果使用者正受到中間人攻擊 (MITM)，攻擊者就可以在通訊埠 80 上代替伺服器回應請求，而你的網站無法對使用者回應"拒絕連線"。 -最後，保持通訊埠 80 開啟並提供重新導向，有助於使用者透過正確的 HTTPS 版本訪問你的網站。 有非常多你無法掌握的因素，會讓使用者透過 HTTP 訪問你的網站，例如：電子郵件中的自動連結，或是使用者手動輸入網域名稱。 網站最好替使用者重新導向到 HTTPS 版本，而不是告訴使用者拒絕連線。 +最後，保持通訊埠 80 開啟並提供重新導向，有助於使用者透過正確的 HTTPS 版本訪問你的網站。有非常多你無法掌握的因素，會讓使用者透過 HTTP 訪問你的網站，例如：電子郵件中的自動連結，或是使用者手動輸入網域名稱。網站最好替使用者重新導向到 HTTPS 版本，而不是告訴使用者拒絕連線。 -不幸的是，有時候你有可能無法控制通訊埠 80 的開啟或關閉。 有些（大部分住戶區）的網路業者會因為各種原因禁止他人對通訊埠 80 的連線。 如果你的網路業者禁止你使用通訊埠 80，而你還是想取得憑證的話，你有兩個選擇：使用 DNS-01，或在通訊埠 443 上使用[支援 TLS-ALPN-01 驗證的客戶端](https://community.letsencrypt.org/t/which-client-support-tls-alpn-challenge/75859/2)。 +不幸的是，有時候你有可能無法控制通訊埠 80 的開啟或關閉。有些（大部分住戶區）的網路業者會因為各種原因禁止他人對通訊埠 80 的連線。如果你的網路業者禁止你使用通訊埠 80，而你還是想取得憑證的話，你有兩個選擇：使用 DNS-01，或在通訊埠 443 上使用[支援 TLS-ALPN-01 驗證的客戶端](https://community.letsencrypt.org/t/which-client-support-tls-alpn-challenge/75859/2)。 diff --git a/content/zh-tw/docs/lencr-org.md b/content/zh-tw/docs/lencr-org.md index dd9d839e0a..74d43d3b95 100644 --- a/content/zh-tw/docs/lencr-org.md +++ b/content/zh-tw/docs/lencr-org.md @@ -8,27 +8,27 @@ show_lastmod: 1 # `lencr.org` 是什麼？ -`lencr.org` 是 Let's Encrypt 旗下的一個域名。 我們用它來存放憑證中所引用的資料。 +`lencr.org` 是 Let's Encrypt 旗下的一個域名。我們用它來存放憑證中所引用的資料。 -# 我的電腦為什麼會從這個網站獲取資料？ 這是惡意的嗎？ +# 我的電腦為什麼會從這個網站獲取資料？這是惡意的嗎？ -不，`lencr.org` 網站上的資料絕非惡意。 裝置會連線到 `lencr.org`，是因為該裝置上的用戶端（例如瀏覽器或應用程式）先前連線到另一個網站，發現了 Let's Encrypt 憑證，正在驗證其有效性。 這是許多用戶端的正常流程。 +不，`lencr.org` 網站上的資料絕非惡意。裝置會連線到 `lencr.org`，是因為該裝置上的用戶端（例如瀏覽器或應用程式）先前連線到另一個網站，發現了 Let's Encrypt 憑證，正在驗證其有效性。這是許多用戶端的正常流程。 -我們無法斷言上述*另一個網站*是否存在風險。 如果您正在調查異常的網路活動，或許應該關注與 `lencr.org` 緊鄰的前一條連線。 +我們無法斷言上述*另一個網站*是否存在風險。如果您正在調查異常的網路活動，或許應該關注與 `lencr.org` 緊鄰的前一條連線。 -客戶端與 `lencr.org` 之間的連線模式可能較為反常，沒有規律可循。 有些用戶端從來不會從該網站獲取資料，有些則只下載部分資料，或者為提高效率而快取部分資料，因此只會偶爾（首次需要時以及資料可能已過期後）建立連線。 +客戶端與 `lencr.org` 之間的連線模式可能較為反常，沒有規律可循。有些用戶端從來不會從該網站獲取資料，有些則只下載部分資料，或者為提高效率而快取部分資料，因此只會偶爾（首次需要時以及資料可能已過期後）建立連線。 # 這些資料的用途是什麼？ -當用戶端軟體（例如瀏覽器或應用程式）連線到一個網站，而該網站出示憑證時，用戶端需要驗證這份憑證的真實性與有效性。 以下資料可以從各方面幫助用戶端達成此目的。 +當用戶端軟體（例如瀏覽器或應用程式）連線到一個網站，而該網站出示憑證時，用戶端需要驗證這份憑證的真實性與有效性。以下資料可以從各方面幫助用戶端達成此目的。 * `c.lencr.org` 提供了憑證撤銷清單 (CRL)，列出我們所頒發、尚未過期但已撤銷的所有憑證。 -* `i.lencr.org` 提供了我們的"簽發者"中繼憑證副本，這些證書由我們的根憑證簽署，或由其他憑證頒發機構 (CA)"交叉簽署"。 用戶端可以利用此資料來確認"信任鏈"，從它正在驗證的終端實體證書，經由一個或多個中繼憑證，追溯到它所認可並信任的根 CA 憑證。 +* `i.lencr.org` 提供了我們的"簽發者"中繼憑證副本，這些證書由我們的根憑證簽署，或由其他憑證頒發機構 (CA)"交叉簽署"。用戶端可以利用此資料來確認"信任鏈"，從它正在驗證的終端實體證書，經由一個或多個中繼憑證，追溯到它所認可並信任的根 CA 憑證。 # 為什麼用 "`lencr.org`"？ -我們過去曾使用較長的網址，例如 `http://example.int-x3.letsencrypt.org/`。 然而，在我們頒發[新的根憑證和中繼憑證][1]時，我們希望盡可能縮減它們的大小。 網際網路上每一次 HTTPS 連線（每天數十億次）都必須傳送一份憑證副本，因此每個位元組都至關重要。 我們選擇了 `lencr.org`，因為它與我們的名稱相似：**L**et's **ENCR**ypt。 其發音很像虛構的地區 [Lancre][]，在 Terry Pratchett 的_《碟形世界》_小說裡。 +我們過去曾使用較長的網址，例如 `http://example.int-x3.letsencrypt.org/`。然而，在我們頒發[新的根憑證和中繼憑證][1]時，我們希望盡可能縮減它們的大小。網際網路上每一次 HTTPS 連線（每天數十億次）都必須傳送一份憑證副本，因此每個位元組都至關重要。我們選擇了 `lencr.org`，因為它與我們的名稱相似：**L**et's **ENCR**ypt。其發音很像虛構的地區 [Lancre][]，在 Terry Pratchett 的_《碟形世界》_小說裡。 [1]: https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html [Lancre]: https://wiki.lspace.org/Lancre diff --git a/i18n/cs.toml b/i18n/cs.toml index a33158e3e5..f61ac11806 100644 --- a/i18n/cs.toml +++ b/i18n/cs.toml @@ -614,7 +614,7 @@ other = "Akcie můžete darovat také několika kliknutími přes {{ .givingBloc other = "Darovat kryptoměnu" [donate_2026_donate_cryptocurrency_text] -other = "Většinu kryptoměn můžeme přijímat prostřednictvím {{ .givingBlockLink }}. U těchto transakcí nám vznikají poplatky za zpracování, proto prosím zvažte, zda je zaplatíte, aby měl váš dar co největší dopad." +other = "Přijímáme většinu kryptoměn. Přispět můžete přes {{ .givingBlockLink }}. Za tyto transakce platíme poplatky za zpracování. Zvažte prosím jejich uhrazení, aby váš dar měl co největší dopad." [donate_2026_donor_advised_funds_title] other = "Fondy spravované podle pokynů dárce (DAF)" diff --git a/i18n/zh-cn.toml b/i18n/zh-cn.toml index 5914f97f38..02de49e119 100644 --- a/i18n/zh-cn.toml +++ b/i18n/zh-cn.toml @@ -611,7 +611,7 @@ other = "您也可以通过{{ .givingBlockLink }}更加便捷地捐赠股权， other = "捐赠加密货币" [donate_2026_donate_cryptocurrency_text] -other = "我们也支持通过{{ .givingBlockLink }}接收加密货币，但这种交易方式会产生手续费，因此请考虑补齐差额，以确保您的善款能够最大程度发挥效力。" +other = "我们也接受大部分类型的加密货币。您可以通过{{ .givingBlockLink }}捐赠加密货币，但这种交易方式会产生手续费，因此请考虑补齐差额，以确保您的善款能够最大程度发挥效力。" [donate_2026_donor_advised_funds_title] other = "捐赠人建议基金 (DAF)"