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

Let's EncryptのDNS CAA検証漏れのバグに伴う、証明書取り消しについて

世界標準時間(UTC)の2020年3月4日の午前0時0分(日本時間の2020年3月4日午前9時)から、証明書の取り消しが実施されます。

原因と影響範囲についてまとめてみました。

2020年3月5日追記
再発行などにより、置き換えられたと思われる1,706,505 の証明書と、
DNS CAAによってLet's Encryptによる発行が明示的に禁止されていた445 の証明書
について失効が行われたようです。
残りの約100万については、コンプライアンス期限までには、失効させない模様です。
DNS CAAの検証を行っていないとは言え、発行されたサーバ証明書が悪用される可能性が低く、いたずらに混乱させないためには、最善かもしれません。

原因となったバグ

Let's Encryptでは、サーバ証明書の発行に先立ち、ドメイン名の所有者からの発行要求かどうかを検証します。

これをドメインコントロールの検証と呼びます。

Let's Encryptでは、ドメインコントロールの検証後、30日間はこの検証が有効と考えています。

その一方で、サーバ証明書の発行については、DNS CAA(参考:当サイトの解説)と呼ばれる仕組みによって、DNSサーバを使って、ドメイン名毎にサーバ証明書を発行できる発行先を指定できるようになっています。

DNS CAAによってサーバ証明書の発行先を限定している場合、DNS CAAは、発行前8時間以内に検証しておかなければなりません。

修正前のLet's Encryptは、ドメインコントロールの検証結果のみを根拠にサーバ証明書を発行していたため、DNS CAAの発行前8時間以内の検証を行わずに、サーバ証明書を発行してしまったようです。

影響範囲と対処方法

問題のバグは、2019年7月25日頃に導入されたとみられます。

世界標準時2020年2月29日3時8分に、問題のバグによる証明書発行が停止され、同5時22分に修正プログラムが展開されています。

そのため、世界標準時2020年2月29日5時22分(日本時間2020年02月29日(土) 14時22分)以降に、Let's Encryptが発行したサーバ証明書は影響を受けません。

また、ほとんどの証明書が、DNS CAAの検証とドメインコントロールの検証を同時に行い、その場で証明書を発行しているため、影響を受けません。

影響を受けるのは、サーバ証明書を30日以内に再発行するか、30日以内に、同一ドメインの検証によって発行可能な、サブドメインのサーバ証明書を取得するなどした場合になります。

Let's encryptでは、現在有効な証明書(1億1,600万個)の内、2.6%が影響を受けるとしています。

ただし、30日以内の再発行などを行っているドメインが、重複してサーバ証明書を取得しているため、実際に影響を受けるドメイン名の割合は、これよりも少ないと考えられます。

とはいえ、これほどの数のサーバ証明書が一度に無効になるのは、珍しく、おそらく過去最大規模かもしれません。OCSP様々です。

OCSPは、サーバ証明書の失効情報を確認するプロトコルです。Let's ecnryptの場合、http://ocsp.int-x3.letsencrypt.orgが利用されます。

この失効情報について、OCSP Staplingと呼ばれる、サーバ側のキャッシュを利用している場合、その間(通常、一週間ほど)、失効したことがブラウザまで伝わらないことがあります。

そのため、世界標準時間(UTC)の2020年3月4日の午前0時0分(日本時間の2020年3月4日午前9時)から、失効が、上記のOCSPサーバに登録された場合、一週間ほどの時間をかけて、じわじわ影響が出てくることが考えられます。

心配な方は、以下の確認方法で、自分のドメイン名の証明書が影響を受けるのか、確認することができます。

もし、影響を受ける場合、通常のrenewによるサーバ証明書の再取得を行えば、問題の無いサーバ証明書を取得できます。

確認方法

自分のドメイン名が影響を受けるかを確認するためのサイトがあるようですが、日本時間の2020年3月4日午前7時頃はうまく稼働していないようです。

そのため、以下のファイル(caa-rechecking-incident-affected-serials.txt.gz)をダウンロードして、確認する方法が確実のようです。

$ wget https://d4twhgtvn0ff5.cloudfront.net/caa-rechecking-incident-affected-serials.txt.gz
$ gzip -d caa-rechecking-incident-affected-serials.txt.gz

として、リストをダウンロードして展開します。

続いて、以下のように、調べたいサーバ証明書のシリアルナンバーを取得します。

緑色の「try-and-test.net」の部分を、皆さんの調べたいサーバ証明書のドメイン名に書き換えてください。

$ openssl s_client -connect try-and-test.net:443 -servername try-and-test.net -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :

Serial Number
    03a8eddcf8ac4fda027c136612ebf7d1c083

上記出力されたシリアルナンバー(黄色の部分)をコピーして、以下のように、grepコマンドを打ちます。

$ grep 03a8eddcf8ac4fda027c136612ebf7d1c083 caa-rechecking-incident-affected-serials.txt
といったコマンドを打って、grepに引っかからなければ、OKです。

NEXT >> トップページに戻る

©Copyrights 2015-2020, non-standard programmer

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