Apache 2.4系でHTTP/2サーバを構築してみるテスト。
Let's Encryptの機能のまとめ2015年12月3日のパブリックベータ開始から、すこし時間が経ちました。 2016年4月12日にベータが取れ、正式運用が開始しました。 この間、地道に機能の拡張が行われていますので、まとめたいと思います。 また、その後の変化や、これから予想される動きも、コチラに書き足していこうと思います。
Let's EncryptとはLet's Encrypt (レッツ・エンクリプト)は、無償で90日間有効なSSL/TLS用のサーバ証明書を発行してくれます。 これまで、サーバ証明書の発行は、CSRと呼ばれるファイルをWebサイトにアップロードしてから、決済を行うなど、手作業が必要でしたが、Let's Encryptでは、ACMEプロトコルと呼ばれる方法を利用して、サーバ証明書取得の自動化を実現しています。 ACMEエージェントと呼ばれる、ACMEプロトコルのクライアントは、公式、非公式のものがありますが、Windows/Linuxなどに対応しており、若干の修正で、他のUnixでも動作します。 一般的なRSA暗号に加えて、ECDSAと呼ばれる楕円曲線暗号を利用してサーバ負荷を抑えることができるサーバ証明書の発行にも対応しています。 HTTP/2では、事実上TLS通信が必須となりますので、当サイトの説明をご覧の上、無料で取得する方法を是非みなさんのものにしてください。
Let's Encryptに追加される予定の機能Let's Encryptの公式ページによれば、以下の機能が追加の予定です。以下、独断と偏見の翻訳。 2020年1月14日現在のスケジュール 証明書へのIPアドレスの埋め込み [開始時期未定]証明書へのIPアドレスの埋め込みをサポートする計画があるようです。 ルート証明書の切り替え [2020年7月8日][2019年7月10日追記]Android端末におけるルート証明書の普及を待つため、開始が2020年7月8日に延期されました。 https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html 2020年7月8日から、Let's Envrypt自身のISRG Root X1証明書によって署名された中間証明書に切り替わる予定です。中間証明書を自動で設定している場合、特に作業は必要ありません。 中間証明書を手動で設定している場合、2021年9月29日までに、Signed by ISRG Root X1の証明書をダウンロードして、更新してください。 ただし、ISRG Root X1によって署名されたLet’s Encrypt Authority X3も、有効期限が2021年10月6日なので、後継となるLet’s Encrypt Authority X5以降がそれまでに発行されると思われます。 引き続きアナウンスにも注意してください。 2020年7月8日より前に発行されるサーバ証明書のfullchain.cerに同梱される中間証明書 Let’s Encrypt Authority X3 (IdenTrust cross-signed)[有効期限2021年3月17日] 2020年7月8日以降に発行されるサーバ証明書のfullchain.cerに同梱される中間証明書 Let’s Encrypt Authority X3 (Signed by ISRG Root X1)[有効期限2021年10月6日]
ACMEv1プロトコルによる証明書の発行完全終了 [2021年6月頃]https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 2021年6月頃に ACMEv1完全終了とのことです。(testtlnlsさん情報ありがとうございます。) まず、ドメインの新規登録について、2019年10月10日~11日と10月16日~18日の2回、無効にします。 10月31日以降はACME v1において新規のドメイン登録を永続的に無効にします。 https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/3 その後、2021年5月末日頃に、登録済みドメインについても、ACMEv1による更新を停止する予定です。 複数視点からのドメイン検証(Multi-Perspective Validation) [2020年2月19日開始予定]BGPハイジャックなどによって、ドメイン所有者以外に証明書を発行することを防ぐため、独立した複数のネットワークからドメインを検証するようにします。 ECDSAルート証明書&ECDSA中間証明書対応 [2019年9月末までに開始の予定]現在、Let’s EncryptはRSA暗号方式のルート証明書及び中間証明書だけですが、サーバ証明書を、ECDSA方式の中間証明書で署名する機能を追加する予定です。 Let's Encryptに追加された機能等証明書透過性ログ(Certificate Transparency Log) [2019年5月15日]証明書が、正当な方法で発行されたことを公開しておくことで、偽造された証明書を防ぎます。 今後、90日間の監視が成功した後、Google ChromeおよびApple Safariの承認済みログとなる見込みです。 https://letsencrypt.org/docs/ct-logs/ 以下の証明書ログサーバの評価がPenddingからQualifiedに変わりました。
TLS-SNI-01チャレンジによる既存の証明書更新の終了 [2019年3月14日]2018年1月から、脆弱性により、TLS-SNI-01チャレンジによる新規証明書の取得が停止しており、既存の証明書の更新のみ行えておりましたが、TLS-SNI-01チャレンジによる更新も終了となりました。 TLS-SNI-01チャレンジを使って、既存の証明書の更新を行っているサーバが影響を受けます。 対応策としては、ACMEクライアントの種類にもよりますが、Certbotならバージョンを上げるだけで、TLS-ALPN-01チャレンジが利用できるようになり、TLS-SNI-01チャレンジと同じ設定のまま、証明書の更新ができるはずです。 Letsencrypt-auto等の既にサポートが終了したクライアントの場合、http-01の設定を用意するか、Certbot等の最新版のACMEクライアントをインストールしてください。 新たにACMEクライアントをインストールするなら、acme.shがOS依存しないのでオススメです。 詳細はコチラ(英語)。@beyondDNSさん、情報ありがとうございます! TLS ALPN Challenge [2018年7月12日開始]セキュリティ上の問題があったTLS-SNI-01、およびTLS-SNI-02に代わり、TLSを使ったドメイン認証の方法として、TLS-ALPN-01が実装されました。 証明書タイムスタンプ署名の埋め込み [2018年3月29日開始]証明書タイムスタンプ署名(SCT : Signed Certificate Timestamp)を証明書に埋め込んで発行することで、CT(Certificate Transparency:証明書の透明性)の監査に対応しました。 ACME v2のサポート開始 [2018年3月14日開始]ACMEプロトコルの最新版であるACME v2に対応しました。 当面、現在利用しているACME v1も利用できる見込みです。 ACME v2においてワイルドカード証明書の発行開始 [2018年3月14日開始]ACME v2において、ワイルドカード証明書の発行か開始されました。dns-01認証チャレンジが必須です。 これまで、単独ではLet'encryptの証明書を取得できなかった機器も、他のホストで証明書を取得後にインストールすることで、有効なLet'encryptの証明書を利用できます。 国際ドメイン名対応開始 [2016年10月20日に対応開始]国際ドメイン名(IDN)に対応しました。 Punycodeのドメイン名に、証明書を発行してくれます。 詳しい使い方は、 をご覧ください。 IPv6対応開始 [2016年7月26日に対応開始]Let's Encryptが、IPv6対応にしました。 詳しい使い方は、 をご覧ください。
Let's Encryptの主な機能パブリックベータ開始当初は、RSA対応のサーバ証明書が、公式ACMEエージェントから取得できる程度だったのですが、非公式のACMEエージェントが増えてきたり、ECDSA対応のサーバ証明書が取得できるようになったり、してきています。 すでに有償のサーバ証明書発行機関と比較しても遜色ないところまで来ています。 [2016年6月19日追記] このページで説明している、letsencrypt-autoの名称が、certbot-autoに代わりました。 最近のバージョンのLinuxとFreeBSDとOpenBSDであれば、パッケージシステムからインストールで気うようになっています。 上記ページでcertbotコマンドをインストールしてから進んでください。 基本的な知識や、コマンドの実行は、こちらをご覧ください。 RSA対応のサーバ証明書古いブラウザなどとの互換性を重視するなら、RSA対応のサーバ証明書ですね。 ECDSA対応のサーバ証明書PCやスマートフォンのうち、比較的新しいものは、RSAよりもECDSA対応のサーバ証明によってサーバ負荷を軽くできます。 >> 非公式ACMEエージェントのECDSA対応サーバ証明書 クラウド環境など、負荷分散装置配下の場合負荷分散装置の配下だとWebrootを使うhttp-01ドメイン認証チャレンジが難しくなります。 そこで、HTTPではなく、DNSを利用したドメイン認証(dns-01)を使います。 クラウド向けに、AWS用やCloudFlare用など、各サービス用のスクリプトが用意されていますので、簡単に導入できます。 >> 非公式ACMEエージェントのdns-01チャレンジの場合
cronを使った自動再取得Let's Encryptの発行するサーバ証明書は、90日しか有効期限がありません。そこで、自動的に再取得するスクリプトを用意します。 >> RSA証明書 公式ACMEエージェントの場合 (リダイレクト対応)
Let's Encryptの制限について自動化できるが故、一定の制限がかかっています。 テストなど、実運用に入る前には、ステージング環境でテストすると、前記制限を回避しやすくなります。 >> ステージング環境について メンテナンス情報の告知
多国語ドメインについて
国際ドメイン名(IDN)に対応しました。Punycodeのドメイン名に、証明書を発行してくれます。 上記の通り、対応しました。
証明書の透過性情報の登録Let's Encryptから、ACMEプロトコルを使用して、証明書を取得すると、自動的に証明書の透過性情報を登録してくれます。 透過性情報の登録とは、偽造された証明書を識別するために、第三者のサーバに登録しておきます。 Let's Encryptの署名にも係わらず、このサーバに登録の無い証明書は、Let's Encryptが発行した物ではない可能性が出てくるので、偽造の可能性があるということになります。 ブラウザに、この透過性情報を伝える方法は3種類ありますが、まだLet's Encryptは対応していません。 ただ、自動登録していることから、OCSP Staplingの中に登録済み証明書タイムスタンプ(Signed Certificate Timestamp:SCT)、の情報を埋め込む方法を実装する布石だと思われます。 まだLet's Let's EncryptのOCSPサーバから、SCTの情報を埋め込んだ、データは提供されていないようですが、準備だけは進めている感じでしょうか。
⇒登録済み証明書タイムスタンプの埋め込みに、2018年3月29日に開始しました。 ということで、Let's Encryptのサーバ証明書を利用するなら、OCSP Staplingの設定は済ませておきましょう。 ちなみに、Let's Encryptが発行したサーバ証明書の透過性情報は、こちらから検索することができます。 >> crt.sh (Let's Encrypt Authority X3) 使い方は簡単。下段のフォームに検索したいドメイン名(FQDN)を入れて、Searchボタンを押します。
![]() 当然といえば当然ですが、発行履歴が一目瞭然です。 有償の証明書が1年間有効なのに比べて、Let's Encryptのサーバ証明書の有効期限は90日ですので、ドメイン名あたりの証明書の数がどうしても増えてしまいます。 とはいえ、EV証明書では、透過性情報の登録は必須なので、気にすることではないのかもしれません。 ちなみに、Let's Encryptの証明書の発行総数も、ここで判っちゃいますね。 なお、CTログのモニター状況はコチラから確認できます。
| ||||||||||||||||||||||||||||||||||||||||