Windows Provider

sslTrus provides two Windows Provider integration options: KSP (Key Storage Provider) and CSP (Cryptographic Service Provider).

Through the Windows Provider, Microsoft SignTool, Visual Studio, MSBuild, installer tools, and other software that supports Windows cryptography interfaces can leverage sslTrus cloud-based code signing capabilities.

The signing private key is always stored in the cloud HSM, so there is no need to deploy private key files to local machines.

Installation, configuration, and maintenance of KSP and CSP are all performed through the sslTrus SignTool CLI, which can be downloaded from the sslTrus client release page.

KSP and CSP

KSP and CSP correspond to the two generations of Windows cryptography interfaces:

Provider	Windows Interface	Applicable Scenarios
KSP	CNG (Cryptography API: Next Generation)	Modern Windows applications and signing tools, preferred choice
CSP	CryptoAPI	Legacy applications or software that explicitly requires CSP

For new Windows integration scenarios, KSP is generally the preferred choice.

Use CSP only when the target software does not support KSP, or when it explicitly requires the traditional CryptoAPI Provider.

KSP

KSP is a Key Storage Provider based on Windows CNG.

After installing sslTrus KSP, Windows applications that support CNG can invoke the remote code signing service through the standard Windows key interface.

The local Provider is responsible for receiving signing requests initiated by applications and sending the digest to be signed to the remote code signing service; the actual private key operations are performed in the cloud HSM.

Applicable Scenarios

KSP is suitable for:

• Microsoft SignTool.
• Visual Studio.
• MSBuild.
• Build and signing software that supports Windows CNG.
• Applications that need to access remote private keys through the standard Windows Provider.

Installing KSP

Run the following in an administrative terminal:

signtool ksp install

This command will install and register:

sslTrus Key Storage Provider

KSP installation involves system Provider registration and Windows system directories, so administrator privileges are typically required.

Add Certificate Configuration

Run:

signtool ksp add

Based on the prompt, enter:

Access Key
Access Secret
Certificate Code

The client will obtain the corresponding certificate from the remote code signing service and save the remote service address, access credentials, and certificate configuration.

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

signtool ksp add --address nicsrs

Register the Certificate

After completing the KSP configuration, you need to register the code signing certificate into the Windows certificate inventory and associate it with the KSP Provider.

Execute:

signtool ksp register

Default registration goes to the current user's personal certificate inventory.

If you need to register to the LocalMachine certificate inventory:

signtool ksp register --store local-machine

After registration is complete, Windows will recognize the corresponding certificate as having an available private key, but the actual private key remains stored in the cloud HSM.

Using Microsoft SignTool

After the KSP is configured, you can use the Microsoft signtool.exe provided by the Windows SDK to sign files.

For example:

signtool.exe sign /v ^
  /csp "sslTrus Key Storage Provider" ^
  /kc CERT_CODE ^
  /f "C:\ProgramData\sslTrusKSP\CERT_CODE.crt" ^
  /fd SHA256 ^
  /tr http://timestamp.acs.microsoft.com ^
  /td SHA256 ^
  ".\app.exe"

Main parameters:

Parameter	Description
/csp	Specifies the sslTrus KSP Provider
/kc	Specifies the key container corresponding to the certificate number
/f	Specifies the code signing certificate
/fd	Specifies the file digest algorithm
/tr	Specifies the RFC 3161 timestamp server
/td	Specifies the timestamp digest algorithm

If you need to append a SHA-1 signature to an existing signature, you can use the /as parameter:

signtool.exe sign /v ^
  /csp "sslTrus Key Storage Provider" ^
  /kc CERT_CODE ^
  /f "C:\ProgramData\sslTrusKSP\CERT_CODE.crt" ^
  /fd SHA1 ^
  /tr http://timestamp.acs.microsoft.com ^
  /td SHA256 ^
  /as ^
  ".\app.exe"

Microsoft signtool.exe will invoke the sslTrus KSP through Windows CNG, and the KSP will complete the remote private key signing.

Managing the KSP

To view the configured KSPs:

signtool ksp list

Deletion configuration:

signtool ksp del

Remove the association between the certificate and the KSP:

signtool ksp deregister

Uninstall KSP:

signtool ksp uninstall

Before uninstalling the Provider, confirm that no other Windows applications still depend on it.

CSP

CSP is the Cryptographic Service Provider used by the traditional Windows CryptoAPI.

It is mainly used in Windows signing flows that require specifying the Provider and key container via the /csp and /kc parameters. sslTrus CSP is installed and maintained by the client, while the actual file signing is still performed by Microsoft signtool.exe from the Windows SDK.

Applicable Scenarios

CSP applies to:

• Windows software that only supports the traditional CryptoAPI.
• Signing tools that explicitly require specifying a CSP Provider.
• Environments that need to sign using Microsoft SignTool with the /csp and /kc parameters.
• Legacy applications that cannot use Windows CNG / KSP.

For new systems that can use KSP properly, additional use of CSP is generally not required.

