Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Windows: revocation check blocks up to 10s with no effect on verification outcome

オープン
  • 何か問題がありますか？
#237 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

@djc がすでに取り組んでいます。

2026年7月8日 から。

  • #238 @djc による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
rust
領域
security

調査の方向性

src/verification/windows.rs から始め、実稼働用のチェーン構築フラグおよび dwUrlRetrievalTimeout を、CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL を使用するテスト構成と比較します。verify_chain_policy が失効エラーをどのように処理するかを追跡し、提案されている動作のうちどれが意図されたものかを判断します。不要なブロッキング検索に対処しつつ証明書検証の結果を変更せず、Windows の動作をカバーできれば完了です。

索引モデルが issue の本文から書いたものです。

説明

O-Windows

Summary

On Windows, CertGetCertificateChain is called with CERT_CHAIN_REVOCATION_CHECK_END_CERT, which triggers a network call to OCSP/CRL endpoints with a 10-second timeout. However, in verify_chain_policy, CERT_CHAIN_POLICY_IGNORE_ALL_REV_UNKNOWN_FLAGS is set, meaning revocation failures are silently ignored in the final policy decision.

This results in a blocking network call of up to 10 seconds that has no effect on whether the certificate is ultimately accepted or rejected.

Impact

In network-restricted environments (e.g., hosts with limited outbound access where OCSP/CRL endpoints are unreachable), the TLS handshake blocks for the full 10-second dwUrlRetrievalTimeout on every first connection attempt. This is particularly problematic f
or:

  • Short-lived instances where the CRL cache is always cold
  • Hosts behind firewalls that allow :443 to the application server but not to arbitrary OCSP responders
  • Applications with request timeouts shorter than 10 seconds (the revocation timeout exceeds the application timeout, causing connection failures)

One can hit this e.g. after migrating from webpki-roots (no network calls) to rustls-platform-verifier (via reqwest 0.13).

Relevant code

In src/verification/windows.rs:

// Chain building — triggers network call
const FLAGS: u32 = CERT_CHAIN_REVOCATION_CHECK_END_CERT
    | CERT_CHAIN_REVOCATION_ACCUMULATIVE_TIMEOUT
    | CERT_CHAIN_CACHE_END_CERT;

parameters.dwUrlRetrievalTimeout = 10 * 1000; // 10 seconds

// Policy verification — ignores revocation failures
params.dwFlags = CERT_CHAIN_POLICY_IGNORE_ALL_REV_UNKNOWN_FLAGS;

Comparison with other implementations

  • Go crypto/x509 (root_windows.go): Calls CertGetCertificateChain without any CERT_CHAIN_REVOCATION_CHECK_* flags - no revocation network calls.
  • The test configuration in this crate: Uses CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL to prevent network calls, which confirms the production code intentionally makes them.

Suggestion

Would you consider one of the following?

  1. Remove CERT_CHAIN_REVOCATION_CHECK_END_CERT from the flags, since the result is discarded by the policy step anyway. This eliminates the network call with no change in security posture.

  2. Make revocation checking configurable via a builder option on Verifier (e.g., with_revocation_check(bool) or with_revocation_check(RevocationPolicy)) so consumers can opt out in environments where the network call is problematic.

  3. Use CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY by default (check cached CRLs without making network calls), with an opt-in for full network-based revocation.

Environment

  • Windows Server 2025
  • rustls-platform-verifier 0.7.x
  • reqwest 0.13
主要言語
Rust
スター
160
フォーク
66
平均マージ
2日 22時間
マージ済み PR（30日）
4

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rustls/rustls-platform-verifier のほかの issue

rustls/rustls-platform-verifier の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。