SSL証明書/Memo_Of_LetsEncrypt

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」である（場合によってはこっち「も」入ってることがあるかもしれない）。

なおツールとしては certbot が代表的だが、他にもたくさんのツールが存在する。

ここでは全て dehydrated を使用を前提に解説する。certbotとdehydratedの違いについては特に解説しない。

dehydratedを選んだ理由は、

• dehydratedはＢａｓｈ／ＺＳＨ依存スクリプトであるため、特別な言語環境（Ｐｙｔｈｏｎ）を必要としない。

• certbotの場合、Ｐｙｔｈｏｎに依存する分には問題無いが、依存するＰｙｔｈｏｎモジュールが極めて大量にあって維持が大変。

• dehydratedはまだ依存が少ない（curl のせいでずいぶん増えてるが）。

• dehydratedの場合、わけわかんなくなっても、シェルスクリプトなのでソースコード読んで理解できる。また長いコードではない。

• dehydratedはＷｅｂサーバー機能を内蔵していないため、Ｗｅｂサーバーとの競合に配慮しなくてよい。

• dehydratedはエイリアス機能により、同じコモンネームでＲＳＡ／ＥＣＤＳＡ両方の証明書取得が可能である。