無料のサーバー証明書「Let's Encrypt」を使ってみて気が付いた事【SSL/TLS】
完全無料で SSL/TLS サーバー証明書を発行してもらえる「Let's Encrypt」について、実際に使ってみて気が付いたことを今さらですがまとめておきます。
サーバー証明書にCRLの記述が無い
Let's Encrypt を使ってまず最初に気になったのは、証明書に CRL（Certificate Revocation List・証明書失効リスト）配布ポイントが記述されていない、という点です。
今まで発行したことのある有料のサーバー証明書では、例外なく CRL 絡みの記述があったと記憶しているのですが、Let's Encrypt は CRL 非対応で、証明書失効の確認は、OCSP（Online Certificate Status Protocol）のみの対応となっています。
もっとも、この背景には色んな要因が透けて見えまして、特に、Let's Encrypt のように膨大な数の証明書を発行する認証機関の場合、仕組み上、CRL ではスケールが難しいでしょうから、これは順当な判断かな、とも思います。
CRL の代替となる OCSP ですが、こちらは証明書失効の問い合わせを証明書内で指定されたポイントに対して都度行う仕組みとなっています。この方式だと、スケールしやすい代わりにCAがユーザーの接続先サーバー情報を収集できる、というセキュリティ上の課題、また、OCSP 自体が HTTPS ハンドシェイクのオーバーヘッドとなるという問題を抱えており、Google Chrome ではこれらの問題を避けるためか、初期状態では OCSP を利用しない設定になっているらしく。
このオーバーヘッド問題に関しては、Chrome 以外のブラウザ向けにWEBサーバー側で OCSP Stapling を ON にしておくことで、閲覧者の安全性とパフォーマンスの両面で解決できそうだ、との見込みから、問題ないとの結論に至りました。
ドメイン乗っ取り対策が重要
Let's Encrypt のように自動発行される DV（ドメイン認証）証明書の場合、ドメイン・DNS のセキュリティの担保が非常に重要なのではないか、と、実際に設定作業を行う中で強く感じました。
別に、有料のDV 証明書を発行したことがあるドメインだからといって、過去の金銭のやり取りを論拠にレジストラが「ハイハイ」と乗っ取られたドメイン登録を元に戻してくれる気もしませんが（刑事・民事上手続き上の一助にはなるかもですが）、Let's Encrypt の場合、証明書発行にあたって DNS の制御権の有無のみが問われ、金銭のやり取りが一切発生しないため、DNS の制御権をしっかりと握っておくことがものすごく大事なんじゃ？とは肌感覚で感じるところです。
もっとも、これは感覚の話であって、技術的な意味は無い気もするんですが、有事の法務的対応まで見据えたときに、ちょっと危なさを感じるなー、という部分ではある気がして。
ちゃんとしたサイトであれば、ドメイン移管を悪用したサイトの乗っ取り対策としてトランスファーロックを掛けていたり、DNS レコードを書き換えできるようなクラウドサービスのAPIキーは特に厳重に管理している事とは思いますが、攻撃手段は他にも腐るほどありますし、脇が甘いとドメインからサーバー証明書までしっかり揃った偽物サイトが簡単に作れそうで怖いなー、とは思うところです。
Let's Encrypt 側としても地理的に離れた複数地点から DNS レコードの確認を行うことでスプーフィング対策はしているとのことで、この部分だけ見れば安心感はあるわけですが、それもこれも「DNS 制御権の所有者」であることを認証の軸としているからであって、当然の事として、その軸はしっかり守らないといけない、とは気の引き締まるところです。
この辺は、Let's Encrypt の問題ってわけではないとは思いますが。
DNS CAAレコード設定に意味はある？
サーバー証明書を第三者が勝手に発行できなくする仕組みである DNS CAA レコードですが、これに関しても、Let's Encrypt ではごく例外的なケースにおいて運用上の差が出てきそうな気がします。
例えば、DNS CAA レコードに書かれている認証局へ攻撃者が証明書発行依頼を掛ければ、手続き上、認証局側が「別の人物が証明書発行依頼を掛けてきた」と、異変に気が付くチャンスがあるわけです。
が、DNS の制御権が奪取されていない状態、かつ、何らかの方法で被害者サーバー上で Certbot を動かせてしまう状態だと、Let's Encrypt からは秘密鍵と証明書のペアを容易に入手できそうです。
もっとも、このパターンの話しになると、従来の有料認証局でもひょっとするとキーペアを入手できる機会があるかもなのですが、決済情報などで証拠が残りやすい分、Let's Encrypt では攻撃側の心理的ハードルが低い気がして。
もちろん、サーバー側に穴さえ無ければこんなことは起こらず、Let's Encrypt に問題がある、という話にもなりませんが、DNS やサーバーに対するセキュリティ意識を高めたくはなるなぁ、とは感じる部分ではあります。
ルート証明書のアップデート予定と互換性
当初心配していた対応ブラウザ・互換性ですが、これに関しては、モダンブラウザ以外の対応を切ってしまった「現時点では」心配いらなさそう、という判断になっています。
互換性に関する公式情報はこちら。
うちのサイト、ここ数年で古いブラウザからのアクセスはほとんど無くなったんですよねぇ。
ただし、2021年にルート証明書の切り替えが予定されており、それ以降、Android 7.1.1よりも古い端末では何らかの対策をしないといけない点は気がかりです。
とはいえ、当サイトの Android ユーザーの92%以上が現状でも Android 7.1.1 以降を利用しており、また、残りの8%以下についても、2021年までに一定の乗り換えが見込めること、また、それ以外のユーザーについても一部は Firefox への移行などで救済が見込めることから、実際のインパクトは数%程度になるのではないか、と見込んでいます。
他にも、Google のサイト認証などで「www.teradas.net」「teradas.net」の2つの SAN（Subject Alternative Name）を記述したいとか、色々な要件をクリアできたので、証明書の期限が切れそうになったこのタイミングで、Let's Encrypt に乗り換えてみました。
また、実際に問題が発生するようなら、何か書くかもしれません。
他にも、大量の証明書を発行してるけど、OCSP サーバーの応答速度は大丈夫なの？とかとか、色々と気になる部分はあるわけですが、そういう部分は追々分かってくるかなぁ、とか。
