次の方法で共有

Microsoft Edge ブラウザーの TLS サーバー証明書検証の変更

  • [アーティクル]

注

Microsoft Edge for Business が Edge 安定バージョン 116 で利用可能になりました。 エンタープライズ レベルのネイティブ セキュリティ、生産性、管理容易性、AI が組み込まれた新しい専用のワーク エクスペリエンスについて説明します。

Microsoft Edge が HTTPS サーバーへの接続を確立すると、Edge は、サーバーがブラウザーによって信頼されたエンティティによって発行された証明書を提示したことを確認します。 この信頼関係は 証明書信頼リスト を介して確立され、チェックの実行を担当するコンポーネントは 証明書検証ツールと呼ばれます。

Microsoft Edge の以前のバージョンでは、既定の証明書信頼リストと証明書検証ツール ロジックの両方が、基になるオペレーティング システム (OS) プラットフォームによって提供されていました。

Windows と macOS の Microsoft Edge 112 以降のマネージド デバイスの場合、既定の証明書信頼リストと証明書検証ツールの両方がブラウザーによって提供され、ブラウザーに付属しています。 この方法では、既定の検証動作のために、リストと検証ツールをホスト オペレーティング システムのルート ストアから切り離します。 変更のタイミングの詳細については、 ロールアウトタイムラインとテストガイダンス を参照してください。

変更後も、Microsoft Edge に付属する組み込みのルートを信頼するだけでなく、ブラウザーは、ユーザーや企業がインストールしたローカルにインストールされたルートについて、基になるプラットフォームと信頼に対してクエリを実行します。 その結果、ユーザーまたは企業がホスト オペレーティング システムのルート ストアにさらにルートをインストールしたシナリオは引き続き機能する必要があります。

この変更は、Windows と macOS の Microsoft Edge で証明書検証ロジックが一貫して機能することを意味します。 今後決定されるリリースでは、ロールアウトは Linux と Android にも適用されます。 Apple App Store ポリシーにより、Apple が提供するルート ストアと証明書検証ツールは引き続き iOS と iPadOS で使用されます。

既定の証明書信頼リスト ソース

Windows および macOS 上の Microsoft Edge に付属するルート ストアは、 Microsoft 信頼されたルート証明書プログラムによって定義された証明書信頼リスト (CTL) から取得されます。 このルート証明書プログラムは、Microsoft Windows に付属するリストを定義します。 その結果、ユーザーに表示される変更は表示されません。

macOS では、プラットフォームによって信頼されているが、Microsoft の信頼されたルート証明書プログラムによって信頼されていないルート証明書によって発行された証明書の場合、証明書は信頼されなくなります。 ほとんどのサーバーは、使用する TLS 証明書が Microsoft Windows によって信頼されていることを既に確認しているため、この信頼の欠如は一般的な状況になるとは考えられません。

更新プログラムは、Microsoft 信頼されたルート プログラムの リリース ノート に記載されている間隔でリリースされます。

ロールアウト タイムラインとテスト ガイダンス

Microsoft Edge 109 以降では、エンタープライズ ポリシー (MicrosoftRootStoreEnabled) と edge://flags のフラグ ("Microsoft ルート ストア") を使用して、組み込みのルート ストアと証明書検証ツールを使用するタイミングを制御できます。

企業が管理していないデバイスは、Microsoft Edge 109 の制御された機能ロールアウト (CFR) を介して機能の受信を開始し、Edge 111 で管理されていないデバイスの 100% に達しました。 詳細については、「 Microsoft Edge の構成と実験」を参照してください。Microsoft Edge の CFR のしくみについて説明します。 エンタープライズ管理デバイスの場合、既存のプラットフォーム提供の実装は Microsoft Edge 111 を通じて使用されました。

Microsoft Edge 112 以降では、エンタープライズ管理デバイスを含むすべての Windows デバイスと macOS デバイスの既定値が、ブラウザーに付属する検証ツールの実装と CTL を使用するように変更されました。 MicrosoftRootStoreEnabled ポリシーは引き続きこのリリースで使用でき、予期しない問題が見つかった場合に企業が以前の動作に戻し、問題を Microsoft に報告できるようにします。

Microsoft では、互換性の問題を事前に特定して Microsoft に報告するために、Microsoft CTL ではなくルートによって発行された TLS サーバー証明書に関連するプロキシやその他のシナリオを中断して検査する企業をお勧めします。

Microsoft Edge 115 では、 MicrosoftRootStoreEnabled ポリシーのサポートが削除されます。

Windows でのローカルで信頼された証明書の動作に関する既知の違い

RFC 5280 のコンプライアンスの厳格

新しい組み込みの証明書検証ツールは、以前のプラットフォーム ベースの検証ツールよりも RFC 5280 の要件を適用する場合の方が厳しくなります。

RFC 5280 コンプライアンスの厳格化の例を次に示します。

  1. ECDSA アルゴリズムのアルゴリズム パラメーターは存在しない必要があります。 古い検証ツールはパラメーターを無視し、新しい検証ツールは証明書を拒否します。 詳細については、「 Chromium issue 1453441 」を参照してください。
  2. IP アドレスを指定する名前制約には、IPv4 アドレスの場合は 8 オクテット、IPv6 アドレスの場合は 32 オクテットが含まれている必要があります。 証明書で空の IP アドレスが指定されている場合は、証明書を再発行し、IP アドレス名の制約を完全に省略する必要があります。
  3. "除外" リストが空の名前制約が無効です。 Windows 証明書ビューアーは、この一覧をName Constraintsの詳細内のExcluded=Noneとして表示します。 詳細については、「 Chromium issue 1457348 」を参照してください。 空のリストを指定する代わりに、完全に省略します。

Windows での既知の失効チェック動作の違い

より厳しい RFC 5280 要件に加えて、新しい検証ツールでは LDAP ベースの証明書失効リスト (CRL) URI はサポート されていません 。

企業が RequireOnlineRevocationChecksForLocalAnchors ポリシーを有効にしていて、RFC 5280 ごとに CRL が有効でない場合、環境で ERR_CERT_NO_REVOCATION_MECHANISM や ERR_CERT_UNABLE_TO_CHECK_REVOCATION エラーが表示され始める可能性があります。

ERR_CERT_NO_REVOCATION_MECHANISMが発生した場合は、証明書で指定された URI の CRL が、(PEM でエンコードされていない) DER でエンコードされた応答を返していることを確認する必要があります。

関連項目