Client Tools

sslTrus provides command-line clients and desktop clients for connecting to the remote code signing service and completing file signing.

Among them, SignTool CLI is suitable for command-line, scripting, and automation scenarios; macOS users can also install and update SignTool CLI or the desktop client via Homebrew.

SignTool CLI

SignTool CLI is a remote code signing command-line client provided by sslTrus. The executable file name after installation is signtool.

It mainly provides the following capabilities:

Function	Command	Description
File signing	signtool sign	Performs remote code signing on local files
Signing quota	signtool quota	Queries the remaining and total signing quota of the certificate
Client update	signtool update	Queries and installs the latest client for the current platform
Windows KSP	signtool ksp	Installs and manages the Windows Key Storage Provider
Windows CSP	signtool csp	Installs and manages the Windows Cryptographic Service Provider

KSP and CSP are Windows Provider integration methods. For specific usage, please refer to Windows Provider.

Download the Client

SignTool CLI can be downloaded from the sslTrus client release page:

sslTrus Client Release Page

The release page provides the latest client installation packages for each platform. Automated scenarios can also query the latest version information through the version index latest.json.

macOS users can also install directly via Homebrew, see macOS Homebrew below.

View Client Information

After installation, you can run:

signtool --help

View command help.

Check the current client version:

signtool --version

The version information includes the client version, build revision, runtime platform, and build time.

Access Credentials

Before using the remote code signing service, you need to prepare:

• Access Key
• Access Secret
• Cert Code

The Access Key and Access Secret are used to access the remote code signing service, while the Cert Code is used to specify the code signing certificate that actually performs the signing.

SignTool CLI can provide credentials via command-line parameters or read them from environment variables:

export ACCESS_KEY="your-access-key"
export ACCESS_SECRET="your-access-secret"

It is recommended to provide the Access Secret primarily through environment variables, CI/CD Secrets, or other secure credential management methods.

Do not expose the Access Secret by:

• Committing it to a Git repository.
• Writing it into public scripts.
• Outputting it to build logs.
• Sending it to untrusted third-party systems.

Remote Service Address

By default, SignTool CLI uses the sslTrus production service address and requires no additional configuration.

If you are using the NICSRS (www.nicsrs.com) environment, you need to add --address nicsrs to the command:

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

signtool quota and signtool update also support --address nicsrs.

File Signing

Use signtool sign to directly perform remote code signing on local files.

The most basic signing command:

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

If already configured:

ACCESS_KEY
ACCESS_SECRET

SignTool CLI automatically reads the corresponding access credentials.

Signing is performed with SHA-2 by default.

Specify the Output File

By default, the client does not overwrite the original file directly.

You can specify the signed output file via --out:

signtool sign \
  --cert-code CERT_CODE \
  --file app-unsigned.exe \
  --out app-signed.exe

Overwrite the Original File

If you need to directly modify the original file, you can use:

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

Once --override is enabled, the signature result will be written directly back to the input file.

When used in an automated build environment, confirm whether subsequent steps require the original file or the signed file.

Specify Program Description

You can write a program description and URL into the Authenticode signature:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --desc "Example Application" \
  --url "https://example.com"

SHA-1 and SHA-2

SHA-2 is enabled by default:

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

Use only SHA-1:

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

Enable SHA-1 and SHA-2 simultaneously:

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

SHA-1 is mainly used for compatibility with legacy systems; new projects should generally prioritize SHA-2.

Timestamp

For code signing, it is usually recommended to also add a trusted timestamp.

The SignTool CLI automatically configures a timestamp service for signing by default, and you can also specify a timestamp server via parameters:

• --timestamp-rfc3161: The RFC 3161 timestamp server used for SHA-2 signing.
• --timestamp: The Authenticode timestamp server used for SHA-1 signing.

Specify the RFC 3161 timestamp server:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --timestamp-rfc3161=http://timestamp.acs.microsoft.com

Specify the Authenticode timestamp server:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --timestamp=http://timestamp.sectigo.com

If you need to disable the corresponding timestamp, you can set the parameter value to empty:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --timestamp-rfc3161= \
  --timestamp=

