SignTool SDK 10.0.26100.0 rejects RFC 3161 HTTPS URLs with Invalid Timestamp URL

hich 0 Reputation points
2026-10-10T19:40:38.18+00:00

We request free product/documentation clarification only, not a paid support case.

Environment: isolated GitHub-hosted Windows Server 2022, OS 10.0.20348.0; Microsoft-signed x64 SignTool under Windows Kits/10/bin/10.0.26100.0/x64. FileVersion: 4.00 (WinBuild.160101.0800). Exact SignTool executable SHA-256/ProductVersion were not captured.

We attempted timestamping only disposable copies of an existing Microsoft executable with a SHA-256 Authenticode signature. Baseline verification succeeded. No private key, new primary signature, certificate import or production machine was involved. The copies were never executed and root stores remained unchanged.

Arguments passed to SignTool:

timestamp /tr https://rfc3161.ai.moda/ /td SHA256 /tp 0 /v <disposable-already-signed-copy.exe>

timestamp /tr https://timestamp.sectigo.com/ /td SHA256 /tp 0 /v <disposable-already-signed-copy.exe>

Both returned exit code 1:

SignTool Error: Invalid Timestamp URL: https://rfc3161.ai.moda/

SignTool Error: Invalid Timestamp URL: https://timestamp.sectigo.com/

Independent .NET HTTPS RFC 3161 POST requests from that same environment returned valid SHA-256 tokens with matching nonce/imprint and timestamping EKU, chaining to pre-existing Windows roots. These were separate requests and do not prove SignTool received the same response.

Public reproduction harness and logs:

https://github.com/khemisset18/gpubnb/actions/runs/38078385157

https://github.com/khemisset18/gpubnb/blob/f30ac0f603eda727dbb95f1ee33308bdf995bf48/scripts/tests/windows-tsa-probe.ps1

The Microsoft page below shows /tr https://timestamp.example.com, but we found no known-issue entry or corrected build explaining our observed rejection:

https://learn.microsoft.com/en-us/windows/win32/seccrypto/time-stamping-authenticode-signatures

Questions:

  1. Is direct HTTPS /tr supported by this SDK SignTool for timestamp and sign? Does it depend on SDK patch, architecture or OS Authenticode components?
  2. What validation produces Invalid Timestamp URL? Could /tp 0, trailing slash, proxy or URL parsing affect it? Does the error necessarily precede network access?
  3. Is there an official issue identifier or a free corrected Microsoft tool build?
  4. What minimal diagnostics distinguish URL validation from transport/TLS failure without exposing credentials or keys?
  5. If this combination does not support HTTPS, can the documentation clarify the limitation? Our procedure requires HTTPS and we will not bypass certificate validation or downgrade it to HTTP.

No subscription, replacement trust root or paid signing service is requested.

Windows development | Windows App SDK
0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-10-10T19:40:52.8066667+00:00

    Supported facts from the available documentation are:

    • signtool timestamp and signtool sign both support RFC 3161 timestamping through the /tr option.
    • /tr takes a URL for the RFC 3161 time stamp server.
    • /td must be used with /tr to request the digest algorithm, and SHA256 is recommended.
    • /tr cannot be used together with /t.
    • If /tr or /t is not present, the file is not time stamped.
    • If time stamping fails, SignTool generates a warning.
    • For SDK, WDK, HLK, and ADK builds 20236 and later, SignTool requires specifying /fd for signing and /td for time stamping.

    For an app package, time stamping must be done during the sign operation, not with the separate timestamp operation.

    The available documentation does not provide:

    • a statement that HTTPS is or is not supported for /tr
    • any version-specific known issue for SDK 10.0.26100.0
    • the internal validation rules that lead to Invalid Timestamp URL
    • whether that error occurs before any network access
    • any official issue identifier or corrected build for this behavior
    • diagnostics that distinguish URL parsing failure from TLS or transport failure
    • any documented effect of /tp 0, trailing slash, proxy handling, architecture, or OS Authenticode components on this specific error

    Based on the documented behavior alone, the only confirmed requirement for RFC 3161 is to use /tr <URL> together with /td <alg>, and not combine /tr with /t.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    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.