これらの要件の1つは、4.9.9項でMUSTマークを付けて指定されています。
OCSP（オンライン証明書ステータスプロトコル）応答は、RFC6960および/またはRFC5019に準拠する必要があります。OCSP応答は、次のいずれかでなければなりません。
- 失効ステータスがチェックされている証明書を発行したCAによって署名されている、または
- 証明書を発行したCAによって証明書が署名され、失効ステータスがチェックされている署名OCSPレスポンダーを用意する
後者の場合、OCSP署名証明書には、RFC6960で指定されているタイプid-pkix-ocsp-nocheckの拡張子が含まれている必要があります。
この規則は、ほとんどすべての認証機関（CA）によって違反されており、いくつかの結果があります。
これは、公的に信頼さ れた証明書の発行と管理に関するベースライン要件のスクリーンショットです（最新バージョン1.7.0、2020年5月4日、pdf）：
セクション4.2.2.2のRFC6960標準では、id-kp-の存在によって「OCSP委任レスポンダー」が定義されています。 OCSPSigning。
証明書の操作を専門とする開発者のRyanSleeviは、CAがルール4.9.9に大幅に違反していることを証明しました。
crt.shデータを調べた後、Ryan Slavyは、pkix-nocheck拡張子のない293の中間証明書を見つけました。そのうち、180が現在有効で、113が取り消されています。
Census.ioでのフィルタリングは276の証明書を発行しますこれらの条件に一致します。
したがって、これらの証明書は、CA / Browserの基本要件、さらに必須要件に違反します。
Ryan Slavyによると、CAはCA /ブラウザのルールを詳しく調べる必要があります。おそらく、一部のCAはRFC 6960の要件に精通していません。
対応する拡張機能がないことは、単なる形式的なものではありません。中間CAが同じルートCAから別の中間CAの証明書を取り消すことができないという意味で、ここでは問題はありません。
本当の問題は、拡張機能がない場合、中間CAが理論的に証明書の失効をキャンセルできることです。別の中間CAまたはルートCA自体。これは本当に問題です。実際、このような状況での認証機関には、証明書を完全かつ不可逆的に取り消すための信頼できるオプションがありません。失効手順が期待どおりに機能しないため、失効した証明書を復元するために攻撃を行う可能性のある攻撃者に門戸が開かれます。
この問題を解決するには、証明書を取り消すときに、キーのすべてのコピーを完全に削除して、失効も元に戻せないようにすることをお勧めします。
CAを正当化するために、この欠点がなくても、証明書の失効手順は期待どおりに機能しないと言えます。たとえば、主要なブラウザはCRLの独自のコピーを維持しており、常に最新であるとは限りません。これらのCRLには、基本的で最も重要な情報しか含まれていませんが、完全ではありません。たとえば、Chromeは、特定のTLS証明書がそれぞれ取り消されているかどうかを確認する必要はありませんが、Firefoxは取り消されています。つまり、Chromeを使用すると、証明書の有効期限が切れているサイトに安全にアクセスでき、Firefoxが警告を発行して、そこにアクセスできない場合があります。
興味深いことに、規則によれば、誤った証明書は7日以内にブラウザーで取り消す必要がありますが、この状況では例外がありました。 MozillaのBenWilsonは、そうしないと言ったid-pkix-ocsp-nocheck拡張子が欠落している証明書を取り消します。このような証明書は準拠していませんが、Firefoxブラウザーは、中間CAによって署名されたOCSP応答を受け入れないため、この特定のセキュリティの脆弱性の影響を受けません。
CAは何らかの方法で誤った証明書を置き換える必要がありますが、最終的な期限はありません。
企業向けのPKIソリューションの 詳細については、GlobalSignマネージャー+7（499）678 2210、sales-ru @ globalsign.comにお問い合わせください。