Let’s EncryptとACME
2018年07月25日 水曜日
2018年7月はWeb業界にとって記憶に残る日になるでしょう。httpsが標準となった日として。
これまでWebサイトへのアクセスにはhttpを利用するのが通常で、安全性が求められる場合にはhttpsを利用すると考えられてきましたが、これからはhttpsを使うのが当たり前になっていくでしょう。この流れを強力にけん引しているのは、保守的な我が国においてもトップシェアブラウザとなったChromeを擁するGoogleであることはご存知の通りです。これまではhttpでのアクセスには特に表記はなく、httpsでアクセスすると「保護された通信」と表示されていましたが、2018年7月リリースのChrome 68からはhttpでのアクセス時には「保護されていない通信」と警告が表示され、httpsでのアクセス時には特に何も表示されないように変更されます。さらにその先のリリースでは、httpでのアクセス時にフォームが存在していると警告が赤字表記に変わることが予定されているなど、もはや常時TLS化は常識となるわけです。
（https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.htmlから引用）
この方針は2018年2月に示されていたため、多くのサイトではすでにhttps対応が進んでいますが、小規模なサイトではコストなどの問題から未対応のままこの日を迎えるところも少なくないようです。そんな中Let’s Encryptのように無償でサーバ証明書を発行するサービスが立ち上がり注目を集めています。また、AWSは自社クラウド内での利用に限られるとはいえ、やはり無償でサーバ証明書を提供しています。今まで費用をかけて証明書という信用を買っていたのでは？と思うと、利用に踏み切ってよいものか迷うところではないでしょうか。
本稿でこうした無償のサーバ証明書が登場した背景と現状についてお話しします。
少し前の話になりますが、CA/Browserフォーラム（主にGoogle）に不適切な証明書発行業務を指摘され、不信任を突き付けられた挙句に証明書ビジネスを事業譲渡することになったSymantec社の件はご存じの方も多いでしょう。元とはいえ証明書ビジネスにおいてトップブランドの一つであったVeriSign社を引き継ぐ事業がこんな展開になったことに驚いた方も多かったのではないでしょうか。
https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html
Googleからは完全にダメ出しされたSymantec社ですが、エンドユーザーの立場から見てSymantec社とLet’s Encryptのサーバ証明書を比較して、より信用できると感じるのはどちらでしょう？おそらく多くの方が前者のSymantec社を挙げるのではないでしょうか。しかし、CA/Browerフォーラムのメンバー、つまりGoogle, Microsoft, Apple, Mozilla, etcによれば、後者の方が信用できるということになります。何せOSやブラウザの証明書ストアにはLet’s EncryptのCA証明書がデフォルトで提供されており、そこで発行されたサーバ証明書はごく一般的に利用できるのですから。ブラウザにデフォルトでCA証明書がインストールされるということは、信用の連鎖の元締めとしての役割が任されるということですから、大変なことです。
ただ、その信用レベルには各社の間に温度差があるのかもしれません。AppleやMozillaはLet’s Encryptを直接ルートCAとして信用していますが、MicrosoftはLet’s Encryptを中間CAとして捉えて、そのIssuerであるDST社のルートCAのみ信用している状態になっています（これは今後変わるのかもしれません）。なお、Chromeは各OSの証明書ストアに依存しているので、どちらでもありません（Androidは別として）。Let’s Encryptに漠然とした不安を感じる気持ちは自分にもありますが、 Symantec社へ断固たる決意を示したCA/BrowserフォーラムがLet’s Encryptを支持している姿勢を見るにつけ、そろそろ考え方を見直す時期が来ているのではと感じます。
とはいえ、信用を勝ち取るにはどうしても確かな素性や実績が求められるため、すぐに信用されるのは難しいかもしれません。ですが、純粋にエンジニア的な視点ではまったく見方が違います。Let’s Encryptのようなサービスを積極的に採用する明確な理由があります。
Let’s Ecnryptの証明書発行プロセスはACME（Automatic Certificate Management Environment）としてIETFへ提案され、現在Proposed Standardの段階で評価中です。つまり、Let’s Encryptの証明書発行システムはプロプライエタリなものではなく、今後サーバ証明書の標準的な発行プロトコルとなって、同種のサービスが複数立ち上がる可能性があるということです。また、現在提供されているサービスはACMEのリファレンス実装としての役割を担っているということでもあります。
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
こうして標準規格として仕様がまとまるということは、前述したような不適切な発行を避けやすい透明性の高いプロセスでサーバ証明書が発行されるということです。仮に問題があってもそれに気づくことができます。実際にLet’s Encryptのサービス提供が始まってからのことですが、同一IPアドレスで複数のServerNameが同居している環境における脆弱性が指摘され、一部のチャレンジタイプ（TLS-SNI-01）が無効化されました。疑うわけではありません、プロプライエタリなブラックボックスの中で発行された証明書に同様の問題があった時、どのような対応がなされただろうかと考えてしまいます。CA/Browserフォーラムが重視し、信用しているのは、こうした高い透明性と迅速な対応が行われる運営体制なのではないでしょうか。
また、ACMEを採用すると単純に楽です。何しろACMEの認証フローは完全に自動化可能です。キーペアの作成、CSRの提出、証明書の発行、システムへのインストール、すべてが全自動で可能です。一番面倒でトラブルになりやすい証明書の更新も無人で問題ありません。実際に弊社の一部システムではすでにサーバ証明書のことは構築プロセスにありません。システムが勝手にやるので考える必要がないのです。今後httpsが常識となれば、サーバ証明書の維持管理業務が重くなることは容易に想像されるため、ACMEであるかどうかにかかわらず自動化の工夫は不可避といえるでしょう。
まだサーバ、クライアント双方で環境が整備されているとはいいがたい状況ですが、それでもWebサーバやロードバランサを中心にACMEクライアントの実装が広がりつつあります。ここでは具体的なプロダクトは取り上げませんが、興味があれば調べてみてください。環境が整備されてきたら、信用とスピード、安定性、コストのバランスを考えて、導入の是非を検討されることをお勧めします。
ところで、ACMEによって発行されるサーバ証明書はDV証明書と呼ばれるドメイン認証が行われる証明書です。EV証明書はまた別の話がありますので、そこは混同しないようにお願いします。証明書には確かもう一種類あったはずなのですが、最近利用していないもので忘れてしまいました。なんでしたっけ？
