Reference Materials
This page compiles reference information shared by different integration methods for the sslTrus remote code signing service, including:
- Code signing quota calculation rules.
- Authenticode and RFC 3161 timestamp protocols.
- Commonly used code signing timestamp servers.
- Considerations when choosing a timestamp service in production environments.
Signing Quota Calculation
The signing quota is calculated based on actual completed signing actions.
Simple explanation:
一个文件成功完成一次签名 = 一次签名次数
The number of signatures 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 if all three files are signed separately, then:
签名次数 = 3 次
Basic Rules
The number of signatures mainly depends on:
- Which files or objects are ultimately signed.
- How many signatures are actually completed for each object.
- Whether standard client signing is used, or low-level signing invocation methods such as KSP or Jarsigner.
- Whether the build tool automatically signs additional EXEs, DLLs, uninstallers, or installation packages.
Common signing objects include:
.exe.dll.msi.msp.sys.cat.jar- Uninstaller, for example
uninstall.exe
As long as an object actually completes one successful signature, it is counted according to the corresponding counting rules.
Counting Only on Success
Signatures are counted only when the remote code signing service successfully completes the signing.
The following situations are generally not counted:
- Authentication failure.
- Parameter errors.
- Certificate unavailable.
- Network request failure.
- The server does not successfully return a signing result.
- Querying certificates.
- Querying signing 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 the file locally, adding a timestamp, or performing subsequent processing, the already 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 signing counts
Adding timestamp → does not generate additional signing counts
Verifying signature → does not generate signing counts
Whether the timestamping service is successful only affects the timestamp result in the final signed file; it does not mean that code signing was performed an additional time.
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
Regular CLI dual signing is calculated as one client signing task:
GUI / SignTool CLI 双签 = 1 次
This is where the standard client signing process is most easily confused with the underlying KSP signing call.
Windows KSP
KSP is the Windows CNG Provider integration method.
When Microsoft SignTool, MSBuild, Visual Studio, Electron packaging tools, or other Windows software invoke remote code signing through KSP, the counting is closer to:
底层远程私钥签名调用次数
For example:
| Operation | Number of signatures |
|---|---|
Perform one SHA256 signature on app.exe | 1 |
| Perform SHA256 first, then append SHA1 | 2 |
Sign app.exe, helper.dll, and uninstall.exe separately | 3 |
Therefore:
SignTool CLI 双签 = 1 次
KSP 双签 = 2 次
If the 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 called by Microsoft SignTool or other Windows applications through the Provider to invoke the remote signing service.
When determining the number of signing operations, base the count on the actual remote private key signing operations that occur.
If the 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 | Signing Count |
|---|---|
Signing app.jar | 1 time |
| Signing 3 JARs separately | 3 times |
| Signing the same JAR again | Add 1 more time |
jarsigner -verify | 0 times |
| Generating a keystore for verification | 0 times |
Therefore:
每个 JAR 每次成功完成签名 = 1 次
Installation package
The installation package requires distinguishing between:
- The executable file inside the installation package.
- 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 targets include:
- Main executable
.exe - DLL
- Updater
- Uninstaller
- Installer package
.exe - MSI
- Other auxiliary executable files
For example:
| Artifact | Number of Signatures |
|---|---|
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 artifacts signed and the number of signing operations performed on each artifact.
If Electron uses KSP and performs dual signing on the same file, that file may also incur two remote signing operations.
Quick Assessment
When 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. 构建工具有没有自动签额外文件？
Simply put:
签名次数 = 成功完成的签名动作数量之和
Special notes:
GUI / SignTool CLI 双签 = 1 次
KSP 对同一个文件执行两次底层签名 = 2 次
Jarsigner 每个 JAR 每次成功签名 = 1 次
时间戳 = 0 次
验证签名 = 0 次
Timestamp Server
Code signing typically also utilizes timestamp services.
A timestamp can prove that a digital signature already existed at a specific time, enabling the verifying party to judge the validity of the signature by combining the signing certificate, timestamp certificate, revocation status, and validation policy.
Two timestamp protocols are commonly used in code signing:
| Protocol | Description |
|---|---|
| Authenticode | Microsoft's legacy timestamp protocol, mainly used for compatibility with older Windows code signing workflows |
| RFC 3161 | A universal timestamp protocol suitable for modern code signing scenarios |
Modern code signing scenarios typically prioritize RFC 3161.
RFC 3161
An RFC 3161 timestamp request sends the digest of the data to be timestamped, rather than the original file.
Basic workflow:
代码签名
↓
计算待时间戳数据摘要
↓
发送摘要到 TSA
↓
TSA 返回时间戳令牌
↓
写入最终签名
Timestamp tokens typically contain:
- The data digest.
- The timestamp issuance time.
- The TSA policy.
- The 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 from the respective providers.
Microsoft
http://timestamp.acs.microsoft.com
Primarily used for RFC 3161 timestamping.
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 policy.
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
Supports:
- Authenticode
- RFC 3161
Certum's official code signing documentation covers Windows and Java JAR signing scenarios.
GlobalSign
http://timestamp.globalsign.com/tsa/r45standard
The current GlobalSign code signing documentation uses this RFC 3161 timestamp URL.
It is not recommended to continue using legacy GlobalSign URLs that are no longer listed in the current official code signing documentation.
SSL.com
http://ts.ssl.com
Supports RFC 3161 but 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 capability confirmed by the corresponding provider's public documentation.
Timestamp service policies may change, and the provider's current official documentation should be rechecked before production configuration.
Restricted timestamp services
Some timestamp servers provide RFC 3161 services but cannot be used directly as anonymous public TSAs.
QuoVadis
Publicly available RFC 3161 addresses include:
http://ts.quovadisglobal.com/eu
http://ts.quovadisglobal.com/ch
This service requires pre-registration of 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 in the Apple code signing ecosystem.
It should not be directly used as a general-purpose timestamp server for Windows Authenticode.
Test timestamp services
Certain public RFC 3161 services are better suited for protocol testing rather than being directly used as production code signing TSAs.
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 is trusted.
In production environments, validate signed artifacts using the target platform's actual verification process.
Production Environment Checks
Before adding a timestamp server to the production configuration, it is recommended to confirm at least the following:
- The service provider's official documentation explicitly publishes this endpoint.
- The service provider explicitly supports the required timestamp protocol.
- A SHA-256 or stronger timestamp digest algorithm is used.
- The target system can validate the TSA's complete certificate chain.
- DNS, proxies, firewalls, and egress networks can reliably access the TSA.
- Authentication methods, rate limits, regional restrictions, and terms of service have been confirmed.
- Verification tests have been completed using actual signed artifacts.
Do not rely solely on:
浏览器可以打开
HTTP 返回 200
Determine whether a Timestamp Authority (TSA) is suitable for code signing.
You must use the actual signing tool to send a timestamp request and perform validation on the final artifact.
Timestamp Selection Recommendations
For modern Windows SHA-2 code signing, it is generally preferable to choose a timestamp service that supports RFC 3161.
For example:
Microsoft
Sectigo
DigiCert
Certum
GlobalSign
The final choice should take into account:
- Target operating system.
- Signing tool.
- TSA certificate chain.
- Network reachability.
- Regional restrictions.
- Call frequency limits.
- Terms of service.
- Service level agreement.
- Actual signed artifact verification results.
If the certificate provider has explicit requirements for the timestamp service, the corresponding certificate policy and provider requirements should be followed as a priority.
Related integration methods
Different integration methods use the signing count and timestamp rules on this page:
| Usage scenario | Documentation |
|---|---|
| SignTool CLI | Client tools |
| Windows KSP / CSP | Windows Provider |
| Jarsigner | Java integration |
| GitHub Actions, Electron Builder, Advanced Installer | CI/CD and build tools |
| Directly calling the remote signing API | API integration |