SignTool in SDK BuildTools 10.0.28000.2957: cache-only verification and result evidence

Peter Zhang 0 Reputation points
2026-10-31T02:25:28.4366667+00:00

Please identify existing, version-applicable documentation or an independently reviewed implementation record for SignTool distributed through Microsoft.Windows.SDK.BuildTools 10.0.28000.2957.

We need clarification on two points before recommending acquisition as a candidate solution:

  1. Cache-only enforcement: Which supported verification configuration prevents automatic certificate, revocation or other supporting retrieval? Please distinguish SignTool controls from native WinVerifyTrust controls that SignTool may not expose.
  2. Evidence exposure: Which results identify revocation scope and freshness, signer-certificate validity, timestamp treatment and unavailable or indeterminate evidence? Please distinguish process exit status from underlying provider results and explain applicable limitations.

Please also identify the evidence supporting internal verification-state cleanup and interruption behavior for the applicable build.

We request existing documentation or review records only. No trial invocation, installation, newly built wrapper or remote access is requested. Please identify version applicability and distinguish documented guarantees from assumptions.

Windows development | Windows API - Win32
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-10-31T02:26:54.9966667+00:00

    No public record identified establishes that SignTool from Microsoft.Windows.SDK.BuildTools 10.0.28000.2957 can enforce cache-only verification or expose the complete verification evidence requested; those controls and detailed results are documented only at the native WinVerifyTrust/certificate-chain API layer.

    Version applicability and provenance

    The NuGet Gallery identifies Microsoft.Windows.SDK.BuildTools version 10.0.28000.2957 as an available package ^1^. Microsoft documents that SignTool is part of the Windows SDK and is installed under its Bin directory ^2^. Microsoft also directs users to the BuildTools package to obtain SignTool ^3^.

    These establish the package family and distribution route. They do not provide:

    • A 10.0.28000.2957-specific SignTool behavioral contract.
    • Source or independently reviewed implementation details for that executable.
    • A package-to-binary provenance record covering the exact payload, hash, or internal implementation.
    • A statement that this build forwards particular undocumented options to WinVerifyTrust.

    The located independent repositories merely reference or lock the package version; they are acquisition records, not reviews of SignTool verification behavior.

    Cache-only enforcement

    SignTool

    The documented signtool verify options include policy selection, catalog handling, signature selection, verbose/debug output, and timestamp warnings. They do not include a cache-only, offline, or “disable URL retrieval” option ^2^.

    Consequently, there is no documented SignTool configuration for 10.0.28000.2957 that guarantees verification will not automatically retrieve certificates, revocation data, or other supporting material. Running it behind a disconnected network would constrain the environment, but it would not constitute a documented SignTool enforcement control.

    Native WinVerifyTrust

    For a caller that owns the WinVerifyTrust invocation, WINTRUST_DATA.dwProvFlags supports:

    • WTD_CACHE_ONLY_URL_RETRIEVAL: use only locally cached revocation information and prevent network revocation checks.
    • Revocation scope flags for none, end certificate, complete chain, or complete chain excluding the root.
    • WTD_LIFETIME_SIGNING_FLAG: limit a timestamped signature to the signing certificate’s lifetime rather than treating the timestamped signature as valid indefinitely ^4^.

    The documentation explicitly describes WTD_CACHE_ONLY_URL_RETRIEVAL in terms of revocation checks. It does not provide a broad guarantee that every possible certificate, AIA, CTL, policy, or provider-supporting retrieval is disabled. It also does not document a SignTool switch that sets this flag.

    Evidence and result exposure

    SignTool process-level evidence

    SignTool provides:

    • Text output; /v displays signer-certificate and verbose status information.
    • /debug adds debugging information.
    • /tw produces a warning when no timestamp exists.
    • Process exit code 0 for success, 1 for failure, and 2 for warnings ^5^.

    These exit codes classify the overall command outcome. They do not encode revocation scope, freshness, the affected chain element, timestamp-chain treatment, or the distinction between absent and indeterminate evidence. SignTool’s documented output is not specified as a stable, structured evidence contract.

    Native trust-provider evidence

    WinVerifyTrust returns zero only when the selected provider verifies trust. Every nonzero value must be treated as nonsuccess; the return is a LONG, not an HRESULT, and must not be tested with SUCCEEDED ^6^. That provider result remains distinct from SignTool’s normalized process exit code.

    When verification is performed with WTD_STATEACTION_VERIFY, the retained state can be queried as follows:

    1. WTHelperProvDataFromStateData obtains CRYPT_PROVIDER_DATA from hWVTStateData ^7^.
    2. CRYPT_PROVIDER_DATA exposes the final error, trust-step errors, provider flags, stores, and signer array ^8^.
    3. CRYPT_PROVIDER_SGNR exposes signer or countersigner status, verification time, certificate chain, signer error, timestamp-signer indication, and chain context ^9^.
    4. Each CERT_CHAIN_ELEMENT exposes certificate trust status and, when revocation checking occurred, pRevocationInfo; a null pointer means revocation checking was not enabled ^10^.
    5. CERT_REVOCATION_INFO can distinguish revoked from unknown status and can report CRL freshness in seconds when fHasFreshnessTime is true ^11^.

    This native state can represent substantially more evidence than SignTool’s exit status. However, the helper and provider structures carry warnings that they may change or become unavailable, and Microsoft recommends the certificate-chain APIs for certificate verification. They are not documented as SignTool output or as a stable evidence schema specific to build 10.0.28000.2957.

    Cleanup and interruption

    The native lifecycle guarantee is explicit: every WTD_STATEACTION_VERIFY that creates hWVTStateData must be followed by a call using WTD_STATEACTION_CLOSE to release it ^4^. Microsoft’s WinVerifyTrust sample follows exactly that sequence ^12^.

    No located documentation or independent review establishes that SignTool 10.0.28000.2957:

    • Retains provider state using this specific pattern.
    • Executes WTD_STATEACTION_CLOSE on every internal error or interruption path.
    • Exposes cancellation semantics.
    • Guarantees cleanup after forced process termination.

    Windows documentation states generally that forced thread or process termination does not permit normal cleanup and does not notify attached DLLs ^13^. That is an operating-system limitation, not evidence of SignTool’s internal design.

    Therefore, acquisition of this package can be supported as acquisition of an official SDK SignTool distribution, but not as a documented solution for the requested cache-only guarantee, structured evidence completeness, or build-specific interruption cleanup.

    References

    1. Microsoft.Windows.SDK.BuildTools 10.0.28000.2957
    2. SignTool - Win32 apps | Microsoft Learn
    3. Set up signing integrations to use Artifact Signing
    4. WINTRUST_DATA structure (wintrust.h)
    5. Use SignTool to verify a file signature
    6. WinVerifyTrust function (wintrust.h)
    7. WTHelperProvDataFromStateData function (wintrust.h)
    8. CRYPT_PROVIDER_DATA structure (wintrust.h)
    9. CRYPT_PROVIDER_SGNR structure (wintrust.h)
    10. CERT_CHAIN_ELEMENT structure (wincrypt.h)
    11. CERT_REVOCATION_INFO structure (wincrypt.h)
    12. Example C Program: Verifying the Signature of a PE File
    13. Terminating a Thread
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Zack Nguyen (WICLOUD CORPORATION) 405 Reputation points Microsoft External Staff Moderator
    2026-11-02T06:07:31.72+00:00

    Hi @Peter Zhang ,
    The available Microsoft documentation does not establish a SignTool-specific contract for the requested behavior in Microsoft.Windows.SDK.BuildTools 10.0.28000.2957. The Windows SDK release notes identify this SDK build, but do not document SignTool-specific verification changes for it.

    Cache-only enforcement:

    • The documented SignTool options do not provide a cache-only/offline switch that guarantees prevention of supporting URL retrieval.
    • At the native API level, WINTRUST_DATA defines:
      • WTD_CACHE_ONLY_URL_RETRIEVAL
      • WTD_REVOCATION_CHECK_NONE
      • WTD_REVOCATION_CHECK_END_CERT
      • WTD_REVOCATION_CHECK_CHAIN
      • WTD_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT
    • These are WinTrust caller controls. The SignTool documentation does not establish that a SignTool option exposes WTD_CACHE_ONLY_URL_RETRIEVAL.

    Therefore, the native API provides documented cache/revocation controls, but no equivalent SignTool guarantee is documented.

    Evidence exposure:

    These native structures can carry signer, chain, timestamp, revocation and freshness information. SignTool does not document its process exit code or console output as an equivalent structured evidence interface.

    Cleanup and interruption:

    • Native WinTrust callers using WTD_STATEACTION_VERIFY must subsequently close retained state with WTD_STATEACTION_CLOSE. Microsoft demonstrates this lifecycle in the PE signature verification example.
    • General thread-termination documentation also warns that forced termination does not permit normal cleanup.
    • However, these do not establish SignTool 10.0.28000.2957's internal cleanup, cancellation, or interruption paths.

    I hope this helps clarifying your requirements. If you find my response helpful, I would greatly appreciate it if you could follow the guide here so others experiencing similar behavior or issue can benefit from it as well.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.