“Unable to contact the code signing server” (and related messages like “The timestamp operation failed” or “The specified timestamp server either could not be reached or returned an invalid response”) covers two distinct problems that look identical on the surface:
- Timestamp server unreachable: signtool is contacting a third-party timestamp server with the /tr flag and cannot reach it. This is the most common cause.
- Cloud HSM signing service unreachable: a cloud signing client (eSigner, smctl for KeyLocker, the Trusted Signing dlib) cannot reach the signing API. The key never leaves the cloud HSM, so signing itself can’t proceed.
The fixes are completely different. Identifying which situation you’re in takes about 30 seconds and prevents going down the wrong troubleshooting path.
Step 1: Identify Which Server Is Unreachable
Look at the full error output. signtool’s verbose mode (/v) shows where exactly the failure occurs:
- Failure mentions a timestamp server URL (timestamp.digicert.com, timestamp.sectigo.com, etc.): this is the timestamp problem. Jump to the timestamp server section below.
- Failure occurs before the file is even submitted for signing, or mentions the signing API, smctl, eSigner, or CodeSignTool: this is the cloud HSM connectivity problem. Jump to the cloud HSM section.
- Signing succeeds but fails on the timestamp step specifically: timestamp problem. The signing operation completed; the timestamp attachment failed.
Scenario A: Timestamp Server Unreachable
Timestamps are not optional. A signature without an RFC 3161 timestamp expires when the code signing certificate expires, often within 460 days. The /tr flag tells signtool which timestamp server to contact. If that server is unreachable, signtool fails the entire signing operation.
Fix 1: Test connectivity to the timestamp server
Before changing anything, confirm whether the timestamp server is actually unreachable from this machine:
| # Test timestamp server reachability from PowerShell:
> Invoke-WebRequest -Uri ‘http://timestamp.digicert.com’ -Method Get # A response (even an error page) means you can reach the server. # A timeout or connection refused means the network path is blocked.
# Alternative test with curl (if available): $ curl -v http://timestamp.digicert.com
# Test DNS resolution separately: > Resolve-DnsName timestamp.digicert.com |
If the connectivity test fails, the issue is network-level. Jump to Fix 3. If it succeeds, the issue is more specific: Fix 2 or Fix 4.
Fix 2: Try an alternative timestamp server
All major CAs provide free timestamp servers. If one is temporarily unavailable or rate-limiting your requests, switching to another resolves the immediate problem:
| # DigiCert (most widely used):
signtool sign /a /fd sha256 /tr http://timestamp.digicert.com /td sha256 /v file.exe
# Sectigo: signtool sign /a /fd sha256 /tr http://timestamp.sectigo.com /td sha256 /v file.exe
# GlobalSign: signtool sign /a /fd sha256 /tr http://timestamp.globalsign.com/scripts/timestamp.dll /td sha256 /v file.exe
# Entrust: signtool sign /a /fd sha256 /tr http://timestamp.entrust.net/TSS/RFC3161sha2TS /td sha256 /v file.exe |
Any trusted timestamp server works regardless of which CA issued your code signing certificate. You don’t need to use DigiCert’s timestamp server just because you have a DigiCert certificate. If one server is unreachable or slow, any of the others is a valid drop-in replacement.
Fix 3: Check firewall and proxy settings
Corporate firewalls and web proxies are the most common cause of timestamp server failures in enterprise environments. Timestamp servers operate over HTTP (port 80) by default, though some support HTTPS. Firewalls that block outbound HTTP to external hosts, or that require proxy authentication for external connections, will silently block timestamp requests.
signtool uses the Windows HTTP stack (WinHTTP) for its timestamp requests, which honors Windows proxy settings configured via netsh or Internet Explorer settings. If your browser can reach external sites through a corporate proxy but signtool cannot, the proxy may not be configured at the WinHTTP level.
| # Check the WinHTTP proxy configuration:
> netsh winhttp show proxy # If ‘Direct access (no proxy)’ and you need a proxy: > netsh winhttp set proxy proxy-server=’http://your-proxy:8080′ bypass-list='<local>’
# Or import the settings from Internet Explorer / system settings: > netsh winhttp import proxy source=ie |
If you’re in a corporate environment and cannot modify proxy settings yourself, contact your network team to allowlist outbound HTTP access to the timestamp server URLs, or to configure the proxy to pass timestamp requests through without authentication.
Fix 4: Rate limiting from high-volume signing
Some timestamp servers rate-limit requests from a single IP. If you’re signing a large number of files in a pipeline (hundreds or thousands per build), rapid sequential timestamp requests can trigger rate limiting that looks like a connectivity failure.
Two approaches help here: add a short delay between signtool calls in the pipeline script, or use a for loop that retries on timestamp failure rather than failing the whole build. Alternatively, contact your CA’s enterprise support about a dedicated timestamp server for high-volume use.
A simpler mitigation: sign all files in a single signtool invocation rather than one call per file. A single command signing fifty files uses roughly one timestamp request rather than fifty:
| # Sign multiple files in one signtool call (one timestamp request):
signtool sign /a /fd sha256 /tr http://timestamp.digicert.com /td sha256 /v file1.exe file2.exe file3.dll
# Or use a wildcard to sign all .exe files in a directory: signtool sign /a /fd sha256 /tr http://timestamp.digicert.com /td sha256 /v .\release\*.exe |
Fix 5: CI/CD runners and containers without internet access
Cloud CI runners and Docker containers often run in isolated network environments without outbound internet access. This is intentional in some security configurations (air-gapped build environments) but means timestamp servers are unreachable.
For containers: ensure the Docker network or pod network allows outbound HTTPS to the timestamp server hostnames. For isolated build runners: either configure an internal RFC 3161 timestamp server (Windows Server 2012 and later include a built-in TSA via the Active Directory Certificate Services role) or proxy the timestamp requests through an internal server that has internet access.
Signing without a timestamp (/tr omitted) solves the immediate build failure but creates a worse long-term problem: the signature expires when the certificate expires, typically within 460 days. Any user who verifies the signature after that date will see an invalid signature. Never ship software signed without a timestamp. Fix the timestamp connectivity instead.
Scenario B: Cloud HSM Signing Service Unreachable
Cloud signing services (SSL.com eSigner, DigiCert KeyLocker/smctl, Microsoft Trusted Signing) require the signing client to reach the signing API over HTTPS. If the API is unreachable, the private key operation cannot be performed and signing fails before any file is modified.
Fix 1: Verify credentials haven’t expired
The most common non-network cause of cloud signing failures is expired or rotated credentials. API tokens, client certificates, and TOTP secrets used to authenticate to signing services all have lifetimes. An expired credential produces a connection-failure-style error because the API rejects the authentication before any signing operation begins.
- DigiCert KeyLocker (smctl): confirm the API token is current in your DigiCert ONE portal. Tokens can be set to expire; if a token expired since the pipeline last ran, re-generate and update the pipeline secret.
- com eSigner: verify username, password, credential ID, and TOTP secret are current. TOTP secrets are time-sensitive; ensure the signing machine’s clock is synchronized.
- Microsoft Trusted Signing: confirm the Azure service principal credentials or managed identity configuration are current and the certificate profile is still active in the Azure portal.
Fix 2: Check the service status page
Cloud signing services occasionally have outages. Before spending time troubleshooting network access, check whether the service itself is reporting an incident:
- DigiCert: status.digicert.com
- com: check ssl.com for status announcements
- Microsoft Azure (for Trusted Signing): status.azure.com
If the service reports degraded or unavailable status, the fix is to wait for the outage to resolve. An in-progress build failure due to a service outage is not a configuration problem.
Fix 3: Firewall and proxy blocking the signing API
Corporate environments that restrict outbound HTTPS will block cloud signing service APIs the same way they block timestamp servers. The relevant hostnames vary by service:
- DigiCert KeyLocker: one.digicert.com and related one.digicert.com subdomains
- com eSigner: ssl.com API endpoints
- Microsoft Trusted Signing: *.codesigning.azure.net and Azure identity endpoints
Test connectivity to the relevant API hostname (Invoke-WebRequest or curl) from the build machine before assuming the signing service or credentials are the problem. If the test fails, work with your network team to allowlist the necessary hostnames.
Fix 4: VPN routing issues
If signing works without a VPN connected but fails with VPN active, the VPN is routing API traffic through a path that blocks it. Split-tunnel VPN configurations sometimes route certain traffic through the VPN endpoint in a way that blocks direct internet access to cloud service APIs. Check with your VPN administrator whether the VPN policy needs an exception for the signing service’s API endpoints.
Quick Reference
| Symptom | Most likely cause | First fix to try |
| Timestamp server unreachable on a single machine | Firewall blocking outbound HTTP | Test with Invoke-WebRequest, then check netsh winhttp proxy settings |
| Timestamp fails in CI/CD pipeline but works locally | Build runner without internet access | Allow outbound HTTPS from the runner to timestamp server hostnames |
| Timestamp fails intermittently on large builds | Rate limiting from many rapid requests | Sign all files in a single signtool invocation; try alternative timestamp server |
| Cloud HSM signing fails immediately | Expired credentials or service outage | Check service status page first; verify credential expiry in the provider portal |
| Cloud HSM fails only with VPN active | VPN routing blocking API access | Add signing service API hostnames to VPN split-tunnel exceptions |
| Signing works once then fails on next run | API token expired between runs | Re-generate API token; update pipeline secret; check token expiry settings |
Frequently Asked Questions
Can I sign without contacting any external server?
For timestamp-only failures: yes, by omitting the /tr flag, but the resulting signature will expire with the certificate. This is only acceptable for internal use where you control all the machines that will verify the signature and can ensure verification happens before expiry. For production software distributed to end users, always timestamp.
For cloud HSM signing failures: no. If your private key is in a cloud HSM (eSigner, KeyLocker, Trusted Signing), the signing operation physically requires reaching the cloud API. There is no offline fallback. If cloud signing is a hard requirement for your pipeline, build in retry logic with exponential backoff to handle transient failures gracefully.
Why does the error say ‘server’ when it’s a timestamp issue?
The RFC 3161 timestamp service is technically a server that your signing tool contacts to obtain a signed timestamp token. signtool and related tools refer to it as the timestamp server, which is accurate. The same error message pattern appears for cloud HSM signing service failures because both involve contacting a remote server over the network. The error text alone doesn’t distinguish between them, which is why checking the /v verbose output for the specific URL or service name is the correct diagnostic first step.
What’s the difference between /tr and /t in signtool?
/t is the legacy timestamp flag using RFC 2630 Authenticode timestamp format. /tr is the modern flag using RFC 3161 timestamp format, and /td specifies the digest algorithm for the RFC 3161 timestamp. Use /tr with /td sha256 for all current signing operations. The /t flag should be considered deprecated; some timestamp servers no longer accept /t requests. If you have old signing scripts still using /t, migrating to /tr /td sha256 is worthwhile.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.