Skip to main content

Global Code Signing Timestamp Servers

Document Scope​

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

  • Verification date: 2026-06-18.
  • Only addresses that can be confirmed from providers' official documentation are listed as public endpoints.
  • This document is not an exhaustive list of all timestamp services worldwide. Services without public endpoints, services requiring commercial activation, or services offering only on-premises products are described separately.
  • The availability, certificate chains, and access policies of timestamp services may change. Providers' latest documentation should be re-checked 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 preferred for production environments.

An RFC 3161 request sends a digest of the data to be timestamped, not 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 a signature remains valid in the long term still depends on the signing certificate, timestamp certificate, revocation status, and verifier policy.

Public Code Signing Timestamp Endpoints​

The following addresses are explicitly stated in current official documentation and can be used as code signing candidates. "Public" in the table only means that the provider has officially published the endpoint; it does not mean the provider promises unlimited, unconditional, or permanently free use.

ProviderAddressAuthenticodeRFC 3161Access NotesOfficial Documentation
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. Official requirements state that batch calls must have at least 15 seconds between each request.Sectigo Time Stamp Server
DigiCerthttp://timestamp.digicert.comUnconfirmed✅Officially designated 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's current code signing documentation uses this R45 address.GlobalSign Code Signing in Windows
SSL.comhttp://ts.ssl.com❌✅Only RFC 3161 is supported. The default timestamp may use an ECDSA key; older tools that only support RSA timestamps can evaluate the /legacy address according to the official instructions.SSL.com Using Your Code Signing Certificate

For SHA-2 code signing, evaluate in the following order:

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

The order reflects the degree of fit with common Windows code signing scenarios and does not constitute a guarantee of service quality, legal validity, or commercial ranking. Production environments should select based on the target operating system, network egress, validation chain, regional accessibility, 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

Officially, the caller's egress IP must be registered with DigiCert first, so it cannot be used as an anonymous public TSA. Authorization should be completed before integration, and the selected policy and certificate chain should be confirmed to match the target validation environment.

Official documentation: 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 used in the Apple code signing ecosystem and should not be considered a general-purpose candidate for Windows Authenticode.

Official documentation: Apple PKI

Public or trial RFC 3161 services​

The following services provide public RFC 3161 endpoints, but their scope of use, call quotas, or trust chains are not suitable as general-purpose production code signing services. Before use, verify the timestamp certificate chain in the target validation environment.

ProviderAddressApplicable scopeLimitationsOfficial documentation
MeSignhttp://tsa.mesign.comDocument signing, electronic data preservation, and RFC 3161 protocol trialThe official free trial service targets Adobe document timestamps, with a daily limit of 20 requests per IP. Code signing compatibility must be verified separately.MeSign TSA
FreeTSAhttps://freetsa.org/tsrRFC 3161 protocol testing, general-purpose data and code timestampsFree public service using its own CA and TSA certificates; do not assume default trust from target operating systems or code signing validators.FreeTSA

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

The following types differ from "public code signing TSAs that can be directly configured":

  • Entrust: The current official page describes an on-premises 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 mainland China: Vendors such as GDCA, CFCA, Anxin CA, SmartCert, and TrustAsia offer timestamp products or signing tools, but their public product pages generally do not provide a unified production URL that can be called anonymously. Endpoints, authentication methods, policy OIDs, rate limits, and SLAs should be obtained 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 single 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. Use the currently published r45standard address instead.
  • StartSSL: http://tsa.startssl.com/rfc3161 has no verifiable current official service documentation and should not be used.
  • nCipher sample address: http://dse200.ncipher.com/TSS/HttpTspServer is closer to a historical demo or test system and has no basis as a current public production service.
  • Addresses with unclear sources and operational 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 the production candidate list.
  • Other research network TSAs: can be used for protocol testing, but lack sufficient production assurance documentation for code signing, and are not recommended as production default services.

Production Integration Checklist​

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

  1. The provider's official documentation clearly publishes the endpoint and supported protocols.
  2. Use the correct timestamp protocol. Do not use an address that supports only RFC 3161 for Authenticode requests.
  3. Use SHA-256 or a stronger timestamp digest algorithm, and confirm that the target platform is compatible with the TSA's signing algorithm and key type.
  4. Check the complete timestamp certificate chain in the target Windows, macOS, or other verification environment.
  5. Confirm that the egress network, proxy, firewall, and DNS can reliably access the endpoint.
  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 by browser access or HTTP status codes.

Reference Standards​

Last updated on