Reference Materials

This page organizes the reference information shared by sslTrus remote code signing services across different integration methods, including:

• Rules for calculating code signing counts.
• Authenticode and RFC 3161 timestamp protocols.
• Commonly used code signing timestamp servers.
• Considerations when selecting a timestamp service in production environments.

Signing Count Calculation

Signing counts are calculated based on the actual completed signing actions.

Simple understanding:

一个文件成功完成一次签名 = 一次签名次数

The number of signing operations is not calculated based on the number of source code files, nor is it calculated based on a single build, a single packaging, or a single CI/CD pipeline.

For example:

100 个源代码文件
        ↓
编译生成 1 个 app.exe
        ↓
app.exe 成功签名一次
        ↓
1 次签名

If a single build produces:

app.exe
helper.dll
installer.msi

And all three files are signed separately, then:

签名次数 = 3 次

Basic Rules

The signature count mainly depends on:

1. Which files or objects are ultimately signed.
2. How many signatures are actually completed for each object.
3. Whether standard client signing is used, or low-level signature invocation methods such as KSP or Jarsigner.
4. Whether the build tool automatically signs additional EXEs, DLLs, uninstallers, or installation packages.

Common signing objects include:

• .exe
• .dll
• .msi
• .msp
• .sys
• .cat
• .jar
• Uninstallers, for example uninstall.exe

As long as an object actually completes one signature successfully, it is counted according to the corresponding counting rules.

Only Successful Signatures Are Counted

A signature count is generated only when the remote code signing service successfully completes a signature.

The following situations are generally not counted:

• Authentication failure.
• Parameter errors.
• Certificate unavailability.
• Network request failure.
• The server did not successfully return a signing result.
• Querying certificates.
• Querying signature records.
• Verifying signatures.
• Removing existing signatures.
• Generating verification files.

If the remote service has successfully returned a signing result, but the client subsequently fails while writing files locally, adding a timestamp, or performing follow-up processing, the completed remote signature is still counted as a successful signature.

Timestamps Are Not Counted Separately

Timestamps are used to prove that a signature already existed at a specific time and do not constitute a new code signing operation.

Therefore:

Code signing      → generates signature count
Adding timestamp  → does not generate additional signature count
Verifying signature → does not generate signature count

Whether the timestamping service succeeds only affects the timestamp result of the final signed file; it does not mean an additional code signing operation was performed.

SignTool CLI

Use the sslTrus SignTool CLI:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe

If the signature is successful:

1 个文件 × 1 次成功签名 = 1 次

For example:

signtool sign --cert-code CERT_CODE --file app.exe
signtool sign --cert-code CERT_CODE --file helper.dll
signtool sign --cert-code CERT_CODE --file installer.msi

All three files succeeded:

合计 = 3 次

SignTool CLI Dual Signing

If you use the standard SignTool CLI to enable both SHA-1 and SHA-2 simultaneously:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --sha1=true \
  --sha2=true

Ordinary CLI dual signing is calculated as one client signing task:

GUI / SignTool CLI 双签 = 1 次

This is the most confusing point when distinguishing the standard client signing process from the underlying KSP signing invocation.

Windows KSP

KSP refers to the Windows CNG Provider integration approach.

When Microsoft SignTool, MSBuild, Visual Studio, Electron packaging tools, or other Windows software invoke remote code signing through KSP, the usage counting is closer to:

底层远程私钥签名调用次数

For example:

Operation	Number of signatures
Perform one SHA256 signature on app.exe	1 time
Perform SHA256 first, then append SHA1	2 times
Sign app.exe, helper.dll, and uninstall.exe separately	3 times

Therefore:

SignTool CLI 双签 = 1 次
KSP 双签          = 2 次

If a tool performs multiple underlying signing operations on the same file, each successful remote signing is counted separately.

CSP

CSP is the traditional Windows CryptoAPI Provider.

CSP is also invoked by Microsoft SignTool or other Windows applications through the Provider to call the remote signing service.

When determining the number of signatures, base it on the actual remote private key signing operations that occur.

