証明書のピン留めは、特定のWebサイトで有効と見なされる証明書を限定し、リスクを制限します。パブリック証明書ならどれでも使えるようにするのではなく、運用者は発行認証局（ CA ）、公開鍵証明書のピン留めは、特定のWebサイトで有効と見なされる証明書を限定し、リスクを制限します。または選択したエンドエンティティ証明書さえも「固定」します。そのサーバーに接続するクライアントは、他のすべての証明書を無効として扱い、HTTPS接続の確立を拒否します。
ピン留めにより、Webサイトは誤発行、 認証局の危殆化、中間者攻撃のリスクに対してコントロールが可能になります。ピン留めは、ユースケースに応じていくつかのやり方があります。クライアント機器のトラストストア内で唯一利用可能な証明書としてピン留めしたり、公開鍵ハッシュをコードに書き込んで、自分の鍵だけが信頼されるようにすることもできます。ピン留めが一般的になり始めたときには、複雑さを追加する過程が加わることで、悪意のある攻撃者が攻撃やなりすましに証明書を悪用することが困難になると期待されていました。
Googleは、2011年（英語リンク）にChromeブラウザでメインWebサイトの発行認証局をピン留めしたことで、最初にピン留めを利用し始めた例の1つとなりました。Chromeがgoogle.comに接続したとき、信頼される発行認証局はどこか明らかでした。もし他の認証局からの証明書が提示された場合、接続はブラウザによりブロックされます。これは、攻撃者が他の認証局をだましてgoogle.comの証明書を取得したとしても、Chromeによりブロックされることを意味します。
数年後、Chrome（英語リンク）とFirefoxはサイトがHTTP公開鍵ピンニング拡張（HPKP）ヘッダーを使用できるようにしました。ブラウザが初めてHPKPを使用してWebサイトに接続したとき、ヘッダーから公開鍵が記録され、HPKPポリシーで定義された「max-age」まで、サイトに接続するたびにその鍵のみを受け入れます。60日の最大経過時間が設定されている場合、他の鍵は次の60日間受け入れられません。
その間、証明書のピン留めは、アプリ、IoTデバイスやその他のソフトウェアにも利用され始めました。同様の方法を使用してアプリは証明書をピン留めすることができ、その証明書を使用していない場合、アプリはサーバーへのすべての接続を拒否することで、中間者攻撃からユーザーを保護します。
これらの施策は正しく実装すると、セキュリティは強化されますが、ピン留めがそれほど優れたアイデアではないことをWebコミュニティが知るまでに時間がかかりませんでした。
特にHPKPを使用したピン留めは、非常に危険でエラーが発生しやすかったと言えます。ピン留め設定を間違ってしまった場合、なんの対策もできないまま、自らのWebサイトへのアクセスがブロックされたり、アプリケーションの接続が切断されることになります。以下は、ピン留めがそのような害を及ぼす可能性があるいくつかのシナリオです。
HPKPの一般的な方法は、エンドエンティティ証明書の公開鍵をWebサイトに60日間固定することでした。多くのサイトでは、オプションであることを知らなかったためか、単一のキーを使用するリスクを過小評価していたためか、バックアップキーを指定していませんでした。
これにより、サイトはキーの侵害に対して脆弱になります。業界標準では、認証局は危殆化した＝危険にさらされた証明書（安全でないWebサーバーから盗まれた、もしくは誤って公開GitHubリポジトリにアップロードされた）を24時間以内に取り消すことが求められています。固定された唯一のキーが侵害された場合、代替はなく、HPKPポリシーを記録したクライアントはその不正な鍵しか利用できず、新しく発行した証明書との接続は許可されません。
HPKPは、ハッカーがWebサイトを妨害し、長期的な被害を与える簡単な方法です。サーバーを乗っ取り、偽のHPKPポリシーを偽のキーによって最大有効期間1年間と設定したとします。ブラウザーは接続に失敗する事になってしまいます。サーバーへの権限を取り戻した後も、修正が容易ではないHPKPポリシーの影響が残ります。
認証局が証明書を取り消す必要が発生することがあります。監査により、サブジェクト名の記述ミスやOUフィールドの無効なエントリなど、証明書に以前では認識されていなかった問題が見つかることがあります。業界標準では、 認証局は証明書を失効させるのに5日間が必要ですが、クライアントのコードはそれらを固定したままです。5日間以内にすべてのクライアント機器に更新をプッシュして、新たに交換した証明書の使用を開始するにはどうすればよいのでしょうか？
これらの問題に加え、安全かつ確実にピン留めを実装することの難しさから、サイトの保護よりもピン留めにより弊害が起こるケースが増えてきました。これらを含む多くの問題が見つかり、やがてGoogleとFirefoxはHPKP導入後わずか数年後にサポートをやめることになりました。
ピン留めの最大の課題は、証明書に問題があった場合に柔軟に対応できなくなることです。何らかの理由で鍵、証明書、発行者、発行認証局を変更する必要がある場合は、クライアント機器、ブラウザー、ソフトウェア、IoTデバイスなども修正する必要があります。それらは時として非常に短い期間で行われる必要がありました。アプリケーションが何年にもわたってバージョンサポートされるとして、それがピン留めされた証明書を含んでいる場合、証明書がアプリケーションの耐用年数を通して有効であるかは疑問です。パブリックで信頼されるTLS/SSLサーバ証明書は常に新たなルールに準拠する必要があるため、ピン留めは特に問題となりえます。
幸いなことに、HPKPは過去のものであり、DigiCertはいかなる種類の公開鍵固定も支持していません。DigiCertでは、証明書の固定・ピン留めを行わないことをお勧めします。複雑さ及びエラーの回避がピン留めのメリットよりも上回ります。
近年、証明書利用者にピン留めを実装することを推奨または指示していませんが、ご自身でピン留めを設定することは可能です。先日、DigiCertは認証局階層に変更を加えました。パブリックTLSを発行する中間CA証明書（ICA）を従来より短い、6か月ごとに更新されるよう変更します。もちろん、中間CA証明書自体の有効期間は、そのICAが使用される6か月間に発行されたすべての1年・2年証明書の有効期間を超えた十分な長さに設定します。ICAの利用期間が短くなり頻繁に変更されることになるため、それらを固定することができなくなります。
私たちは初めに、ドメイン認証（DV）証明書用のジオトラストRSA CA2018中間CA証明書とRapidSSL RSA CA 2018中間CA証明書を、それぞれ新たなジオトラストTLS DV RSA Mixed SHA256 2020 CA-1 とand RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1へ置き換えます。6か月後、これらはジオトラスト TLS DV RSA Mixed SHA256 2021 CA-1とRapidSSL TLS DV RSA Mixed SHA256 2021 CA-1に置き換えられ、6か月後、* 2021 CA-2バージョンという形に継続して更新してゆきます。
デフォルトのすべてのパブリックTLS Issuerが6か月ごとに全て置き換えられるまで、今後数か月をかけて行う計画です。これらの変更のスケジュールはここに掲載されます（英語リンク）。
全てのピン留めを終わらせ、ICAの利用期間を短縮することには他の利点があります。証明書をより小さくグループ化するため、1つの認証局の下で発行された一連の証明書へ変更が加わったとしても、他の証明書に影響を与えません。もしICAを廃止するような事態が発生した場合、認証局が発行していた6か月間に発行された証明書と、その認証局で許可された特定の種類の証明書のみが影響範囲となります。
・SSLサーバー証明書
・コードサイニング
その他証明書
・バウチャ(クーポン)
