パスワードはもう時代遅れです。あなたのネットワークは、パスワードに代わるシステムへの準備はできていますか？
貴社は長年、ファイアウォール、VPN、多要素認証、エンドポイント保護など、正面玄関のセキュリティ対策に力を注いできました。しかし、多くのITチームがまだ完全には答えを出せていない、より静かな疑問があります。それは、デバイス、サーバー、またはサービスが認証を試みる際に、 それは、それが主張する通りのものですでは、その主張を裏付ける根拠は実際にあるのでしょうか？
多くの組織にとって、正直なところ「パスワード」または「APIキー」が解決策となるでしょう。しかし、どちらも盗まれたり、フィッシング詐欺に遭ったり、入手した者によって悪用される可能性があります。
より良い解決策があり、それは現在ブラウザやルート権限が必要なプログラムが事実上要求しているものです。それは、専用のクライアント認証証明書です。
なぜこれが急に緊急になったのか
この問題を引き起こした変更点は以下のとおりです。2026年6月15日以降、Chromeのルートプログラムは新たに発行された公開信頼済みライセンスを必要とします。 TLS サーバー証明書には serverAuth EKU のみを含めるようにします。Mozilla、Apple、Microsoft は互換性のあるルート プログラム ポリシーを採用し、公開されている信頼できる証明書での clientAuth EKU の使用を終了しました。 TLS サーバー証明書。
組織が標準を再利用していた場合 TLS クライアント認証も処理する証明書、または 相互 TLS (mTLS)そのため、そのショートカットはもはや機能しません。サーバーとクライアントの両方のIDとして機能していた二重目的の証明書は、クライアント認証にはもはや有効ではなく、SSLが提供する、その目的のために特別に作成された証明書に置き換える必要があります。
古い二重目的証明書に依然として依存している組織は、今日すでにコンプライアンス違反の状態にあり、対処されないまま放置される期間が長くなるほど、リスクは増大する一方です。これは、証明書ベースの認証を使用しているすべての人に影響します。TLSゼロトラストアクセス、VPN、Wi-Fiネットワークアクセス、IoTデバイス、産業制御システム、またはエネルギー市場プラットフォーム。
クライアント認証証明書の実際の機能
普段のことを考えてみてください TLS 証明書は、サーバーのIDバッジのようなものです。ブラウザがサーバーに接続した際に、サーバーが主張する通りのサーバーであることを証明します。クライアント認証証明書は、この仕組みを逆転させます。デバイス、ユーザー、サーバー、またはサービスが、接続先に対して自身の身元を証明できるようにします。
ここでは仕組みが重要ですが、それはビジネスにとっての意味合いが重要だからです。秘密鍵はデバイス上で生成され、決して外部に漏れることはありません。公的に信頼されている認証局（SSLなど）は、公開鍵にのみ署名し、検証済みのIDと紐付けます。つまり、どこかのデータベースにフィッシングの標的となるパスワードが保存されることも、情報漏洩で流出する共有シークレットも、ローテーションを忘れたスクリプトにコピーされたAPIキーも存在しないということです。
証明書の失効は、フリート全体ではなく、証明書ごとに適用されます。ノートパソコンが紛失した場合、請負業者のアクセス権が終了した場合、またはデバイスが侵害された場合は、該当する証明書を1つ失効させるだけで、他のすべてのエンドポイントは中断なく動作し続けます。
主なメリットの概要
専用のクライアント認証証明書に切り替えることで、実際に得られるメリットは以下のとおりです。
- フィッシング対策済みの本人確認情報。 秘密鍵はデバイスから外部に持ち出されないため、盗まれたり、リプレイ攻撃やフィッシング攻撃の対象となるパスワードは存在しません。
- Chromeおよびルートプログラムに対応しています。 CA/Browser Forumおよびルートストアの要件を満たす専用のclientAuth EKUにより、この問題の発端となったポリシー変更による影響を回避できます。
- 公的に信頼されている階層構造。 SSLのWebTrust監査済み公開サイトより発行 PKIプライベートルートをリライングパーティスタック全体に配布する必要はありません。
- 検証レベルは3段階。 IV、OV、およびIV+OV（スポンサー）に対応しているため、認証情報は貴社の本人確認ポリシーおよび貴社が従うべき規制要件に適合します。
- きめ細かな取り消し。 デバイスの紛失、廃止、または侵害が発生した時点で、他のデバイスに影響を与えることなく、単一の証明書を失効させることができます。
- APIファーストの発行。 SSLのREST APIを通じて現在大規模な問題解決が可能であり、ACMEおよびSCEP/ESTによる自動化も今後導入予定です。
認証情報をユースケースに合わせる
個人認証（IV）は、指定された人物の実在性を確認するため、従業員のデバイス、BYODポリシー、および個人のエンドポイントアクセスに最適です。組織認証（OV）は、企業の法的存在を確認するため、サーバー、仮想マシン、サービスアカウント、およびAPIクライアントに必要となります。特権ユーザー、契約社員、規制対象業界など、両方の認証が必要な状況では、IV+OV（スポンサー認証）が利用できます。これは、個人の身元をスポンサー組織に同時に紐付けるものです。
クライアント認証は、多くの人が想像する以上に多くの場面で使われているため、その柔軟性は重要です。
|
Use Case |
認定レベル |
と互換性 |
Notes |
|
mTLS ゼロトラスト |
OV / IV+OV |
Nginx、Envoy、Istio、Kong、AWS API GW |
相互 TLS両方のピアはX.509で認証します。 |
|
VPN（証明書ベース） |
IV / OV / IV+OV |
Cisco ASA/FTD、Palo Alto、Fortinet、Juniper SRX |
パスワードベースのVPNを排除。フィッシング対策済み。 |
|
Wi-Fi (802.1X / EAP-TLS) |
IV / OV |
Cisco ISE、Aruba ClearPass、Microsoft NPS |
NACの適用；認証情報はデバイス上にあり、パスワードには含まれない |
|
IoT / デバイス識別 |
OV |
AWS IoT Core、Azure IoT Hub、カスタムブローカー |
デバイスごとの証明書。フリート全体の再フラッシュなしで個別に失効可能。 |
|
OT / SCADA / ICS |
OV |
Claroty、Nozomi、Dragos；IEC 62443対応スタック |
OTネットワーク上のPLC、HMI、ヒストリアンノードを認証します。 |
|
NAESBエネルギー市場 |
IV+OV |
NAESB WEQ-12 準拠のプラットフォーム |
OATI、PowerSecure、およびその他のEISプラットフォームに必要な認証情報 |
|
APIゲートウェイ認証 |
OV / IV+OV |
Apigee、Kong、AWS API GW、Azure APIM |
APIキーとJWTを証明書に紐づいたサービスIDに置き換えます |
これらの具体的な使用例に加えて、証明書はチームが既に運用しているインフラストラクチャ全体で幅広く機能します。
- TLS スタック: OpenSSL、BoringSSL、NSS、SChannel、SecureTransport、wolfSSL、mbedTLS.
- VPNとリモートアクセス： Cisco AnyConnect/SecureClient、Palo Alto GlobalProtect、Fortinet FortiClient、OpenVPN、およびWireGuard（外部認証経由）。
- NACと802.1X： Cisco ISE、Aruba ClearPass、Microsoft NPS/RADIUS、FreeRADIUS、およびJuniper Access Control。
- API ゲートウェイ: Kong、Nginx、Envoy、Istio、AWS API Gateway (mTLSAzure API Management、およびApigee。
- ICSとOT： Claroty、Nozomi Networks、Dragosなどの資産検出および認証レイヤーを含む、IEC 62443に対応したプラットフォーム。
証明書の発行
組織がどのような方法で証明書を発行することを好むかにかかわらず、SSLにはそれに適した方法があります。
|
方法 |
対象者 |
仕組み |
|
ウェブUI（ssl.comダッシュボード） |
IT管理者、小規模な導入、単発発行 |
ssl.comにログインし、「クライアント認証」を選択し、検証レベルを選択して検証を完了し、証明書を生成してダウンロードしてください。コーディングは不要です。 |
|
REST API |
DevOps、CI/CDパイプライン、大規模フリートプロビジョニング |
プログラムによる証明書の発注、 CSR SSLのドキュメント化されたREST APIを介して送信およびダウンロードが可能です。一括発行とオーケストレーションプラットフォームとの統合をサポートします。 |
|
ACME / SCEP / EST |
エンタープライズMDM、IETF標準準拠の自動化（計画中） |
ACME（RFC 8555）、SCEP、およびEST（RFC 7030）を介したプロトコルベースのライフサイクル自動化。現在開発中です。開発スケジュールおよび早期アクセスに関する詳細は、営業担当までお問い合わせください。 |
購入方法
クライアント認証証明書は、最低契約期間の制限なく、SSLから直接入手できます。
- セルフサービス。 オンラインで設定して購入する.
- 企業規模と販売量。 SSL営業チームにお問い合わせください ボリューム価格、専任アカウント管理、 なべ- 特定のオンボーディング。
- プライベート階層またはデュアルEKUのニーズ。 プライベート階層、カスタム証明書プロファイル、またはデュアルEKU証明書が必要な場合は、 SSLのプライベート PKI 製品 (高保証プライベート証明書、専用 PKI、そしてエンタープライズ PKI）が正しい手順です。紹介をご希望の場合は、営業担当までお問い合わせください。
ボトムライン
clientAuth EKUの変更は、単なる技術的な注釈ではありませんでした。それは、組織がサーバーIDとクライアントIDを最終的に分離し、パスワードやAPIキーをフィッシングやリプレイ攻撃に利用できないものに置き換えるよう促す、強制的な機能だったのです。
SSLは20年以上にわたり、WebTrustの監査を受けた公開認証局を運営しており、クライアント認証証明書は、ゼロトラストネットワーク、IoTデバイスの群、NAESB規制対象の取引プラットフォームなど、大規模な専用クライアントIDを必要とするあらゆる組織にとって、直接的かつコンプライアンスに準拠した解決策となります。
現在の設定がまだ二重目的証明書に依存しているかどうか不明な場合は、今すぐ確認してください。施行日は既に過ぎているため、そのギャップを埋めることはもはや選択肢ではなく必須事項ですが、弊社がお手伝いいたします。
あなたのmはTLS clientAuth EKU の削除によって影響を受けていますか？ clientAuth EKU について証明書を監査し、その後 SSL に連絡して専用のクライアント認証証明書 (またはプライベート証明書) への移行について相談してください。 PKI 現在の証明書の有効期限が切れる前に、内部専用/デュアルEKUのニーズに合わせて:
