Microsoft が、その独自の判断で、使用法または属性が信頼されたルート プログラムの目的に反していると判断される証明書を特定した場合、Microsoft は責任を担う CA に通知し、証明書の失効を要求します。 CA は、Microsoft の通知を受け取ってから 24 時間以内に、証明書を失効させるか、Microsoft に例外を要求する必要があります。 マイクロソフトは、提出された資料をレビューし、独自の判断で、例外を許可または拒否する最終的な決定を CA に伝えます。 Microsoft が例外を許可しない場合、CA は、例外が拒否されてから 24 時間以内に、証明書を失効させる必要があります。
3. プログラムの技術要件
プログラム内のすべてのCAは、プログラム技術要件に準拠する必要があります。 Microsoft は、CA が以下の要件に準拠していないと判断した場合、その CA をプログラムから除外します。
A. ルート要件
ルート証明書は、x.509 v3 証明書である必要があります。
CN 属性は、発行元を一意に示すものである必要があります。
CN属性は、CAの市場に適した言語であり、その市場の典型的な顧客が読めるものでなければなりません。
基本的な制約拡張: cA=trueでなければなりません。
キー使用拡張が存在し、重大とマークされている必要があります。 KeyCertSign と cRLSign のビット位置が、設定されている必要があります。 OCSP 応答の署名にルート CA の秘密キーが使用されている場合は、digitalSignature ビットが設定されている必要があります。
ルート キー サイズは、以下の「署名要件」で詳しく説明されている要件を満たしている必要があります。
信頼されたルート ストアに追加される証明書は、自己署名ルート証明書である必要があります。
新しく作成されるルート CA の有効期間は、送信日から 8 年以上 25 年以下である必要があります。
プライベート鍵とサブジェクト名は、ルート証明書ごとに一意である必要があります。同じCAによる後続のルート証明書でのプライベート鍵またはサブジェクト名の再利用は、予期しない証明書の連鎖問題を引き起こす可能性があります。 CA は、Microsoft による配布の前に新しいルート証明書を生成するときは、新しいキーを生成し、新しいサブジェクト名を適用する必要があります。
政府CAは、サーバー認証を政府が発行したトップレベルドメインに制限し、その国が主権管理下にあるISO 3166国コードにのみ追加の証明書を発行する必要があります(「政府CA」の定義については、セクションIIIをhttps://aka.ms/auditreqs参照してください)。 これらの政府発行の TLD は、各 CA のコントラクトで参照されます。
参加しているルート CA にチェーンする発行元 CA 証明書では、サーバー認証、S/MIME、コード署名、およびタイムスタンプの使用を別にする必要があります。 つまり、単一の発行元 CA で、サーバー認証と S/MIME、コード署名、タイムスタンプ EKU を組み合わせることはできません。 各ユースケースには別々の中間を使用する必要があります。
2024 年 8 月以降、信頼されたルート プログラムとそれぞれのツールによって管理されているすべてのカスタム EV SSL OID が削除され、CA/B Forum 準拠の EV SSL OID (2.23.140.1.1) に置き換えられます。 Microsoft Edge チームは、ブラウザーで EV SSL OID (2.23.140.1.1) のチェックを実装します。そのため、他の EV SSL OID は、Edge と連携して互換性を回避するために受け入れられなくなります。
2024 年 2 月以降、Microsoft は EV コード署名証明書を受け入れたり認識したりしなくなり、CCADB は EV コード署名監査の受け入れを停止します。 2024 年 8 月以降、すべての EV コード署名 OID が Microsoft 信頼されたルート プログラムの既存のルートから削除され、すべてのコード署名証明書が均等に扱われます。
E. EKU の要件
CA は、ルート証明書に割り当てられたすべてのEKUのビジネス上の正当性を提供する必要があります。 正当性は、ある種類の証明書を発行する現在のビジネスの公的証拠、または近い将来(プログラムによるルート証明書の配布から1年以内)にそれらの証明書を発行する意図を示すビジネスプランの形である可能性があります。