共同執筆: Jeremy Rowley

普通のウェブユーザーは、デジタルの世界を保護するために、その裏でどれほど多くの処理が実行されているかご存じないかもしれません。しかし、信頼できるウェブサイト、メール、サーバー、ソフトウェアは、認証局（CA）が発行する電子証明書があるからこそ、その信頼性が成り立っているのです。その CA の信頼性は、認証局/ブラウザ（CA/B）フォーラムなどの団体が定めている標準によって成り立っています。

ときには、人為的なミスやコード上のバグなどが原因で、発行された証明書がルートストアオペレーターの厳格な遵守要件を満たしていないことがあります。そうなった場合に CA は、起こったことを明確に伝え、その証明書を失効させたうえで、コミュニティがそのミスを教訓にできるよう努めると想定されています。

ところが、Google Chrome が Entrust 証明書を無効化した例でもわかるように、適切なタイミングで問題を解決し損ねると、多大な影響が生じかねません。CA にとっても、顧客にとってもです。

Google が Entrust 証明書を無効化した理由

2024 年 6 月、Google の Chrome セキュリティチームは、2024 年 11 月 1 日以降、Entrust が発行する TLS 証明書を信頼しない旨を発表しました。その数か月前に、Entrust は2 万 6000 件以上の EV TLS 証明書を誤って発行したと認めていました。

CA/B フォーラムのベースライン要件では、誤発行した証明書を失効させるタイムラインが定められていますが、これは問題の性質に応じて 24 時間以内または 5 日以内と、かなり短期間です。通常なら、各組織への影響を最小限に抑えながら CA が問題を是正できるのですが、Entrust は問題の証明書の失効または置き換えに向かう動きを何も見せませんでした。

そうした不履行があると、各組織では業務の停止、CA のステータスに関する不安、顧客からの信頼の喪失といった影響が生じる恐れがあります。Entrust のような CA が、誤発行した証明書の失効や置き換えをし損ねると、2024 年に Google がしたように、ウェブブラウザでその CA に対する信頼が損なわれるということです。

証明書の誤発行に伴うビジネス中断を企業はどう防ぐか

ソフトウェアにバグは付きものです。同じように、最新のソフトウェア開発ライフサイクルでは誤発行も起こります。そうなったとき、CA が第一に目指す目標は、どこでエラーが起こったかを特定し、その再発を防ぐことです。

2023 年にデジサートは、全世界のデバイスメーカーに向けて発行された 300 件の証明書が、CA/B フォーラムのベースライン要件で定められている厳格なプロファイル要件を遵守していないことを発見しました。その要件に従うと、各種標準へのコンプライアンスを保つには 5 日以内に問題の証明書を失効させる必要がありました。これは、公的に信頼される機関としての役割の一環として全 CA が合意している標準です。

ただ、問題がひとつありました。この点について顧客と協議したところ、証明書を 5 日以内で失効させるとなると、クリティカルなシステムが大規模に中断するため、消費者の安全性に影響することが明らかでした。デジサートは各メーカーと密接に協力し、誤発行された証明書の置き換えに 1 か月は必要だという結論に達しました。

CA/B フォーラムの規則に従わないという選択肢はありえませんが、新しい証明書を適切に発行しないまま、誤発行された証明書を失効させるというのも論外です。そこで私たちは、新しい証明書を期限内に発行して運用できるよう、コミュニティと話し合い、顧客とも 24 時間体制で協力しました。

関係各者には煩わしい事態でしたが、間違いが起こった経緯を振り返ったことで、誤発行された証明書が問題を引き起こし続けないよう顧客が対策を講じるための一助となりました。

証明書を安全に保つためのポイントとしてデジサートが推奨した内容は、以下のとおりです。

1. 適切な場合にはプライベートトラスト証明書を使用する。

CA/B フォーラムが標準を定めている対象は、パブリックトラスト証明書のみです。プライベートに信頼される証明書なら、5 日間という失効のタイムラインはありません。デバイスメーカーの顧客にしてみれば、必要のないもの―この場合はコネクテッドデバイス―にまでパブリックトラスト証明書を適用するのは、余計な問題が増える原因でしかありません。

デジサートのアドバイスとしては、証明書の使用状況を確認し、事足りるのであれば、トラスト証明書をパブリックからプライベートに変更して、失効によるビジネス中断のリスクを回避しましょう、と言えます。

プライベートトラスト証明書を使用する一般的なケースを以下に挙げます。

• コネクテッドデバイス: コネクテッド IoT デバイスは、ゲートウェイ、サーバー、アプリケーション、他のデバイスへの接続を手動で認証するときに証明書を使用します。このときの通信はプライベートネットワーク上で発生するのが普通なので、パブリックトラストは不要です。
• 内部アプリケーションとウェブサイト: パブリックなアクセスはないので、企業のイントラネットにパブリックトラストは必要ありません。
• 組織間の通信: パートナー組織は、相互のプライベート証明書を受け入れるよう各システムを手動で設定すれば、パブリックトラストを不要にできます。
• VPN: クライアントとサーバーの認証にプライベート証明書を使用すると、企業の VPN への接続は信頼されたデバイスに限定されます。

デジサートが公開している無料のオープンソース証明書リンター、pkilint を使い、証明書に対して自動のコンプライアンスチェックを実行するのもおすすめです。

2. 包括的な証明書管理ソリューションを導入する。

スプレッドシートを使って手動で証明書を管理している企業は、今でも少なくありません。証明書ライフサイクル管理（CLM）ソリューションを使えば、CA/B フォーラムが定める 5 日以内という期限に対応するのも不可能ではありません。一方、このソリューションがない状態で、誤発行された証明書を置き換えるには大がかりな手作業が発生し、完了までに数週間かかることもあります。

組織としてまだ包括的な CLM を使用していない場合は、DigiCert Trust Lifecycle Manager などのソリューションを導入しましょう。以下のような機能が用意されています。

• PKI 証明書の検出
• パブリックおよびプライベートのあらゆる証明書の完全なリポジトリ
• きめ細かな可視性と運用管理
• 証明書の失効を防ぐ通知
• 脆弱性への対策

デジタルトラストを優先する CA とのパートナーシップの重要性

デジサートが何度でもお伝えしているデジタルトラストとは、抽象的な概念ではありません。あくまでも客観的で、測定可能なものなのです。組織のウェブサイトとデジタル製品のなかには、信頼できる証明書によって保護されているものもあれば、保護されていないものもあります。CA/B フォーラムなどの団体によって定められた標準を遵守しているかどうかも、CA ごとに異なります。

CA が信頼のコミュニティへの参加に合意するとき、その信頼性を測る尺度は、規則に従おうとする意志と透明性です。誤発行のエラーも、それ自体で不信につながるわけではありません。問題の原因と、CA が問題から学んだこと、そして、CA の問題への対処方法。これらが特に重要なのです。

デジタルトラストに関する最新情報

証明書ライフサイクル管理、デジタルトラスト、デジサートのデジタルトラストソリューションなどのトピックについて詳しくお知りになりたい場合、記事を見逃さないようにデジサートのブログを参照してください。