Mutual TLSとはなにか
我々が例えばブラウザでウェブサイトを見るとき、接続先のサーバーが信頼できることを保証するためにHTTPSを使います。一方でサーバー側から見て接続してくるクライアントが信頼できることを保証するためにTLSクライアント認証という仕組みがあります。
これを同時にやることをMutual TLS(SSL)と呼びます。Mutualとは相互という意味です。
これは公式な定義がない用語ではありますが、結構広く使われているようです。
これから数回に分けてNginxを題材にMutual TLS設定の話を書いて行こうと思います。
ですがHTTPSについてはほとんど説明しません。なぜならHTTPSサーバーの設定についての記事は世の中に多く存在するためです。畢竟、TLSクライアント認証に関する話題がほとんどとなる予定です。
仕組みについては適宜記述しますが、どちらかというと設定の話がメインです。
Mutual TLSで用意するもの
Mutual TLSで必要なものは多いので、以下にまとめておきます。
登場人物としては、HTTPSサーバー、認証局、クライアントの三者です。
このうちHTTPSサーバーと認証局の運営者は同一です。
サーバーは当然オンラインでなければありませんが、認証局についてはオンラインである必要はまったくありません。
むしろ安全のためにはオフラインであるべきでしょう。
なおサーバー上にはクライアント認証用の秘密鍵は置かれません。
サーバー & 認証局
- HTTPSに必要なもの (割愛。証明書の発行者はクライアント証明書と異なってよい)
- クライアント証明書用認証局
- root認証局
- root認証局秘密鍵(自身を含むサブ認証局を作るため使用する)
- root認証局証明書(オレオレでもよい。というかオレオレ)
- sub認証局
- sub認証局秘密鍵(クライアント証明書署名用。サーバーには置かない)
- sub認証局証明書(root認証局で署名する)
- sub - rootのchained証明書 (サーバーに置く)
- root認証局
クライアント側
- 秘密鍵(CSR作成と接続時に利用する。サーバー側にも送ってはならない)
- 証明書署名要求(CSR)
- これを認証局に送り証明書を作ってもらう
- CSRを元に認証局で作られたクライアント証明書(接続時に利用する)
オレオレ認証局でよいのか？
クライアント証明書のための認証局のroot証明書がオレオレでいいのか？という疑問があるかもしれませんが、この認証局はサーバーがクライアントを認証するためのものです。つまり「サーバー & 認証局」から見て、正当性を確保できればよいためオレオレで問題ありません。サーバー側を証明するためのHTTPSとは異なることに注意してください。
つまりMutual TLSにおいてはサーバ証明書の発行者と、クライアント証明書の発行者は別でもよいということになります。
ただしHTTPSを終端しているもの(今回はNginx)が、クライアントの認証を行う必要はあります。
Basic認証との比較
よい点
Basic認証の場合、サーバー側が認証情報を全部保持しているため、クライアントになりすますことが可能です。
TLSクライアント認証の場合、サーバー側はクライアントの秘密鍵を知らないため、なりすますことは不可能です。
よくない点
「用意するもの」を見てわかる通り、非常に複雑です。とりあえず立ててつなぎたいレベルだと面倒すぎます。
またこれはサーバー側だけでなく、クライアント側も同様で、秘密鍵とCSRを作ってもらったり鍵の管理をしてもらったりと、相手側の情報管理能力が高くないと事実上運用不可能でしょう。
まとめ
Mutual TLSは、ざっくり言うと「HTTPS + TLSクライアント認証」です。
次回はクライアント証明書の認証局を作ります。
果たしてこのシリーズは完結するのか。