問題タブ [certutil]

質問する

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

94 問題
Newest
Active
Bountied
318
Unanswered
0 投票する
0 に答える
773 参照

c# - certutil.exe が「指定されたネットワーク パスワードが正しくありません」を返す

  1. 次のように、Bouncy Castle ライブラリを使用して、CA ルート証明書と自己署名マシン証明書を作成しています。実装全体を以下にリストします。パスワードで保護された .PFX ファイルを作成できます。

  2. CA ルート証明書を作成しましたが、マシンに既にインストールされているため (サブジェクトと発行者が同じ)、インストールしません。それに加えて、元の CAR ルート証明書 (MyCARoot.cer) がどのように作成されたのかはわかりませんが、次のコマンドでインストールされます。

    certmgr.exe /add MyCARoot.cer /c /s /r localMachine ルート

  3. ある時点で、certutil.exe を使用して作成した自己署名マシン証明書 (.PFX) をインストールできましたが、現在は常に上記のエラーが返されます。

  4. ここでの私の質問は、1 つ以上の領域を対象としています。

    • 以下の私の実装が正しいかどうか-「秘密鍵のエクスポートを許可する」などの何かを見逃していましたか...
    • アプローチ全体が正しいかどうか - makecert.exe を pvk2pfx.exe と一緒に使用する代わりに、自己署名マシン証明書を手動で作成してインストールする必要があったため、それに切り替えました。ユーザーは秘密鍵パスワードの入力を 4 回求められます。 ..

    • 生成した .pfx が正しいことを確認するにはどうすればよいですか? （certutil.exeでインストールしようとする以外に？

      /li>

および関数の実装:

0 投票する
2 に答える
1742 参照

windows - Microsoft OCSP チェック (OCSP と軽量 OCSP) & "certutil -url" による紛らわしい応答

#通常の OCSP (RFC 6960) 私は OCSP レスポンダーを書きました。ここで、レスポンスは次のように述べているRFC 6960に基づいています。

nextUpdate が設定されていない場合、レスポンダーは、より新しい失効情報が常に利用可能であることを示しています。

そのため、nextUpdate を設定せず、BouncyCastle を次のBasicOCSPRespBuilderように使用しました (Wireshark キャプチャでも見られるように、デフォルトで thisUpdate を設定します)。

しかし、これらの応答は IIS の証明書オーセンティケーターによって拒否されました。certutil を試すと、応答ステータスは常に「期限切れ」でした。

ここに画像の説明を入力

これは、「certutil -url」コマンドを使用して確認されました。

#Lightweight OCSP (RFC 5019) 少しグーグルで調べてみると、Microsoft がRFC 5019に従って Lightweight OCSP をサポートしていることが明らかになりました。

クライアントは、nextUpdate フィールドの存在をチェックしなければならず、セクション 2.2.4 で説明されているように GMT 時間で表された現在の時間が、thisUpdate 時間と nextUpdate 時間の間にあることを確認しなければなりません。nextUpdate フィールドが存在しない場合、クライアントは応答を拒否する必要があります。

そこで、次のように nextUpdate Date (数分後) を含めるように実装を変更しました。

これにより、「期限切れ」ステータスの問題から抜け出すことができましたが、問題は、これが 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 を終了 ---


12345678910