For information about the timestamp protocol, server address, and selection recommendations, please refer to the Reference Materials.

Query Signature Quota

Usage:

signtool quota

You can query the quota of code signing certificates visible to the current access credential.

The output includes:

• Certificate number.
• Certificate information.
• Remaining signing count.
• Total signing count.

If JSON format output is needed:

signtool quota --json

You can also use the abbreviation:

signtool quota -j

The specific calculation method for signature counts may vary depending on how the CLI, KSP, Jarsigner, or build tools are invoked. For detailed rules, please refer to Signature Count Calculation Guide.

Updating the Client

SignTool CLI supports querying and installing the latest version for the current platform:

signtool update

During the update process, the size and SHA-256 of the downloaded file are verified to ensure the integrity of the client file.

If the SignTool CLI was installed via Homebrew, it is recommended to continue managing the version through Homebrew, rather than mixing two update methods simultaneously.

macOS Homebrew

macOS users can install the SignTool CLI or the desktop client via the official sslTrus Homebrew Tap.

Public repository: ssltrus-official/homebrew-tap

Installing the Homebrew Tap

Run:

brew tap ssltrus-official/tap
brew trust ssltrus-official/tap

Once completed, you can install the corresponding client.

Install SignTool CLI

Execute:

brew install ssltrus-official/tap/code-sign-cli

After installation, you can run:

signtool --version

Confirm that the client is installed properly.

The package name in Homebrew is:

code-sign-cli

The actual command-line program name installed is:

signtool

Installing the Desktop Client

Install the sslTrus code signing desktop client:

brew install --cask ssltrus-official/tap/code-sign-gui

The corresponding Homebrew Cask name is:

code-sign-gui

Updating the client

If the client is installed via Homebrew, it is recommended to upgrade using Homebrew.

First, update the Homebrew package information:

brew update

Upgrade SignTool CLI:

brew upgrade ssltrus-official/tap/code-sign-cli

Upgrade the desktop client:

brew upgrade --cask ssltrus-official/tap/code-sign-gui

This ensures that the locally installed version stays consistent with the Homebrew package metadata.

Windows Provider

If your scenario does not involve calling the SignTool CLI directly, but you instead want Microsoft SignTool, Visual Studio, MSBuild, Advanced Installer, or other Windows software to directly use the remote code signing private key, you should use the Windows Provider.

sslTrus offers:

• KSP (Key Storage Provider): For Windows CNG.
• CSP (Cryptographic Service Provider): For the legacy Windows CryptoAPI.

Refer to Windows Provider.

CI/CD Automatic Signing

If you need to perform signing during continuous integration or automated build processes, manual installation and invocation of the SignTool CLI are not necessarily required.

For example, GitHub Actions can use the sslTrus Code Sign Action directly:

- name: Sign files
  uses: ssltrus-official/code-sign-action@v1
  with:
    access-key: ${{ secrets.SSLTRUS_ACCESS_KEY }}
    access-secret: ${{ secrets.SSLTRUS_ACCESS_SECRET }}
    cert-code: ${{ secrets.SSLTRUS_CERT_CODE }}
    files: build/app.exe

GitHub Action supports Linux, macOS, and Windows runners, and can directly complete remote code signing for specified files within the build pipeline.

Public repository: ssltrus-official/code-sign-action

For full configuration, please refer to CI/CD and Build Tools.

How to choose

You can select the appropriate client or integration method based on your actual usage:

Scenario	Recommended method
Manually sign files in the terminal	SignTool CLI
Batch-invoke signing with scripts	SignTool CLI
Check code signing quota	SignTool CLI
Install and update CLI on macOS	Homebrew
Use desktop client on macOS	Homebrew
Microsoft SignTool or other Windows software directly invoking remote private keys	KSP
Legacy CryptoAPI software	CSP
Automatic signing with GitHub Actions	GitHub Actions
Developing your own signing client	Remote Code Signing API

If your application already supports Windows KSP, CSP, or other standard providers, you should generally prioritize the corresponding standard integration method; if you need direct control over the signing process, you can use the SignTool CLI or the Remote Code Signing API.