Getting Started With Your Code Signing Certificate: Installation, Configuration, and Your First Signing Operation

Key Takeaways 

• A code signing certificate lets you cryptographically sign software so users and operating systems can verify who published it and confirm it hasn’t been tampered with since release. 

• SSL.com issues code signing private keys only to FIPS-validated hardware (YubiKey or Thales SafeNet USB tokens) or to the cloud-based eSigner service — private keys can never be exported as a downloadable .pfx file. 

• Signing is performed with Microsoft’s SignTool, or an eSigner tool (eSigner CKA, eSigner CodeSignTool, or the eSigner CSC API), depending on whether your certificate lives on a token or in the cloud. 

• As of March 1, 2026, CA/Browser Forum Baseline Requirements cap the validity of publicly trusted code signing certificates at 458 days; your purchased term is unaffected, but individual certificates within that term may need periodic reissuance. 

• Always timestamp your signatures so they remain valid after the certificate itself expires. 

 

Go to top

 

Prerequisites Common to All Signing Methods 

Before you begin, regardless of which certificate delivery method you’re using, make sure you have: 

• Windows SDK installed, which includes SignTool (SignTool ships with the Windows 10/11 SDK — there’s no separate download required) 

• The file you intend to sign saved locally and accessible from the command line 

• Administrator access on the signing machine, since some configuration steps and SignTool operations require elevated permissions 

From here, the setup path splits depending on whether your certificate is on a hardware token or enrolled in eSigner. 

Go to top

   

Option 1: Token-Based Code Signing 

SSL.com ships code signing certificates on two supported hardware tokens: YubiKey (FIPS-validated) and Thales SafeNet (Gemalto). This guide assumes a certificate is already installed on your token. 

A. YubiKey Code Signing 

Installation and configuration requirements 

1. Install the Windows SDK and SignTool. SignTool is bundled with the Windows 10/11 SDK and is typically installed at a path similar to C:\Program Files (x86)\Windows Kits\10\bin\<SDK VERSION>\x64\signtool.exe. 
2. Download and install the YubiKey Smart Card Minidriver, available from Yubico. This driver is required for Windows to recognize the FIPS token. 
3. Locate your YubiKey PIN. You’ll be prompted for this PIN every time you sign. It’s viewable from your SSL.com account. 

 

Signing your first file 

With the token connected and the minidriver installed, open PowerShell or Command Prompt and run:  .\signtool.exe sign /fd sha256 /a "C:\path\to\MyExecutable.exe"      Here’s what each part of that command does: 

• .\signtool.exe invokes SignTool. Depending on your SDK version and how your PATH is configured, you may instead need the full path to signtool.exe. 

• /fd sha256 sets the digest (hash) algorithm used when signing. This flag is mandatory on Windows 10 SDK, HLK, WDK, and ADK builds 20236 and above, and SHA256 is recommended over SHA1 for stronger security. 

• /a tells SignTool to automatically select an appropriate code signing certificate — useful when only one certificate is present. 

• "C:\path\to\MyExecutable.exe" is the full path to the file you’re signing. 

You’ll be prompted to enter your YubiKey PIN to authorize the operation. 

Adding a timestamp (recommended)

Timestamping ensures your signature remains valid even after the certificate expires, since the timestamp proves the code was signed while the certificate was still valid. Add /tr http://ts.ssl.com /td sha256 to your command — note that SSL.com’s timestamp server requires the /tr flag specifically (not the older /t flag), and /td must come after /tr or SignTool will silently default to the weaker SHA-1 timestamp algorithm.   

B. Thales SafeNet (Gemalto) USB Token 

Installation and configuration requirements 

1. Install the Windows SDK and SignTool (as above). 
2. Install SafeNet Authentication Client, the middleware that manages Thales SafeNet hardware. For the complete guide, with detailed download and installation instructions, see: SafeNet Authentication Client Download for Code Signing Certificates 
3. Activate your Thales SafeNet token. Because SSL.com pre-installs the certificate on the token before shipping, activation is done through your SSL.com account rather than locally: 
4. Locate the serial number printed on the physical token. 
5. Sign in to your SSL.com account and open the Orders tab. 
6. Click the download/details link for your certificate order, then find the Physical Tokens section. 
7. Enter the token’s serial number to activate it. This reveals your Activation PIN (also called the Token Password, entered when signing) and your Admin PIN (also called the PUK, used only to reset a locked token). 

Signing your first file 

1. Connect the Thales SafeNet token to your computer. 
2. Open SafeNet Authentication Client so the token is recognized. 
3. Run the signing command: 

signtool sign /tr http://ts.ssl.com /td sha256 /fd sha256 /a "PATH_OF_FILE_TO_BE_SIGNED" 