If a tool signs multiple files separately or signs the same file multiple times, each operation should be counted separately.

Jarsigner

When using the sslTrusJarsigner Provider, the standard jarsigner calls the remote code signing service during the signing process.

Generally:

Operation	Number of signatures
Sign app.jar	1
Sign 3 JARs separately	3
Sign the same JAR once more	Add 1 more
jarsigner -verify	0
Generate a keystore for verification	0

Therefore:

每个 JAR 每次成功完成签名 = 1 次

Installation Package

The installation package needs to distinguish between:

1. The executable file inside the installation package.
2. The installation package itself.

For example:

app.exe       → signed 1 time
installer.msi → signed 1 time

Then:

合计 = 2 次

If there are other files:

File	Signed	Number of Signatures
app.exe	Yes	1
helper.dll	Yes	1
driver.sys	Yes	1
installer.msi	Yes	1
Total		4

The number of source code files, resource files, images, or configuration files included in the installation package does not directly affect the number of signatures.

The key point is:

最终到底有哪些产物被实际签名

Electron

Desktop application build tools such as Electron Builder and Electron Forge may automatically sign multiple files during a single packaging process.

Common objects include:

• Main program .exe
• DLL
• Updater
• Uninstaller
• Installation package .exe
• MSI
• Other auxiliary executable files

For example:

Artifact	Signing Count
MyApp.exe	1
ffmpeg.dll	1
update.exe	1
uninstall.exe	1
MyApp Setup.exe	1
Total	5

Therefore:

一次 Electron Build ≠ 一次签名

The calculation should be based on the actual number of signed artifacts and the number of signing operations performed on each artifact.

If Electron uses a KSP and performs dual signing on the same file, that file may also generate two remote signing operations.

Quick Assessment

If you are unsure how many signing operations a build will generate, you can check the following in order:

1. 最终有哪些文件被签名？
2. 每个文件签了几次？
3. 使用的是 SignTool CLI 还是 KSP / Jarsigner？
4. 构建工具有没有自动签额外文件？

It can be simply understood as:

签名次数 = 成功完成的签名动作数量之和

Special notes:

GUI / SignTool CLI 双签                = 1 次
KSP 对同一个文件执行两次底层签名       = 2 次
Jarsigner 每个 JAR 每次成功签名         = 1 次
时间戳                               = 0 次
验证签名                             = 0 次

Timestamp Server

Code signing typically uses a timestamp service as well.

A timestamp proves that a digital signature existed at a specific time, allowing the verifier to determine the validity of the signature by combining the signing certificate, timestamp certificate, revocation status, and validation policy.

There are two common timestamp protocols for code signing:

Protocol	Description
Authenticode	Microsoft's traditional timestamp protocol, primarily used for compatibility with legacy Windows code signing processes
RFC 3161	A general-purpose timestamp protocol suitable for modern code signing scenarios

Modern code signing scenarios generally prefer RFC 3161.

RFC 3161

An RFC 3161 timestamp request sends the digest of the data to be timestamped, rather than the original file.

Basic process:

代码签名
   ↓
计算待时间戳数据摘要
   ↓
发送摘要到 TSA
   ↓
TSA 返回时间戳令牌
   ↓
写入最终签名

Timestamp tokens typically include:

• Data digest.
• Timestamp issuance time.
• TSA policy.
• TSA digital signature.

The timestamp server does not consume additional sslTrus code signing quota for adding timestamps.

Common Timestamp Servers

The following endpoints apply to common code signing scenarios.

Before production use, reconfirm the latest official documentation, service policies, and availability of the corresponding provider.

Microsoft

http://timestamp.acs.microsoft.com

Primarily used for RFC 3161 timestamps.

Suitable as a timestamp candidate for modern Windows code signing scenarios.

Example:

--timestamp-rfc3161=http://timestamp.acs.microsoft.com

Microsoft SignTool:

/tr http://timestamp.acs.microsoft.com
/td SHA256

Sectigo

http://timestamp.sectigo.com

Supports:

• Authenticode
• RFC 3161

Can be used with Windows and other code signing tools that support the corresponding protocols.

