|
サイズ: 4859
コメント:
|
← 2019-12-14 22:07:35時点のリビジョン8 ⇥
サイズ: 5199
コメント:
|
| 削除された箇所はこのように表示されます。 | 追加された箇所はこのように表示されます。 |
| 行 7: | 行 7: |
| * [[https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html|今のところ]]ワイルドカード証明書には対応していない（対応してるブランドと対応してないブランドとあるね）。 * ＤＶ（Domain Validation）証明書のみ提供（対応してるブランドと対応してないブランドとあるね）。 * ただしＯＶ（Organization Validation）証明書やＥＶ（Extended Validation）証明書との純技術的な優劣は無い。 |
* [[https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html|いよいよ]][[https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579|ワイルドカード証明書]]に対応（対応してるブランドと対応してないブランドとあるね）。 * ＤＶ（`Domain Validation`）証明書のみ提供（ＤＶだけでなくＯＶ・ＥＶにも対応してるブランドもあるね）。 * ただしＯＶ（`Organization Validation`）証明書やＥＶ（`Extended Validation`）証明書との純技術的な優劣は無い。 |
| 行 12: | 行 12: |
| * ＲＳＡ(2048bit、3072bit、4096bit), ＥＣＤＳＡ(prime256v1、secp384r1) の５種類の鍵が選べる（ここまで選べる認証局は限られるね）。ＤＳＡが無い？時代だ。諦めろ。 * ＡＣＭＥ（Automated Certificate Management Environment）プロトコルによる証明書の認証から発行までの一連のバッチ化（自動化）が可能。 * 今どき誤差かもしれないが、扱える端末が（他の認証局と比べて）少ない。 * エンドユーザーが粘り強く使用している、全アクセスの０．５％以下の端末であってもフォローしないといけない用途であるならお勧めしない。 |
* ＲＳＡ(`2048bit`、`3072bit`、`4096bit`), ＥＣＤＳＡ(`prime256v1`、`secp384r1`) の５種類の鍵が選べる（ここまで選べるブランドは限られるね）。ＤＳＡが無い？時代だ。諦めろ。 * ＡＣＭＥ（`Automated Certificate Management Environment`）プロトコルによる証明書の認証から発行までの一連のバッチ化（自動化）が可能。 * 今どき誤差だけど、扱える端末が（他の認証局と比べて）少ない。 * ごく一部のエンドユーザーが粘り強く使用しているような、全アクセスの０．１％未満の端末であってもサポートしないといけない用途であるならお勧めしない。 |
| 行 17: | 行 17: |
| * よってＰＣ相手にはほぼ問題無い（Windows XP? IE6? 知らんがな）。 | * よってＰＣ相手にはほぼ問題無い（`Windows XP`? `IE6`? 知らんがな）。 |
| 行 21: | 行 21: |
| * !IdentTrust なの？ DST なの？ については旧会社のブランドも残ってるらしい、としか自分は認識してない。詳しくは[[https://www.identrust.com/company/company_profile.html|会社概要]]でも読んでくれい。 * 少なくとも中間証明書の発行者（Issuer）はそうである（Let's Encrypt 運用元の [[https://letsencrypt.org/isrg/|ISRG - Internet Security Research Group]] ではない）。 |
* `IdentTrust` なの？ `DST` なの？ については旧会社のブランドも残ってるらしい、としか自分は認識してない。詳しくは[[https://www.identrust.com/company/company_profile.html|会社概要]]でも読んでくれい。 * 少なくとも中間証明書の発行者（`Issuer`）はそうである（`Let's Encrypt`運用元の [[https://letsencrypt.org/isrg/|ISRG - Internet Security Research Group]] ではない）。 |
| 行 24: | 行 24: |
| * 中間証明書（Subject）は「Let's Encrypt Authority X3」である（場合によってはこっち「も」入ってることがあるかもしれない）。 | * 中間証明書（`Subject`）は「`Let's Encrypt Authority X3`」である（場合によってはこっち「も」入ってることがあるかもしれない）。 |
| 行 26: | 行 26: |
| * ここでは全て [[https://github.com/lukas2511/dehydrated|dehydrated]] を使用を前提に解説する。certbot と dehydrated の違いについては特に解説しない。 * dehydrated を選んだ理由は、 * dehydrated は bash/zsh 依存スクリプトであるため、特別な言語環境（Python）を必要としない。 * Python に依存するくらいならまだ良いが、certbot は依存する Python モジュールが極めて大量にある。 * dehydrated はまだ依存が少ない（[[https://curl.haxx.se/|curl]] のせいでずいぶん増えてるが）。 * dehydrated の場合、わけわかんなくなっても、シェルスクリプトなのでソースコード読んで理解できる。また長いコードではない。 * dehydrated はＷｅｂサーバーを内蔵していないため、Ｗｅｂサーバー（Apache 等）との組み合わせに考慮しなくてよい。 |
* ここでは全て [[https://github.com/lukas2511/dehydrated|dehydrated]] を使用を前提に解説する。`certbot`と`dehydrated`の違いについては特に解説しない。 * `dehydrated`を選んだ理由は、 * `dehydrated`はＢａｓｈ／ＺＳＨ依存スクリプトであるため、特別な言語環境（Ｐｙｔｈｏｎ）を必要としない。 * `certbot`の場合、Ｐｙｔｈｏｎに依存する分には問題無いが、依存するＰｙｔｈｏｎモジュールが極めて大量にあって維持が大変。 * `dehydrated`はまだ依存が少ない（[[https://curl.haxx.se/|curl]] のせいでずいぶん増えてるが）。 * `dehydrated`の場合、わけわかんなくなっても、シェルスクリプトなのでソースコード読んで理解できる。また長いコードではない。 * `dehydrated`はＷｅｂサーバー機能を内蔵していないため、Ｗｅｂサーバーとの競合に配慮しなくてよい。 * `dehydrated`はエイリアス機能により、同じコモンネームでＲＳＡ／ＥＣＤＳＡ両方の証明書取得が可能である。 |
Lets' Encrypt は認証局（Certificate Authority）のブランドの一つである。
これは「Symantec(旧Verisign)セキュア・サーバーＩＤ」「CyberTrust SureServer」「SecomTrust セコムパスポート for Web3.0」「GlobalSign クイック認証SSL」「GeoTrust RapidSSL」「Comodo PositiveSSL」などの一つと考えれば良い。
- たぶんどれかは聞いたことあるはずと思う。アレが抜けてるというツッコミは却下で:-)。
- 他の認証局と同じような点は、
- １証明書をどのように（複数ＩＰ、複数バックエンド、複数プロトコル）使用しても１取得で済む（安い認証局は大抵そうだよね）。
- 親ドメインをまたぐ、マルチドメイン証明書（Subject Alternative Names）に対応している（全ての認証局で対応してるね）。
いよいよワイルドカード証明書に対応（対応してるブランドと対応してないブランドとあるね）。
ＤＶ（Domain Validation）証明書のみ提供（ＤＶだけでなくＯＶ・ＥＶにも対応してるブランドもあるね）。
ただしＯＶ（Organization Validation）証明書やＥＶ（Extended Validation）証明書との純技術的な優劣は無い。
- 他の認証局と明確に違う点は、
- 無償。
ＲＳＡ(2048bit、3072bit、4096bit), ＥＣＤＳＡ(prime256v1、secp384r1) の５種類の鍵が選べる（ここまで選べるブランドは限られるね）。ＤＳＡが無い？時代だ。諦めろ。
ＡＣＭＥ（Automated Certificate Management Environment）プロトコルによる証明書の認証から発行までの一連のバッチ化（自動化）が可能。
- 今どき誤差だけど、扱える端末が（他の認証局と比べて）少ない。
- ごく一部のエンドユーザーが粘り強く使用しているような、全アクセスの０．１％未満の端末であってもサポートしないといけない用途であるならお勧めしない。
- 逆に今どきのメジャーどころの端末・ブラウザは対応している。
よってＰＣ相手にはほぼ問題無い（Windows XP? IE6? 知らんがな）。
取得数制限（特に単位時間あたりの）があるので注意。詳しくは Rate Limits を参照のこと。
検証（ステージング）用認証局も用意されているので、セットアップ時の検証や、ＡＣＭＥクライアントの開発といった用途ではこちらを使う。
「現在の」ルート証明書は「IdentTrust|DST(Digital Signature Trust) Root CA X3」である。
IdentTrust なの？ DST なの？ については旧会社のブランドも残ってるらしい、としか自分は認識してない。詳しくは会社概要でも読んでくれい。
少なくとも中間証明書の発行者（Issuer）はそうである（Let's Encrypt運用元の ISRG - Internet Security Research Group ではない）。
- このルート証明書がインストールされた端末が対応端末となる。
中間証明書（Subject）は「Let's Encrypt Authority X3」である（場合によってはこっち「も」入ってることがあるかもしれない）。
ここでは全て dehydrated を使用を前提に解説する。certbotとdehydratedの違いについては特に解説しない。
dehydratedを選んだ理由は、
dehydratedはＢａｓｈ／ＺＳＨ依存スクリプトであるため、特別な言語環境（Ｐｙｔｈｏｎ）を必要としない。
certbotの場合、Ｐｙｔｈｏｎに依存する分には問題無いが、依存するＰｙｔｈｏｎモジュールが極めて大量にあって維持が大変。
dehydratedはまだ依存が少ない（curl のせいでずいぶん増えてるが）。
dehydratedの場合、わけわかんなくなっても、シェルスクリプトなのでソースコード読んで理解できる。また長いコードではない。
dehydratedはＷｅｂサーバー機能を内蔵していないため、Ｗｅｂサーバーとの競合に配慮しなくてよい。
dehydratedはエイリアス機能により、同じコモンネームでＲＳＡ／ＥＣＤＳＡ両方の証明書取得が可能である。