Windows Provider

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

With Windows Provider, you can enable Microsoft SignTool, Visual Studio, MSBuild, installation packaging tools, and other software that supports Windows cryptographic interfaces to use sslTrus cloud code signing capabilities.

The signing private key is always kept in the cloud HSM, so there is no need to deploy the private key file to the local computer.

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

KSP and CSP

KSP and CSP correspond to two generations of Windows cryptographic 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 usually preferred.

Use CSP only when the target software does not support KSP or explicitly requires the legacy 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 receives signing requests initiated by the application and sends the digest to be signed to the remote code signing service; the actual private key operation is completed 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 a standard Windows Provider.

Installing KSP

Run the following in an administrator terminal:

signtool ksp install

This command will install and register:

sslTrus Key Storage Provider

KSP installation involves system provider registration and the Windows system directory, so administrator privileges are usually required.

Add Certificate Configuration

Execute:

signtool ksp add

According to the prompt, enter:

Access Key
Access Secret
Certificate Code

The client retrieves the corresponding certificate from the remote code signing service and saves 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 Certificate

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

Run:

signtool ksp register

By default, it is registered to the current user's personal certificate inventory.

If you need to register it to the LocalMachine certificate inventory:

signtool ksp register --store local-machine

After registration is completed, Windows will recognize the corresponding certificate as having a usable private key, but the actual private key remains stored in the cloud HSM.

Using Microsoft SignTool

After KSP configuration is completed, you can use the Microsoft signtool.exe provided by 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 serial 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 an 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 calls the sslTrus KSP through Windows CNG, and the KSP then performs remote private key signing.

Managing the KSP

View the configured KSPs:

signtool ksp list

Delete configuration:

signtool ksp del

Detach the certificate from the KSP:

signtool ksp deregister

Uninstall KSP:

signtool ksp uninstall

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

CSP

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

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

Applicable scenarios

CSP is suitable for:

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

For newer systems that can use KSP normally, it is generally not necessary to additionally use CSP.

Installing CSP

Execute 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 the KSP at the same time, you can run:

signtool csp install --with-ksp

Add certificate configuration

Run:

signtool csp add

Based on the prompt, enter:

Access Key
Access Secret
Certificate Code

After the addition is complete, the client downloads the corresponding certificate and saves it to:

%ProgramData%\sslTrusKSP\CERT_CODE.crt

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

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

signtool csp add --address nicsrs

Register certificate

By default, the certificate is registered to the current user's personal certificate store:

signtool csp register

If you need to register to LocalMachine:

signtool csp register --store local-machine

Supported certificate stores include:

Parameter	Windows Certificate Store
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 associated, but the private key actually remains in the cloud HSM.

Using Microsoft SignTool

When signing with a 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 sslTrus CSP supports SHA1, SHA256, SHA384, and SHA512 digest algorithms. New signing scenarios should generally use SHA-256 or a stronger algorithm.

Verify 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 signing counts.

Manage CSP

View existing configurations:

signtool csp list

Delete a certificate configuration:

signtool csp del

Detach the certificate from the private key association with the CSP:

signtool csp deregister

Uninstall Provider:

signtool csp uninstall

Deleting a CSP configuration will not automatically delete downloaded certificate files. If the associated certificates and configurations are no longer in use, they should be cleaned up only after confirming that no other Providers depend on them.

KSP or CSP

If there are no special compatibility requirements, you can choose according to the following table:

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

The primary difference between KSP and CSP lies in the cryptographic Provider interfaces used by Windows, while the remote private key security model remains consistent.

Regardless of whether KSP or CSP is used, code signing private keys are never saved to the local client.

Signing Count

The signing count for Windows Provider is calculated based on the actual remote signing operations completed on the underlying system.

For example:

SHA256 签名一次 = 1 次

If you first complete SHA256 signing on the same file, and then append another signature, the remote private key operation is triggered again, so the hashes must be calculated separately.

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

For specific rules, please refer to Reference Materials.

Timestamp

Windows Authenticode signing usually recommends adding 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, you should select an appropriate TSA based on the target Windows version, certificate policy, network environment, and timestamp service provider requirements.

For details on specific timestamp servers and protocols, refer to Reference Materials.

Security Notes

When using the Windows Provider, note the following:

• The 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 the code signing private key.
• The code signing private key is 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, pay special attention 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.