はじめに
PKIについて今まで雰囲気で抑えていた部分を簡単に整理した記事です。
PKIがないと何が問題なのか
サーバが送ってきた公開鍵が本当に通信したいサーバのものであるかを確認することができません。
今通信している相手がサーバAだとして、「本当にその相手がサーバAであること」をどうやって保証するかというお話です。
PKIの仕組み
要はサーバAが送ってくる公開鍵が「本当にサーバAのものですよー」と誰かに証明してもらえればいいわけです。
その役割を担うのが 認証局(CA) です。
CAはデジタル証明書を発行し、証明書の中に公開鍵とCAによる署名を付与します。
これによってクライアントはCAの署名を検証することで、この公開鍵は本当にそのサーバのものであることを確認できます。
他の例だとマイナンバーカードを用いた本人確認(JPKI)も同じ仕組みです。
マイナンバーカードにある個々人の秘密鍵で署名した後、デジタル証明書(署名用電子証明書)をサーバが受け取り、署名用電子証明書にあるCA(J-LIS)の署名を検証することで本人の公開鍵であることが保証され、その公開鍵で署名値を検証することで本人の署名であることが担保されます。（実際にはこれに加え、証明書が失効していないかの確認なども行われます）
CAの公開鍵は信頼していいの？
PKIは公開鍵の真正性を担保する仕組みです。それはCAの署名を検証することで保証されます。ただこのときCAの公開鍵は無責任に信頼していいのでしょうか？もちろんCAの公開鍵も同様により上位のCAによって署名されています。そして最終的にルートCAにたどり着き、ルートCAの証明書はOSやブラウザにあらかじめ「信頼された証明書」として組み込まれています。（トラストストア／トラストアンカー）これなんというか、すごい。
個人でアプリデプロイしたときそんな設定したっけ...
実は、多くの場合すでに裏側で設定は完了しています。
Vercelなどのホスティングサービスを使う場合、無料の認証局であるLet's Encryptによってデジタル証明書が作成されます。Let's EncryptはACMEというプロトコルに基づき、証明書の発行・更新を完全自動化しています。
流れはざっくり以下の通りです。
- ホスティング側が、そのドメインを本当に自分が管理しているかをHTTPまたはDNSのチャレンジで証明する
- Let's EncryptのCAがこのドメイン所有を確認し、サーバ証明書を自動発行する
参考：VercelとLet's Encryptによる自動SSL化
おまけ
HTTPS通信が開始されるまでの流れ