• /fd sha256 — digest algorithm used for signing 

• /tr http://ts.ssl.com — SSL.com’s timestamp server address 

• /td sha256 — timestamp digest algorithm 

• /a — automatically selects an appropriate certificate 

• The file path should be wrapped in double quotes and include the filename itself, e.g. "C:\Users\Admin\Documents\test file.dll". 

If Windows reports that signtool isn’t recognized as a command, replace signtool in the command with the full quoted path to signtool.exe (the exact path depends on your installed SDK version and architecture). 

1. Run Command Prompt as administrator and execute the command. 
2. When prompted, enter your Token Password (the Activation PIN from your SSL.com order page). 
3. A success message confirms the file is signed. 

  If your token becomes locked or you need to change its password, don’t attempt to guess the PIN repeatedly, as this can lock the token.   

Verifying Your Signature (Both Token Types) 

After signing, confirm the signature is valid:  .\signtool.exe verify /pa "C:\path\to\MyExecutable.exe"    A successful result displays the algorithm and timestamp used. You can also right-click the signed file, open Properties, and check the Digital Signatures tab to visually confirm the signer identity and signing date. 

Go to top

Option 2: SSL.com eSigner Cloud Code Signing 

If managing physical tokens isn’t practical for your team — particularly for distributed developers or automated build pipelines — eSigner lets you sign code remotely from any internet-connected device, with the private key secured in SSL.com’s cloud HSM rather than on hardware you manage. eSigner code signing requires an EV Code Signing Certificate and supports a broad range of file types, including Microsoft Authenticode formats (.exe, .dll, .sys, .ocx, and others), MSI installers, PowerShell scripts, CAB and CAT files, Java .jar files, and — when signed via eSigner CKA — MSIX, MDB, and ACCDE files as well. Maximum file size is 200 MB for code signing regardless of whether you use eSigner Express or the eSigner API.   

Step 1: Enroll Your Certificate in eSigner 

Before you can sign anything, your certificate order must be enrolled in eSigner and paired with two-factor authentication (2FA), which is required on every signing operation. You have two enrollment paths: 

QR Code (Authenticator App) Method 

1. Log in to your SSL.com account, click Orders, and open your certificate order’s details page. 
2. Find the eSigner Cloud Signing Enrollment section and select OTP APP as your second-factor method. 
3. Create a 4-digit PIN and save it securely — ideally in a password manager, since you’ll need it again to add, remove, or replace signing devices later. 
4. Click create OTP and issue certificate. A QR code appears. 
5. Scan the QR code with an authenticator app such as Google Authenticator or Authy. The app will now generate 30-second one-time passwords used for every future signing operation. Note that the QR code is only displayed once — it will not reappear if you reload the page. 

OTP SMS Method 

1. Log in to your SSL.com account (select the correct team if you belong to more than one), click Orders, and open your certificate’s details page. 
2. Under Second factor authentication, select OTP SMS. 
3. In the Mobile number verification section, choose your country code, enter your mobile number, and click send OTP SMS. 
4. Check your phone for a 6-digit code from “AuthMSG” (SSL.com’s verification service), enter it on the order page, and click verify phone. 
5. Once verified, click create OTP and issue certificate to complete enrollment. Your account page will then display the last four digits of the verified phone number. 

 

Step 2: Choose a Signing Tool 

Once enrolled, pick the signing method that fits your workflow: 

eSigner Cloud Key Adapter (CKA) 

 A Windows application that behaves like a virtual USB token, loading your cloud-based certificate into the Windows certificate store so that familiar tools like signtool.exe and certutil.exe can use it directly. This is the best option for teams that want to keep using existing SignTool-based workflows without physical hardware.  Requirements: certificate enrolled in eSigner; eSigner CKA installed and configured for manual or automated signing; Windows SDK/SignTool installed; the file to sign saved locally; and, for manual signing, your 2FA method ready.     A typical CKA signing command looks like:  "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\signtool.exe" sign /fd sha256 /tr http://ts.ssl.com /td sha256 /sha1 CERTIFICATE_THUMBPRINT "SIGNABLE_FILE_PATH" 

• /fd sha256 — hash algorithm 

• /tr http://ts.ssl.com and /td sha256 — timestamp server and digest algorithm 

• /sha1 CERTIFICATE_THUMBPRINT — identifies which certificate to use from the certificate store by thumbprint 

• The signable file path should be quoted 

Some file types need extra configuration before eSigner CKA can sign them. SSL.com maintains dedicated guides for each (confirm current URLs on ssl.com’s knowledge base, as none were provided in source material): 

