* [[https://letsencrypt.jp/|Lets' Encrypt]] は認証局(Certificate Authority)のブランドの一つである。 * これは「Symantec(旧Verisign)セキュア・サーバーID」「!CyberTrust !SureServer」「!SecomTrust セコムパスポート for Web3.0」「!GlobalSign クイック認証SSL」「!GeoTrust RapidSSL」「Comodo PositiveSSL」などの一つと考えれば良い。 * たぶんどれかは聞いたことあるはずと思う。アレが抜けてるというツッコミは却下で:-)。 * 他の認証局と同じような点は、 * 1証明書をどのように(複数IP、複数バックエンド、複数プロトコル)使用しても1取得で済む(安い認証局は大抵そうだよね)。 * 親ドメインをまたぐ、マルチドメイン証明書(Subject Alternative Names)に対応している(全ての認証局で対応してるね)。 * [[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|ワイルドカード証明書]]に対応(対応してるブランドと対応してないブランドとあるね)。 * DV(`Domain Validation`)証明書のみ提供(DVだけでなくOV・EVにも対応してるブランドもあるね)。 * ただしOV(`Organization Validation`)証明書やEV(`Extended Validation`)証明書との純技術的な優劣は無い。 * 他の認証局と明確に違う点は、 * 無償。 * RSA(`2048bit`、`3072bit`、`4096bit`), ECDSA(`prime256v1`、`secp384r1`) の5種類の鍵が選べる(ここまで選べるブランドは限られるね)。DSAが無い?時代だ。諦めろ。 * ACME(`Automated Certificate Management Environment`)プロトコルによる証明書の認証から発行までの一連のバッチ化(自動化)が可能。 * 今どき誤差だけど、扱える端末が(他の認証局と比べて)少ない。 * ごく一部のエンドユーザーが粘り強く使用しているような、全アクセスの0.1%未満の端末であってもサポートしないといけない用途であるならお勧めしない。 * 逆に今どきのメジャーどころの端末・ブラウザは対応している。 * よってPC相手にはほぼ問題無い(`Windows XP`? `IE6`? 知らんがな)。 * 取得数制限(特に単位時間あたりの)があるので注意。詳しくは [[https://letsencrypt.org/docs/rate-limits/|Rate Limits]] を参照のこと。 * [[https://letsencrypt.org/docs/staging-environment/|検証(ステージング)用認証局]]も用意されているので、セットアップ時の検証や、ACMEクライアントの開発といった用途ではこちらを使う。 * 「現在の」ルート証明書は「[[https://www.identrust.com/|IdentTrust]]|DST(Digital Signature Trust) Root CA X3」である。 * `IdentTrust` なの? `DST` なの? については旧会社のブランドも残ってるらしい、としか自分は認識してない。詳しくは[[https://www.identrust.com/company/company_profile.html|会社概要]]でも読んでくれい。 * 少なくとも中間証明書の発行者(`Issuer`)はそうである(`Let's Encrypt`運用元の [[https://letsencrypt.org/isrg/|ISRG - Internet Security Research Group]] ではない)。 * このルート証明書がインストールされた端末が対応端末となる。 * 中間証明書(`Subject`)は「`Let's Encrypt Authority X3`」である(場合によってはこっち「も」入ってることがあるかもしれない)。 * なおツールとしては [[https://certbot.eff.org/|certbot]] が代表的だが、他にもたくさんの[[https://letsencrypt.org/docs/client-options/|ツール]]が存在する。 * ここでは全て [[https://github.com/lukas2511/dehydrated|dehydrated]] を使用を前提に解説する。`certbot`と`dehydrated`の違いについては特に解説しない。 * `dehydrated`を選んだ理由は、 * `dehydrated`はBash/ZSH依存スクリプトであるため、特別な言語環境(Python)を必要としない。 * `certbot`の場合、Pythonに依存する分には問題無いが、依存するPythonモジュールが極めて大量にあって維持が大変。 * `dehydrated`はまだ依存が少ない([[https://curl.haxx.se/|curl]] のせいでずいぶん増えてるが)。 * `dehydrated`の場合、わけわかんなくなっても、シェルスクリプトなのでソースコード読んで理解できる。また長いコードではない。 * `dehydrated`はWebサーバー機能を内蔵していないため、Webサーバーとの競合に配慮しなくてよい。 * `dehydrated`はエイリアス機能により、同じコモンネームでRSA/ECDSA両方の証明書取得が可能である。