ピニングとCA検証の違い

この記事は riku-kobayashi.jpに掲載した記事の転載です。

何を信用して、サーバーを本物と判断するのか

証明書チェーンの記事で書いたとおり、通常のクライアントはOSやブラウザに入っているルート証明書を信頼の起点にして、サーバー証明書の署名をたどって検証します。これがCA検証です。

信用しているのは、証明書そのものではなくCAの署名です。信頼しているCAが署名していて、ドメイン名が合っていて、有効期限内なら、初めて見る証明書でも通します。

ピニングは、これと信用の置き場所が違います。あらかじめこの証明書(あるいはこの公開鍵)だけを許可すると登録しておいて、サーバーが出してきた証明書がそれと一致するかを見ます。

CA検証は誰が保証したかを見ていて、ピニングはこれそのものかを見ている、という違いです。

サーバー証明書は、接続してきた相手に誰にでも渡す公開情報です。登録済みの証明書をコピーして提示しても、なりすましはできません。

TLSのハンドシェイクでは、サーバーが証明書の公開鍵に対応する秘密鍵を持っていることを署名で証明します。秘密鍵がなければここで失敗するので、証明書を知っているだけでは通りません。これはCA検証でもピニングでも同じです。

証明書を更新すると何が起きるか

違いがはっきり出るのは、更新のときです。

CA検証の場合

新しい証明書も、同じCAが署名したものです。署名をたどれば信頼できるCAに行き着くので、相手は何もしなくても通ります。

ピニングの場合

新しい証明書は、古いものとは別のデータです。事前に登録された内容と一致しないので、何もしないと接続は検証エラーで切れます。

これを避けるには、更新前に新しい証明書を相手に送って、登録し直してもらう必要があります。相手の作業が更新日に間に合わなければ、上の図のとおり止まります。

取引先が複数いて、そのうち何社かがピニングだと、更新のたびに誰に送ったか、誰が登録済みかを管理することになります。

公開鍵をピニングする場合

ピニングには、証明書全体を登録するやり方のほかに、公開鍵だけを登録するやり方があります¹。

証明書を更新しても、同じ鍵ペアのまま発行し直せば、公開鍵は変わりません。登録した内容と一致し続けるので、相手に再登録してもらわなくて済みます。

ただ、これにも限界があります。更新のたびに鍵を使い回し続けるのは、鍵の寿命の面で望ましくありません。OWASPも、同じ鍵ペアを推奨される期間を大きく超えて使うべきではないと書いています。

鍵を替えるときのために、次の鍵をあらかじめ登録しておくバックアップピンを用意するのが定石です。ただ、これもまた相手にあらかじめ登録してもらう手間が増える話です。

有効期間が短くなっていく

ここ数年で、更新の頻度そのものが変わりつつあります。

CA/Browser Forumの取り決めで、公開CAが発行するTLS証明書の最大有効期間は、段階的に短くなっています。

適用開始	最大有効期間
2026年3月15日	200日
2027年3月15日	100日
2029年3月15日	47日

47日になると、単純計算で年に7〜8回は更新することになります。

CA検証の相手なら、自動更新(ACME)に任せておけば済む話です。一方、証明書全体をピニングしている相手が多いと、更新のたびの送付と登録の依頼が年に何度も発生します。

ピニングの運用は、有効期間が短くなるほど、人手で回すのが厳しくなります。

それでもピニングが選ばれる理由

手間ばかり書いてきましたが、ピニングにも理由はあります。

• CAの誤発行や侵害に強い: CA検証は、信頼しているCAが署名した証明書なら通します。CAが誤って別人に証明書を発行したり、侵害されて偽の証明書が出回ったりすると、その偽物も通ります。ピニングなら、登録済みのものと違うので弾けます
• 相手が決まっている閉じた通信に向く: 取引先とのファイル受け渡しのように、接続先が最初から決まっている通信なら、公開CAの仕組みに頼らず、相手を直接限定できます
• 自己署名証明書でも信頼を作れる: 公開CAの証明書を使わない構成でも、あらかじめ証明書を渡しておくことで、サーバーを特定できます

相手側のセキュリティ要件として、ピニングが求められることもあります。その場合は、こちらが選べる話ではありません。

どちらを選ぶか

選べる立場なら、基本はCA検証だと思います。

ピニングが守るのは、CAが信頼できなくなったという、起きる確率が低い事態です。その見返りに、更新のたびの連絡と登録という、確実に毎回発生するコストを払います。有効期間が短くなる流れを考えると、この釣り合いは今後さらに悪くなります。OWASPも、公開CAを使う場合のピニングは、リスクのほうが大きいことがほとんどだと書いています。

ピニングを使う必要があるなら、次のあたりで運用負荷を下げられます。

• 証明書全体ではなく公開鍵を登録してもらう: 更新のたびに登録し直してもらう必要がなくなる
• 中間CAの証明書をピニングしてもらう: 同じ中間CAから発行される限り、サーバー証明書の更新は相手に影響しない。ただし、CAを変えたときは再登録が必要
• バックアップピンを最初から用意する: 鍵を替える日が来ても、登録が間に合わないという事態を避けられる

どれも、相手が対応してくれるかどうかに依存します。結局のところ、ピニングの運用コストは、ピニングを求めた側ではなく、証明書を更新する側に積み上がるのが一番の曲者です。

参照

• Certificate and Public Key Pinning | OWASP
• CA/Browser Forum's 47-Day Certificate Roadmap: Full Timeline to 2029 | SSL Insights

1. 正確には、証明書に含まれる公開鍵情報(SPKI)のハッシュ値を登録する方式が一般的です。 ↩