Installing CSP

Run the following in an administrator terminal:

signtool csp install

During installation, the following will be registered:

sslTrus Cryptographic Service Provider

And install the Provider DLL into the Windows system.

The CSP Provider type is:

PROV_RSA_AES

Local configuration is saved by default in:

%ProgramData%\sslTrusKSP

The configuration file is protected using Windows DPAPI.

If you need to install KSP at the same time, you can run:

signtool csp install --with-ksp

Adding Certificate Configuration

Execute:

signtool csp add

Based on the prompt, enter:

Access Key
Access Secret
Certificate Code

After the addition is completed, the client will download the corresponding certificate and save it to:

%ProgramData%\sslTrusKSP\CERT_CODE.crt

Here, CERT_CODE serves as both the remote certificate identifier and the key container name used later by Microsoft SignTool.

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

signtool csp add --address nicsrs

Register a Certificate

By default, the certificate is registered in the current user's personal certificate inventory:

signtool csp register

If you need to register to LocalMachine:

signtool csp register --store local-machine

Supported certificate inventories include:

Parameter	Windows certificate inventory
current-user	CurrentUser\My
local-machine	LocalMachine\My

After registration is complete, Windows Certificate Manager will show that the corresponding certificate has a private key association, but the private key actually remains in the cloud HSM.

Using Microsoft SignTool

When signing with CSP, you need to explicitly specify the Provider, key container, and certificate file:

signtool.exe sign /v ^
  /csp "sslTrus Cryptographic Service Provider" ^
  /kc CERT_CODE ^
  /f "C:\ProgramData\sslTrusKSP\CERT_CODE.crt" ^
  /fd SHA256 ^
  /tr http://timestamp.acs.microsoft.com ^
  /td SHA256 ^
  ".\app.exe"

Main parameters:

Parameter	Description
/csp	Specifies the sslTrus CSP Provider
/kc	Specifies the key container corresponding to the certificate number
/f	Specifies the code signing certificate
/fd	Specifies the file digest algorithm
/tr	Specifies the RFC 3161 timestamp server
/td	Specifies the timestamp digest algorithm

The current remote signing interface supports SHA1 and SHA256 digest algorithms. SHA256 should be preferred for new signing scenarios; use SHA1 only when compatibility with legacy systems is required.

Verifying the signature

After signing is complete, you can use Microsoft SignTool to verify:

signtool.exe verify /pa /v ".\app.exe"

Signature verification does not re-invoke the remote private key, nor does it generate new signature counts.

Managing CSP

View existing configurations:

signtool csp list

Deleting a certificate configuration:

signtool csp del

Remove the association between the certificate and the CSP private key:

signtool csp deregister

Uninstall the Provider:

signtool csp uninstall

Deleting the CSP configuration does not automatically delete the already downloaded certificate files. If the related certificate and configuration are no longer in use, you should clean them up only after confirming that no other Provider depends on them.

KSP or CSP

If there are no special compatibility requirements, you can choose as follows:

Scenario	Recommendation
New Windows signing environment	KSP
Supports Windows CNG	KSP
Modern Windows tools such as Microsoft SignTool	KSP
Software explicitly requires CSP	CSP
Legacy CryptoAPI applications	CSP
Tools require the use of /csp and /kc	CSP

The main difference between KSP and CSP is the cryptography Provider interface used by Windows; the remote private key security model remains the same.

Whether KSP or CSP is used, the code signing private key is never saved to the local client.

Signature Count

The signature count for the Windows Provider is calculated based on the actual remote signing operations performed at the underlying level.

For example:

SHA256 签名一次 = 1 次

If you first complete a SHA256 signature on the same file and then append another signature, it will trigger remote private key operations again, so the calculations must be performed separately.

In the KSP scenario, performing both SHA256 and SHA1 dual-signing on the same file typically results in two underlying signature calls.

For specific rules, please refer to Reference Materials.

Timestamp

For Windows Authenticode signatures, it is usually recommended to add a trusted timestamp.

In modern code signing scenarios, it is recommended to prioritize RFC 3161 timestamps, for example:

http://timestamp.acs.microsoft.com

In actual production environments, the appropriate TSA should be selected based on the target Windows version, certificate policy, network environment, and timestamp service provider requirements.

For details on specific timestamp servers and protocol descriptions, please refer to References.

Security Notes

When using the Windows Provider, please note the following:

• Access Secret should be protected as a sensitive credential.
• Do not write access credentials into public scripts or logs.
• Provider configuration files should not be publicly distributed.
• Local certificate files do not contain code signing private keys.
• Code signing private keys are always stored in the cloud HSM.
• When KSP/CSP initiates signing, it must be able to access the remote code signing service.
• When using the LocalMachine certificate store, special attention should be paid to Windows user permissions and credential access scope.

The CSP's config.dat is protected using the DPAPI of the current Windows user profile; registering the certificate to LocalMachine does not automatically change the DPAPI protection scope of this configuration.