ErrorHarbor
Error Library

SignTool Error: The Specified Timestamp Server Either Could Not Be Reached or Returned an Invalid Response

This error places the failure at the timestamp-request stage: SignTool did not obtain a response it could accept as the requested timestamp. Keep the already-selected signing identity unchanged first. Identify whether the command uses legacy Authenticode /t or RFC 3161 /tr, then trace the same execution context through DNS/TCP → proxy/TLS → protocol-compatible timestamp request → final signature/timestamp verification. Basic reachability alone does not prove a timestamp service is healthy or compatible.

SignTool · Timestamp · RFC 3161Windows SDK · CI/CD · ProxyLast reviewed Sep 27, 2026
🎯 You’re likely in the right place if:
SignTool reports The specified timestamp server either could not be reached or returned an invalid response.Your certificate can be selected and the failure appears when /t or /tr is used.The same signing command may work on one machine but fail behind a proxy, firewall, service account, or CI runner.
Choose your path
Endpoint fails outside SignTool tooInvestigate URL, DNS, network path, proxy/firewall/TLS and provider state—but remember that browser/TCP reachability alone does not validate a timestamp response.
/t works but /tr fails, or vice versaCheck which timestamp protocol the endpoint actually supports; the switches are not interchangeable.
/tr is used without a correct /tdUse the RFC 3161 timestamp digest option; Microsoft recommends SHA256.
Works locally but fails in CI/serviceTest from the runner/service context; its proxy, egress, DNS, and trust path can differ.
Difficulty: ModerateRisk: Low first
🔎 Quick Check — identify the timestamp mode before changing anything

Inspect the failing command. Microsoft documents /t URL as the legacy Authenticode timestamp option and /tr URL as the RFC 3161 option. They cannot be used together.

signtool sign /v /fd SHA256 /tr "https://YOUR-RFC3161-ENDPOINT" /td SHA256 <your existing certificate options> "app.exe"

Do not paste a random public timestamp URL. Confirm the endpoint and protocol from your certificate/signing provider or platform documentation. If certificate selection fails before timestamping, use the certificate-selection guide instead.

ADSENSE · reserved slot after the first useful step

Diagnostic flow — isolate endpoint, protocol, then environment

1
Confirm the exact timestamp URL and switch.
Record whether the command uses /t or /tr and whether that provider endpoint supports that protocol.
2
Test reachability from the failing machine or runner.
Do not infer CI connectivity from your desktop browser.
3
If networking works, inspect SignTool timestamp options.
For RFC 3161 /tr, check /td and use SHA256 unless your provider requires something else.
4
Verify the resulting signature and timestamp.
A successful command is not the final check; inspect the signed file.

Fix #1 — verify the endpoint and timestamp protocol

Fast interpretation: /t = legacy Authenticode timestamping; /tr = RFC 3161 timestamping. With /tr, pair it with /td SHA256 unless your provider explicitly documents another supported digest.

Do not convert /t to /tr merely because one looks newer. The endpoint must support the matching protocol. Microsoft distinguishes legacy Authenticode timestamping (/t) from RFC 3161 timestamping (/tr).

Preferred for new Authenticode workflows: Microsoft currently recommends RFC 3161 with /tr and /td SHA256. Still use the endpoint documented by your signing provider.

Verify: rerun with the provider-confirmed endpoint and matching switch. If the same server error remains, continue to network-path diagnosis rather than changing the certificate.

Fix #2 — test DNS and the correct port from the failing environment

Extract the hostname and scheme from the timestamp URL, then test from the same workstation, service-account host, or CI runner that fails. A browser test on another machine does not prove the build agent can reach it.

Choose the port from the actual endpoint: HTTPS normally uses 443; HTTP normally uses 80 unless your provider documents a custom port. Do not automatically test 443 for an http:// timestamp URL.
Resolve-DnsName YOUR_TIMESTAMP_HOST Test-NetConnection YOUR_TIMESTAMP_HOST -Port YOUR_ENDPOINT_PORT

