#通常の OCSP (RFC 6960) 私は OCSP レスポンダーを書きました。ここで、レスポンスは次のように述べているRFC 6960に基づいています。
nextUpdate が設定されていない場合、レスポンダーは、より新しい失効情報が常に利用可能であることを示しています。
そのため、nextUpdate を設定せず、BouncyCastle を次のBasicOCSPRespBuilderように使用しました (Wireshark キャプチャでも見られるように、デフォルトで thisUpdate を設定します)。
basicOCSPRespBuilder.addResponse(certID, responseList.get(certID));
しかし、これらの応答は IIS の証明書オーセンティケーターによって拒否されました。certutil を試すと、応答ステータスは常に「期限切れ」でした。
これは、「certutil -url」コマンドを使用して確認されました。
#Lightweight OCSP (RFC 5019) 少しグーグルで調べてみると、Microsoft がRFC 5019に従って Lightweight OCSP をサポートしていることが明らかになりました。
クライアントは、nextUpdate フィールドの存在をチェックしなければならず、セクション 2.2.4 で説明されているように GMT 時間で表された現在の時間が、thisUpdate 時間と nextUpdate 時間の間にあることを確認しなければなりません。nextUpdate フィールドが存在しない場合、クライアントは応答を拒否する必要があります。
そこで、次のように nextUpdate Date (数分後) を含めるように実装を変更しました。
basicOCSPRespBuilder.addResponse(certID, responseList.get(certID), getNextUpdateDate(), null);
これにより、「期限切れ」ステータスの問題から抜け出すことができましたが、問題は、これが Web サーバーに展開され、「certutil -url」チェックを実行しようとすると、証明書の WebProxy リンクに対して「検証済み」が返されることです。しかし、サーバーの URL を直接指定すると、「OK」が表示されます。同じレスポンダであるため、レスポンス構造はどちらの場合も同じままです (Wireshark キャプチャを使用して確認しました。必要に応じてこれを添付することもできます)。
#issuerKeyHash フィールド ここで興味深いのは、サーバーに送信される OCSP リクエストが、WebProxy 経由と直接 URL 経由の場合で異なることです。issuerKeyHashOCSP 要求であるという違いには、要求を直接リンクに送信するときは含まれません。
「検証済み」を返した Webproxy に送信された OCSP 要求の Wireshark キャプチャ:-
ステータス「OK」を返した直接リンクに送信された OCSP 要求の Wireshark キャプチャ:-
問題は、リクエストに issuerKeyHash が一方のインスタンスに含まれ、他方のインスタンスには含まれていない理由です。さらに、サーバーからの OCSP 応答が類似しているにもかかわらず、両方のクエリのステータスが同じでないのはなぜですか (Wireshark Caputres によって確認されています)。
この点に関して、「URL取得ツール」または「certutil -verify」の洞察に満ちたドキュメント/リンクにも感謝します。
リクエストに応じて、Wireshark キャプチャを含めることもできます。
OCSP 応答は Java や openssl などで問題なく (RFC 6960 に従って nextUpdate の有無にかかわらず) 受け入れられるため、Java と Bouncycastle をタグとして含めていません。この質問は、Microsoft certutil と OCSP Check here で何が起こっているかを理解することです。
#更新 #1 --- 更新 #1 の開始 ---
@Crypt32 で提案されているように。URL フィールドで URL を使用すると、不明な理由で完全な Certificate-Path が構築されないことを確認できましたIssuerKeyHash。
応答には常に含まれていると想定されておりIssuerKeyHash、これが「検証済み」ステータスではなく「OK」ステータスにつながる可能性があります。これを確認するために、リクエストに一致するようにレスポンスを変更し、リクエストで配信されなかった場合は送信しませんでしIssuerKeyHashたが、ステータスは「OK」のままで「確認済み」に変わりませんでした。
これは、Microsoft アプリケーションが OCSP 応答を処理する方法と、レスポンダーを正しく実装する方法を正しく理解して、Microsoft アプリケーションが失敗しないようにすることを目的としています。
研究は進行中です。アドバイスや提案は大歓迎です!!
--- アップデート #1 を終了 ---