8

HttpWebRequest を使用して SSL\TLS 接続を確立すると、呼び出し時に 30 秒近くかかることがわかりました

  request.GetRequestStream()

stacktrace を有効にしてトレースを有効にすると、2s が poxy を検出することがわかったので、app.config で無効にしました。

<system.net>
 <defaultProxy enabled="false" useDefaultCredentials="false">
  <proxy/>
  <bypasslist/>
  <module/>
 </defaultProxy>
</system.net>

28秒近くかかる次のポイントは

   at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint)

メソッド本体を調べたところ、X509Chain.Build() の呼び出しが見つかり、証明書チェーンの構築に 25 秒近くかかりました。

興味深いことに、新しい HttpWebReqest を作成して再試行すると (アプリを再起動せずに)、リクエストの実行に数ミリ秒かかりました。

誰かが何をすべきか提案できますか? リクエストのキャッシュはオプションではありません。アプリの実行から高速である必要があります。

更新

X509Chain.BuildChain() で 30 秒かかる呼び出しを見つけました。

if (!CAPISafe.CertGetCertificateChain(hChainEngine, pCertContext, ref pTime, invalidHandle, ref cert_chain_para, dwFlags, IntPtr.Zero, ref ppChainContext))

CAPISafe で次のように宣言されたメソッド:

[DllImport("crypt32.dll", CharSet = CharSet.Auto, SetLastError = true)]
internal static extern bool CertGetCertificateChain([In] IntPtr hChainEngine, [In] SafeCertContextHandle pCertContext, [In] ref System.Runtime.InteropServices.ComTypes.FILETIME pTime, [In] SafeCertStoreHandle hAdditionalStore, [In] ref CAPIBase.CERT_CHAIN_PARA pChainPara, [In] uint dwFlags, [In] IntPtr pvReserved, [In, Out] ref SafeCertChainHandle ppChainContext);

というわけで、Crypto API 関数CertGetCertificateChain です。

アップデート:

CRL および OCSP チェックを無効にしようとしましたが、効果はありません:

  1. App.config に追加

    <runtime>
      <generatePublisherEvidence enabled="false"/>
    </runtime>
    
  2. マシン全体: [コントロール パネル] -> [インターネット オプション] -> [詳細設定] -> [セキュリティ] で、[発行元の証明書の失効を確認する] オプションのチェックを外します

  3. レジストリ内:

    [HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing] "状態"=dword:00023e00

4

2 に答える 2

8

最後に、問題の根源を見つけました。イベント ログで CAPI2 ログを有効にしましたが、証明書信頼リストを次からダウンロードしようとしたときに NetworkTimeoutException が見つかりました。

http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

それで、それはファイアウォールの問題でした。調査プロセスと使用された手法に関するブログ投稿を読むことができます。

于 2012-06-13T21:56:19.847 に答える
4

通常、パスの構築は有効なパスの構築を意味し、証明書が発行されてから取り消されていないかどうかを確認する必要があります。

現在の失効ステータスを確認するには、CRL または OCSP レスポンダーからの最新情報が必要です。パス検証リクエストのセットアップ中に正しい CRL が明示的に提供されない場合、CRL の URL が「CRL 配布ポイント」拡張機能にリストされている場合、多くのライブラリは (通常はインターネット経由で) 取得しようとします。

ネットワークが遅い場合、パスが長い場合、または CRL が大きい場合、これには時間がかかることがあります。おそらく、これがあなたのケースで非常に時間がかかっていることです。最初の実行後は高速に実行されるため、最初の試行中にいくつかの大きな CRL がダウンロードされ、その後の使用のためにキャッシュされると推測しています。

あるいは、「Authority Information Access」拡張機能でアドバタイズされている場合、ライブラリはOCSP レスポンダーに自動的に連絡する場合があります。ただし、一部のライブラリでは、OCSP を使用するため、または CRL よりも優先するために、明示的な構成が必要です。

多くの異なる発行者のそれぞれからいくつかの証明書証明書を検証する場合は、OCSP が利用可能な場合はいつでも OCSP を使用してみてください。プロトコルは高速で、応答は小さく、多くの場合、発行者がこれまでに失効させたすべての証明書ではなく、単一の証明書に関する情報が含まれています。

単一の発行者からの多数の証明書を検証する場合は、その発行者の CRL をバックグラウンドで積極的にダウンロードし、有効期限が切れるまで保持します。次に、ユーザーが待機している間に CRL をダウンロードする必要がないように、CRL をパス構築プロセスに渡します。

于 2012-05-23T16:49:19.713 に答える