Skip to main content

Global Code Signing Timestamp Servers

Document Scope​

This document compiles timestamp services applicable to code signing, with a focus on Microsoft Authenticode and RFC 3161 scenarios.

  • Verification date: 2026-06-18.
  • Only addresses that can be confirmed from the provider's official materials are listed as public endpoints.
  • This document is not an exhaustive list of all timestamp services worldwide. Services with unpublished endpoints, requiring commercial activation, or only offering on-premises deployment products are noted separately.
  • The availability, certificate chains, and access policies of timestamp services may change; you should recheck the latest provider documentation before production configuration.

Timestamp Protocols​

There are two common timestamp protocols for code signing:

ProtocolDescription
AuthenticodeMicrosoft's legacy timestamp protocol, primarily used for compatibility with older Windows code signing workflows.
RFC 3161A universal timestamp protocol suitable for modern code signing scenarios, and is the preferred choice for production environments.

An RFC 3161 request sends the digest of the data to be timestamped, rather than the original file. The TSA returns a timestamp token containing the digest, issuance time, policy, and TSA signature. A timestamp can prove that a signature existed at a specific time, but whether the signature remains valid long-term still depends on the signing certificate, timestamp certificate, revocation status, and the relying party's policy.

Public Code Signing Timestamp Endpoints​

The addresses below are all explicitly documented in current official materials and can be used as candidates for code signing. "Public" in the table only means the endpoint has been officially published, and does not mean the provider commits to unlimited, unconditional, or permanently free use.

ProviderAddressAuthenticodeRFC 3161Access InstructionsOfficial Material
Microsoft Artifact Signinghttp://timestamp.acs.microsoft.comUnconfirmed✅Microsoft recommends that Artifact Signing users use this TSA. Suitable as a Windows RFC 3161 candidate.Microsoft Artifact Signing
Sectigohttp://timestamp.sectigo.com✅✅The same address supports both Authenticode and RFC 3161. The official requirement is that there must be at least a 15-second interval between requests during bulk calls.Sectigo Time Stamp Server
DigiCerthttp://timestamp.digicert.comUnconfirmed✅Officially specified for Microsoft Authenticode RFC 3161 timestamping.DigiCert RFC 3161 TSA
Certumhttp://time.certum.pl✅✅Certum's official code signing documentation uses this address for Windows code signing and Java JAR signing.Certum Code Signing
GlobalSignhttp://timestamp.globalsign.com/tsa/r45standardUnconfirmed✅GlobalSign currently uses this R45 address in its code signing documentation.GlobalSign Code Signing in Windows
SSL.comhttp://ts.ssl.com❌✅Supports RFC 3161 only. The default timestamp may use an ECDSA key; legacy tools that only support RSA timestamps can evaluate the /legacy address per official guidance.SSL.com Using Your Code Signing Certificate

When working with SHA-2 code signing, it is recommended to evaluate the options in the following order:

  1. Microsoft: A suitable candidate as a Windows RFC 3161 timestamp service.
  2. Sectigo: Supports both Authenticode and RFC 3161.
  3. DigiCert: Officially supports Microsoft Authenticode RFC 3161.
  4. Certum: Its official code signing documentation covers both Windows and Java signing scenarios.
  5. GlobalSign: Use the r45standard address specified in its current official documentation.
  6. SSL.com: Use only when the caller supports RFC 3161 and can verify its timestamp certificate and key type.

This order reflects the degree of compatibility with common Windows code signing scenarios and does not constitute a guarantee of service quality, legal validity, or commercial standing. Selections for production environments should be based on the target operating system, network egress, validation chain, regional reachability, and vendor service agreements.

Restricted or Ecosystem-Specific Services​

QuoVadis​

QuoVadis publishes the following RFC 3161 addresses:

  • http://ts.quovadisglobal.com/eu
  • http://ts.quovadisglobal.com/ch

