Skip to main content

Global Code Signing Timestamp Servers

Document Scope​

This document consolidates timestamp services applicable to code signing, with emphasis on Microsoft Authenticode and RFC 3161 scenarios.

  • Verification date: 2026-06-18.
  • Only addresses that can be confirmed from official provider materials are listed as public endpoints.
  • This document is not an exhaustive list of all timestamp services worldwide. Services that are not publicly exposed, require commercial activation, or are offered only as on-premises products are noted separately.
  • Timestamp service availability, certificate chains, and access policies may change; re-check the provider's latest documentation before production configuration.

Timestamp Protocols​

Code signing commonly involves two types of timestamp protocols:

ProtocolDescription
AuthenticodeMicrosoft's legacy timestamp protocol, primarily used for compatibility with legacy Windows code signing workflows.
RFC 3161A general-purpose timestamp protocol suitable for modern code signing scenarios; prefer it in 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, signing time, policy, and the TSA's signature. A timestamp can prove that a signature existed at a specific point in time, but whether the signature remains valid over the long term still depends on the signing certificate, the timestamp certificate, revocation status, and verifier policy.

Public Code Signing Timestamp Endpoints​

The following addresses are explicitly documented in current official materials and can serve as code signing candidates. "Public" in the table means the endpoint is officially published; it does not imply that the provider guarantees unlimited, unconditional, or permanently free usage.

ProviderAddressAuthenticodeRFC 3161Access NotesOfficial Materials
Microsoft Artifact Signinghttp://timestamp.acs.microsoft.comNot confirmed✅Microsoft recommends this TSA for Artifact Signing users. Suitable as a Windows RFC 3161 candidate.Microsoft Artifact Signing
Sectigohttp://timestamp.sectigo.com✅✅The same address supports both Authenticode and RFC 3161. Official guidance requires at least 15 seconds between requests for batch calls.Sectigo Time Stamp Server
DigiCerthttp://timestamp.digicert.comNot confirmed✅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/r45standardNot confirmed✅GlobalSign's current code signing documentation uses this R45 address.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 support only RSA timestamps can evaluate the /legacy address per the official documentation.SSL.com Using Your Code Signing Certificate

For SHA-2 code signing, it is recommended to 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 compatibility with common Windows code signing scenarios and does not constitute a guarantee of service quality, legal validity, or commercial grade. In production environments, selection 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 has published 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 first, so it cannot be used as an anonymous public TSA. Authorization must be completed before integration, and the selected policy and certificate chain must be confirmed to meet the target validation environment.

Official documentation: DigiCert/QuoVadis Timestamp Server

Apple​

Apple operates its own timestamp PKI and publicly discloses the Apple Timestamp CA and related CPS. http://timestamp.apple.com/ts01 is used within 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, the timestamp certificate chain should be verified in the target validation environment.

ProviderAddressScopeLimitationsOfficial documentation
MeSignhttp://tsa.mesign.comDocument signing, electronic data attestation, and RFC 3161 protocol trialThe official free trial service targets Adobe document timestamps, limited to 20 requests per IP per day. Code signing compatibility needs separate verification.MeSign TSA
FreeTSAhttps://freetsa.org/tsrRFC 3161 protocol testing, general data and code timestampingFree public service using its own CA and TSA certificates; should not assume default trust by target operating systems or code signing validators.FreeTSA

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

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

  • 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 public product pages typically 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 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 r45standard address should be used instead.
  • StartSSL: http://tsa.startssl.com/rfc3161 has no confirmable current official service information and should no longer be used.
  • nCipher example address: http://dse200.ncipher.com/TSS/HttpTspServer is closer to a historical demo or test system and has no current public production service basis.
  • Addresses with unclear origin and operation 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: These can be used for protocol testing, but there is insufficient code signing production assurance information, so they are not recommended as production default services.

Production Integration Checks​

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

  1. The provider's official documentation clearly publishes the endpoint and supported protocols.
  2. Use the correct timestamp protocol; addresses supporting only RFC 3161 must not be used 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 signature algorithm and key type.
  4. Verify the full timestamp certificate chain in the target Windows, macOS, or other validation environments.
  5. Confirm that outbound network, proxy, firewall, and DNS can reliably reach the endpoint.
  6. Confirm the authentication method, rate limits, terms of service, regional restrictions, and SLA.
  7. Perform signature verification with actual signed artifacts; TSA availability cannot be determined solely by browser access or HTTP status codes.

Reference Standards​

Last updated on