してみるテストロゴ
Apache 2.4系でHTTP/2サーバを構築してみるテスト。

Let's Encryptの機能のまとめ

2015年12月3日のパブリックベータ開始から、すこし時間が経ちました。

2016年4月12日にベータが取れ、正式運用が開始しました。

この間、地道に機能の拡張が行われていますので、まとめたいと思います。

また、その後の変化や、これから予想される動きも、コチラに書き足していこうと思います。

2020年2月7日 複数視点からのドメイン検証を2月19日から開始する予定であることを追記しました。
2020年1月18日 証明書へのIPアドレスの埋め込みを計画していることを追記しました。
2019年5月15日 Let's Encryptによる証明書透過性ログ(Certificate Transparency Log)の運用が開始されました。
2019年4月16日 これまでのIden Trustの証明書によるクロス署名から、Let's Encrypt自身のISRG Root X1証明書による署名に切り替える計画を発表しました。
2019年3月12日 2021年6月に,ACMEv1による証明書の発行を停止するスケジュールを発表しました。(testtlnlsさん情報ありがとうございます。)
2019年1月18日 2019年2月13日にTLS-SNI-01チャレンジによる既存の証明書更新の終了する件を追記しました。
2019年1月7日 Let's Encryptに「追加される予定の機能」のスケジュールを修正しました。
>>Let's Encryptの更新履歴

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に変わりました。

  • DigiCert's Yeti 2023
  • DigiCert's Nessie 2023
  • Google's Argon 2023
  • Google's Xenon 2023
  • Let's Encrypt's Oak 2019
  • Let's Encrypt's Oak 2020
  • Let's Encrypt's Oak 2021
  • Let's Encrypt's Oak 2022

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対応のサーバ証明書ですね。

>> 公式ACMEエージェントのRSA対応サーバ証明書

>> 非公式ACMEエージェントのRSA対応サーバ証明書

ECDSA対応のサーバ証明書

PCやスマートフォンのうち、比較的新しいものは、RSAよりもECDSA対応のサーバ証明によってサーバ負荷を軽くできます。

>> 公式ACMEエージェントのECDSA対応サーバ証明書

>> 非公式ACMEエージェントのECDSA対応サーバ証明書

クラウド環境など、負荷分散装置配下の場合

負荷分散装置の配下だとWebrootを使うhttp-01ドメイン認証チャレンジが難しくなります。

そこで、HTTPではなく、DNSを利用したドメイン認証(dns-01)を使います。

クラウド向けに、AWS用やCloudFlare用など、各サービス用のスクリプトが用意されていますので、簡単に導入できます。

>>  非公式ACMEエージェントのdns-01チャレンジの場合 

 

cronを使った自動再取得

Let's Encryptの発行するサーバ証明書は、90日しか有効期限がありません。そこで、自動的に再取得するスクリプトを用意します。

>> RSA証明書 公式ACMEエージェントの場合 (リダイレクト対応

>> ECDSA対応証明書 公式ACMEエージェントの場合

>> 非公式ACMEエージェントの場合

 

Let's Encryptの制限について

自動化できるが故、一定の制限がかかっています。

>> サーバ証明書発行の枚数制限について

テストなど、実運用に入る前には、ステージング環境でテストすると、前記制限を回避しやすくなります。

>> ステージング環境について

メンテナンス情報の告知

>> status.ioについて

 

多国語ドメインについて

Let's Encryptは、2016年3月現在、日本語ドメインを含む多国語ドメイン(Punycode domains)には対応していません。

これは、ラテン系文字によく似た、非ラテン文字を使ったドメイン名によるフィッシングを防ぐためです。認証の課程で、人間が介在しないため、致し方ないところでしょうか。

2016年11月を目安に、国際ドメイン名(IDN)に対応とのアナウンスが出ました。>>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ログのモニター状況はコチラから確認できます。

NEXT >> Let's Encryptのサーバ証明書を自動更新

©Copyrights 2015-2023, non-standard programmer

このサイトは、あくまでも私の個人的体験を、綴ったものです。 軽く参考程度にご利用ください。