Important: DNS resolution and a successful TCP test prove only lower-layer reachability. Likewise, loading a URL in a browser is not a protocol-valid timestamp test: Authenticode/RFC 3161 timestamp services expect specific requests and responses. Use the original SignTool operation (or the provider's documented diagnostic method) as the application-layer test.

Verify: DNS should resolve and the documented endpoint port should be reachable from the failing environment. Then rerun the same protocol-compatible SignTool timestamp request. If transport works but SignTool still reports an invalid response, the diagnosis moves upward to proxy/TLS behavior, endpoint protocol compatibility, digest options or provider response—not back to DNS.

Fix #3 — check proxy, firewall, TLS inspection, and egress policy

Enterprise signing often runs under a different network context than an interactive user. Check whether the build process must use a proxy, whether outbound traffic to the timestamp authority is allowed, and whether TLS inspection changes or blocks the connection. Do not disable certificate validation or the corporate security stack as a shortcut.

netsh winhttp show proxy

Verify: rerun the timestamp operation from the same execution context after the approved proxy/firewall route is corrected. If local signing works but the runner still fails, keep diagnosis inside the runner.

Fix #4 — with /tr, specify the timestamp digest correctly

Microsoft documents /td for RFC 3161 timestamping and recommends SHA256. Keep file digest and timestamp digest conceptually separate: /fd controls the file-signature digest, while /td controls the RFC 3161 timestamp digest. Specify the intended digest explicitly, but do not cycle algorithms merely to make an endpoint respond; confirm what the provider supports.

signtool timestamp /tr "https://YOUR-RFC3161-ENDPOINT" /td SHA256 "app.exe"

Verify: the timestamp operation should complete without the server-response error using the provider-supported protocol/digest. Then verify the artifact itself; transport success or a different HTTP/TLS result is not final success.

Fix #5 — works locally but fails in CI, Jenkins, or a service?

Treat the runner as a separate network identity. Current Microsoft Q&A includes a 2026 case where a SignTool + Artifact Signing command worked in PowerShell but hung in Jenkins. Check the runner’s identity, proxy, DNS, outbound policy, and endpoint access inside the job itself.

whoami netsh winhttp show proxy Resolve-DnsName YOUR_TIMESTAMP_HOST

Verify: make the pipeline perform a non-secret connectivity check before signing, then run SignTool. Do not expose PFX passwords, private keys, access tokens, or signing-service credentials in logs.

Fix #6 — distinguish a provider outage from a permanent configuration fix

If a known-good command suddenly fails across multiple environments while DNS/network policy is unchanged, check the timestamp provider’s status or support channel. A bounded retry can be reasonable for a transient service failure, but repeated retries should not hide a wrong URL, protocol mismatch, or blocked egress.

Do not silently ship without timestamping merely to make the build green. Timestamping preserves evidence of when a valid signing certificate was used and is important for long-term signature validity.

Verify: after service recovery, sign a fresh test artifact and verify that the timestamp is present before restoring the normal release pipeline.

Final verification — confirm both signature and timestamp

Use SignTool verification after the signing/timestamp step and inspect the resulting signature/timestamp details. Do not infer timestamp success solely from SignTool no longer printing the original server error. For files that may be catalog-signed, choose verification options appropriate to the artifact/signing model rather than treating one verification switch as universal.

signtool verify /pa /v "app.exe"

Verify: inspect the verbose output and file signature details for a valid signature and timestamp. If timestamping succeeds but verification now fails on certificate trust, that is a different stage and should be diagnosed separately.

What not to do

Do not replace the signing certificate first when the failure clearly begins at the timestamp stage.Do not paste an arbitrary timestamp-server URL from a forum without confirming protocol/provider support.Do not disable TLS validation, firewall, proxy, or endpoint security globally to make timestamping work.Do not confuse /fd with RFC 3161 /td.Do not treat a successful local test as proof that a CI runner has the same network path.Do not treat DNS, TCP connectivity, HTTP status, or a browser-loaded timestamp URL as proof that the endpoint returned a valid Authenticode/RFC 3161 timestamp response.Do not switch between /t and /tr without confirming that the endpoint supports the matching timestamp protocol.Do not cycle /td algorithms merely to get a response; use a provider-supported digest and keep /fd vs /td semantics separate.Do not keep diagnosing timestamp reachability once a timestamp is issued and verification fails at a different trust/signature stage.

Still seeing the error?

Capture these before escalating:the exact error and redacted SignTool commandwhether you use /t or /tr and the provider hostname/fd and /td valuesDNS and expected-port reachability from the failing environmentproxy/egress context and whether failure is local or CI-onlywhether the same endpoint previously worked and when it last succeededthe exact SignTool/Windows SDK version used in the failing contextwhether lower-layer DNS/TCP succeeds but the protocol-compatible SignTool request still failsthe first different error if timestamp issuance succeeds but signature verification fails

If the next error says no certificate meets the criteria, return to No Certificates Were Found That Met All the Given Criteria. If signtool itself is unresolved, use ‘signtool’ Is Not Recognized. A trust-chain failure after successful timestamping is a separate next-stage problem.

Official references

Microsoft: SignToolOfficial /t, /tr, /td, signing and verification options →Microsoft: Time Stamping Authenticode SignaturesCurrent SHA256 and RFC 3161 recommendations →Microsoft: Artifact Signing integrationCurrent SignTool example using /tr and /td SHA256 →

Still stuck? Ask the community

Share the redacted command, /t or /tr mode, timestamp provider hostname, reachability result, and whether the failure is local or CI-only.

Keep it safe: never post PFX files, private keys, passwords, tokens, certificate secrets, private URLs or confidential build logs.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…