Sectigo has service-side usage requirements for bulk calls. Production systems should control call frequency according to its current official policies.

DigiCert

http://timestamp.digicert.com

Supports RFC 3161 and can be used in code signing scenarios such as Microsoft Authenticode.

Certum

http://time.certum.pl

Supported:

• Authenticode
• RFC 3161

Certum official code signing materials cover Windows and Java JAR signing scenarios.

GlobalSign

http://timestamp.globalsign.com/tsa/r45standard

The current GlobalSign code signing documentation uses this RFC 3161 timestamp address.

Using historical GlobalSign addresses that are no longer in the current official code signing documentation is not recommended.

SSL.com

http://ts.ssl.com

Supports RFC 3161 and does not support the legacy Authenticode timestamp protocol.

If the target signing tool or legacy system has compatibility restrictions on the key algorithm used by the TSA, actual validation should be performed before production integration.

Timestamp Server Comparison

Provider	Address	Authenticode	RFC 3161
Microsoft	http://timestamp.acs.microsoft.com	Unconfirmed	Supported
Sectigo	http://timestamp.sectigo.com	Supported	Supported
DigiCert	http://timestamp.digicert.com	Unconfirmed	Supported
Certum	http://time.certum.pl	Supported	Supported
GlobalSign	http://timestamp.globalsign.com/tsa/r45standard	Unconfirmed	Supported
SSL.com	http://ts.ssl.com	Not supported	Supported

"Supported" in the table describes the protocol capabilities confirmed by the corresponding provider's public documentation.

Timestamp service policies may change, and the provider's current official documentation should be re-verified before production configuration.

Restricted Timestamp Services

Some timestamp servers provide RFC 3161 services but cannot be used directly as anonymous public TSAs.

QuoVadis

Public RFC 3161 addresses include:

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

This service requires pre-registering the caller's egress IP, so the corresponding authorization must be completed before integration.

Apple

http://timestamp.apple.com/ts01

Belongs to the timestamp service used by the Apple code signing ecosystem.

It should not be directly used as a general-purpose timestamp server for Windows Authenticode.

Test timestamp service

Some public RFC 3161 services are more suitable for protocol testing rather than being directly used as a production code signing TSA.

For example:

https://freetsa.org/tsr

Such services may use their own CA and TSA certificates.

Therefore, it cannot be assumed that:

Windows
macOS
Java
其他代码签名验证器

By default, its certificate chain will be trusted.

In production environments, you should use the target platform to actually verify the signed artifacts.

Production environment checks

Before adding a timestamp server to a production configuration, it is recommended to confirm at least the following:

1. The service provider's official documentation explicitly publishes this endpoint.
2. The service provider explicitly supports the required timestamp protocol.
3. A SHA-256 or stronger timestamp digest algorithm is used.
4. The target system can validate the TSA's complete certificate chain.
5. DNS, proxies, firewalls, and egress networks can reliably access the TSA.
6. The authentication method, rate limits, regional restrictions, and terms of service have been confirmed.
7. Verification testing has been completed using actual signed artifacts.

Do not rely solely on:

浏览器可以打开
HTTP 返回 200

Determine whether the timestamp server is suitable for code signing.

You must use the actual signing tool to send a timestamp request and verify the final artifact.

Timestamp selection recommendations

For modern Windows SHA-2 code signing, it is usually preferable to choose a timestamp service that supports RFC 3161.

For example:

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

The final choice should take the following into account:

• Target operating system.
• Signing tool.
• TSA certificate chain.
• Network reachability.
• Regional restrictions.
• Call frequency limits.
• Terms of service.
• Service level agreement.
• Actual verification results of signed artifacts.

If the certificate provider has explicit requirements for the timestamp service, the corresponding certificate policy and provider requirements should be followed first.

Related integration methods

Different integration methods use the signing count and timestamp rules on this page:

Use case	Documentation
SignTool CLI	Client tools
Windows KSP / CSP	Windows Provider
Jarsigner	Java integration
GitHub Actions, Electron Builder, Advanced Installer	CI/CD and build tools
Direct calls to the remote signing API	API integration