• Signing Hardware Lab Kit (HLK) Files — using eSigner CKA with HLKSigntool to prepare kernel-mode drivers for Microsoft submission 

• Signing VBA Macros — signing Microsoft Visual Basic for Applications macros used to automate Office tasks 

• Signing .app Files — securely defining and referencing the identity of a complete Microsoft application solution 

• Signing .vsix Files — signing Visual Studio extension and add-on packages 

eSigner CKA also integrates with CI/CD platforms including CircleCI, GitHub Actions, GitLab CI, Travis CI, and Azure Pipelines for fully automated signing.   

eSigner CodeSignTool 

A cross-platform, Java-based command-line utility built for automated and high-volume signing, including CI/CD pipelines. Rather than transmitting your actual file, CodeSignTool sends only a cryptographic hash of the file to SSL.com for signing, which is a meaningful advantage if your files contain sensitive code that shouldn’t leave your network.  For CI/CD automation, CodeSignTool relies on the following environment variables: 

Variable	Purpose
USERNAME	Your SSL.com account username
PASSWORD	Your SSL.com account password
CREDENTIAL_ID	Identifies which code signing certificate to use — required only if you have more than one eSigner certificate; if omitted with a single certificate, that one is used by default
TOTP_SECRET	OAuth TOTP secret used for automated 2FA — see the Automate eSigner EV Code Signing guide
ENVIRONMENT_NAME	Set to TEST or PROD

And these inputs: 

• input_file_path (required) — path to the file to be signed 

• output_dir_path — destination directory for the signed file; if omitted, the original file is overwritten with the signed version 

  Platform-specific integration guides are also available under the following titles : 

• Cloud Code Signing Integration with CircleCI 

• Cloud Code Signing Integration with GitHub Actions 

• Cloud Code Signing Integration with GitLab CI 

• Cloud Code Signing Integration with Travis CI 

• Cloud Code Signing Integration with Jenkins CI 

• Cloud Code Signing Integration with Azure DevOps 

• Cloud Code Signing Integration with BitBucket 

Go to top

Frequently Asked Questions 

Can I export my code signing private key to use on another machine? No. Per CA/Browser Forum Baseline Requirements, SSL.com code signing private keys cannot be exported and are never issued as downloadable .pfx files. Keys live only on a FIPS-validated YubiKey, a Thales SafeNet token, or within SSL.com’s eSigner cloud HSM.    Why did my certificate’s validity period get shorter? Effective March 1, 2026, CA/Browser Forum Baseline Requirements cap the maximum validity of publicly trusted code signing certificates at 458 days. This doesn’t reduce the value of what you purchased — SSL.com began enforcing the cap on new certificate issuance starting February 27, 2026, and customers still receive the full term they purchased, though individual certificates within that term may need to be reissued more frequently.    Do I need to timestamp my signed code? Yes. Without a trusted timestamp, your signature becomes invalid the moment the certificate expires. With a timestamp, the signature remains trusted indefinitely, since it proves the code was signed while the certificate was valid.    What’s the difference between token-based signing and eSigner? Token-based signing (YubiKey or Thales SafeNet) keeps your private key on physical hardware that must be connected to the signing machine. eSigner keeps the key in SSL.com’s cloud HSM and lets you sign from any internet-connected device using 2FA — better suited to distributed teams or CI/CD automation.    Which file types can I sign with eSigner? eSigner supports Microsoft Authenticode formats (EXE, DLL, SYS, OCX, and related types), MSI installers, PowerShell scripts, CAB/CAT files, and Java JAR files, plus MSIX, MDB, and ACCDE when signed through eSigner CKA. Document signing (PDF, DOCX, PPTX, XLSX) is handled separately through eSigner’s document signing tools.     

Conclusion 

Whether you’re signing an occasional installer from a single developer machine or automating thousands of signing operations across a CI/CD pipeline, the underlying goal is the same: proving to your customers, partners, and operating systems that your software is exactly what you say it is, and that it hasn’t been altered since you released it. Token-based signing with YubiKey or Thales SafeNet gives you direct, hardware-backed control well suited to smaller teams or infrequent signing needs, while eSigner’s cloud-based model removes the friction of physical tokens entirely — letting distributed teams and automated build systems sign code securely from anywhere.  Once your signing environment is configured correctly, the day-to-day process becomes routine: hash, sign, timestamp, verify. Getting it right the first time means fewer browser and OS security warnings, stronger brand trust, and a smoother path to compliance with CA/Browser Forum requirements as they continue to evolve. If you run into questions specific to your setup, SSL.com’s support team is available by email at Support@SSL.com, by phone at 1-877-SSL-SECURE, or through live chat.