Client Tools

sslTrus provides a command-line client and a desktop client for connecting to remote code signing services 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 the remote code signing command-line client provided by sslTrus. The executable file name after installation is signtool.

It mainly provides the following capabilities:

Feature	Command	Description
File signing	signtool sign	Performs remote code signing on local files
Signing quota	signtool quota	Queries the certificate's remaining and total signing quota
Client update	signtool update	Queries and installs the latest client for the current platform
Windows KSP	signtool ksp	Installs and manages Windows Key Storage Provider
Windows CSP	signtool csp	Installs and manages 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 Releases page provides the latest client installation packages for each platform. For automation scenarios, you can also query the current 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 is complete, you can run:

signtool --help

View command help.

View the current client version:

signtool --version

Version information includes the client version, build revision, runtime platform, build time, and other details.

Access Credentials

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

• Access Key
• Access Secret
• Certificate Code (Cert Code)

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

The SignTool CLI can provide credentials through command 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 through environment variables, CI/CD Secrets, or other secure credential management methods.

Do not:

• Commit the Access Secret to a Git repository.
• Write it in public scripts.
• Output it to build logs.
• Send it to untrusted third-party systems.

Remote Service Address

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

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 perform remote code signing directly on a local file.

The most basic signing command:

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

If already set:

ACCESS_KEY
ACCESS_SECRET

SignTool CLI automatically reads the corresponding access credentials.

SHA-2 is used for signing by default.

Specify the output file

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

You can specify the output file after signing via --out:

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

Overwrite the original file

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

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

After enabling --override, the signature result will be written directly back to the input file.

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

Specify Program Description

You can write the 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 SHA-1 only:

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

Enable both SHA-1 and SHA-2:

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

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

Timestamp

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

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

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

Specify an 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 timestamp protocols, server addresses, and selection recommendations, please refer to Reference Materials.

Query Signature Quota

Use:

signtool quota

You can query the quota for code signing certificates visible with the current access credential.

The output includes:

• Certificate ID.
• Certificate information.
• Remaining signing operations.
• Total signing operations.

If JSON output is required:

signtool quota --json

You can also use the shorthand:

signtool quota -j

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

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 confirm the integrity of the client file.

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

macOS Homebrew

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

Install Homebrew Tap

Run:

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

After completion, you can install the corresponding client.

Install SignTool CLI

Execute:

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

After the installation is complete, you can run:

signtool --version

Confirm that the client is installed correctly.

The package name in Homebrew is:

code-sign-cli

The actual installed command-line program name 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 was installed via Homebrew, it is recommended to upgrade using Homebrew.

First, update the Homebrew package information:

brew update

Upgrade the SignTool CLI:

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

Upgrade the desktop client:

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

This keeps the local installation version in sync with the Homebrew package metadata.

Windows Provider

If your scenario is not about directly calling the SignTool CLI, but instead you 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 provides:

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

Refer to Windows Provider.

CI/CD Automatic Signing

If you need to perform signing during continuous integration or automated build processes, you do not necessarily need to manually install and invoke the SignTool CLI.

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

- 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 Actions support Linux, macOS, and Windows runners, and can perform remote code signing on specified files directly within the build process.

For complete configuration, see CI/CD and Build Tools.

How to Choose

Choose the appropriate client or integration method based on your actual usage:

Scenario	Recommended Method
Manually signing files in a terminal	SignTool CLI
Batch signing invoked via scripts	SignTool CLI
Querying code signing quota	SignTool CLI
Installing and updating CLI on macOS	Homebrew
Using the desktop client on macOS	Homebrew
Windows software such as Microsoft SignTool directly invoking remote private keys	KSP
Traditional CryptoAPI software	CSP
Automated signing in GitHub Actions	GitHub Actions
Developing a custom 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 SignTool CLI or the Remote Code Signing API.