The official requirement is to register the caller's egress IP with DigiCert in advance, so it cannot be used as an anonymous public TSA. Before integration, you must complete authorization and confirm that the selected policy and certificate chain meet the requirements of the target validation environment.

Official resources: DigiCert/QuoVadis Timestamp Server

Apple​

Apple operates its own timestamp PKI and publishes the Apple Timestamp CA and related CPS. http://timestamp.apple.com/ts01 is intended for the Apple code signing ecosystem and should not be used as a general candidate for Windows Authenticode.

Official resources: Apple PKI

Public or trial RFC 3161 services​

The following services provide public RFC 3161 endpoints, but their usage scope, call quotas, or trust chains are not suitable for general production code signing services. You should check the timestamp certificate chain in the target validation environment before use.

ProviderAddressScope of applicationRestrictionsOfficial resources
MeSignhttp://tsa.mesign.comDocument signing, electronic data evidence preservation, and RFC 3161 protocol trialThe official free trial service is designed for Adobe document timestamps, with a limit of 20 requests per IP per day. Code signing compatibility requires separate verification.MeSign TSA
FreeTSAhttps://freetsa.org/tsrRFC 3161 protocol testing, general data and code timestampingA free public service that uses its own CA and TSA certificates; you should not assume that target operating systems or code signing validators trust it by default.FreeTSA

Services that should not be directly listed as public code signing endpoints​

The following types are different from "directly configurable public code signing TSAs":

  • Entrust: The current official page introduces an on-premises deployed Timestamping Authority product based on RFC 3161/RFC 5816, and does not confirm on that page that http://timestamp.entrust.net/TSS/RFC3161sha2TS is a public code signing endpoint.
  • Commercial TSAs in Chinese Mainland: Vendors such as GDCA, CFCA, Anxin CA, SmartCert, and TrustAsia provide timestamp products or signing tools, but their public product pages usually do not provide a unified production URL that can be called anonymously. You should obtain endpoints, authentication methods, policy OIDs, rate limits, and SLAs through procurement, contracts, or vendor technical support.
  • Sigstore Timestamp Authority: This is a deployable open-source implementation of an RFC 3161 TSA, not equivalent to a fixed global public endpoint.
  • Historical GlobalSign addresses: http://timestamp.globalsign.com/tsa/r6advanced1 and http://rfc3161timestamp.globalsign.com/advanced do not appear in the current GlobalSign code signing documentation; the currently published address r45standard should be used instead.
  • StartSSL: http://tsa.startssl.com/rfc3161 has no verifiable current official service documentation and should no longer be used.
  • nCipher example address: http://dse200.ncipher.com/TSS/HttpTspServer is more consistent with a historical demonstration or test system, and there is no evidence that it operates as a current public production service.
  • Addresses with unclear sources and operating policies: https://ca.signfiles.com/tsa/get.aspx, http://services.globaltrustfinder.com/adss/tsa, and https://tsp.iaik.tugraz.at/tsp/TspRequest lack sufficient current official service descriptions, trust policies, or availability guarantees, and should not be added to production candidate lists.
  • Other research network TSAs: These may be used for protocol testing, but do not have sufficient documentation supporting code signing production use; they are not recommended as default production services.

Production Onboarding Checks​

Before adding a TSA to the default list or production fallback chain, confirm at minimum:

  1. The provider's official documentation clearly publishes the endpoint and supported protocols.
  2. The correct timestamping protocol is used; addresses that only support RFC 3161 must not be used for Authenticode requests.
  3. SHA-256 or stronger timestamp digest algorithms are used, and the target platform is confirmed to be compatible with the TSA's signing algorithm and key type.
  4. Verify the complete timestamp certificate chain in the target Windows, macOS, or other validation environment.
  5. Confirm that the egress network, proxies, firewalls, and DNS can access the endpoint reliably.
  6. Confirm the authentication method, rate limits, terms of service, regional restrictions, and SLA.
  7. Perform signature verification using actual signed artifacts; do not judge TSA availability solely through browser access or HTTP status codes.

Reference Standards​

Last updated on