How to Sign Your Software or App Using DigiCert Code Signing

Why Signing Your Code Matters

When you sign your software with a trusted certificate, you’re giving it a digital “seal of authenticity.” This seal tells operating systems, browsers, antivirus programs, and end users:

• Who published the software: Your verified name appears instead of “Unknown Publisher.”

• That the file hasn’t been modified: If someone tampers with your file, the signature breaks — and the system warns the user.

• That your brand is trustworthy: Users are far less likely to abandon installation or uninstall your app if it’s properly signed.

Without code signing, many systems — especially Windows — will block your installer or show alarming pop-ups. So for any serious developer or company, signing isn’t optional — it’s essential.

Before You Start: What You Need

Before you can sign anything, you need a few things in place:

First, you need a valid DigiCert Code Signing Certificate. This could be the Standard (OV) version or the Extended Validation (EV) version. The OV version comes as a downloadable .pfx or .p12 file. The EV version always ships with a hardware USB token — because the private key must be stored securely on a physical device that can’t be exported.

Next, you’ll need:

• The actual software file you want to sign — like an .exe, .msi installer, .dll, or .jar file.

• A signing tool. For Windows software, this is usually Microsoft’s SignTool.exe — a free tool that comes with the Windows SDK.

• Administrator rights on your computer, because installing certificates or using a hardware token often needs admin permissions.

• Internet access, if you plan to add a timestamp (which you should — more on that soon).

Once you have these, you’re ready to prepare your system for signing.

Step 1: Install Your Certificate or Token

If you purchased a Standard (OV) DigiCert Code Signing Certificate, DigiCert usually provides you with a .pfx or .p12 file after your identity has been validated. This file contains both your certificate and your private key, encrypted with a password you set when you generated the CSR (Certificate Signing Request).

To install this .pfx:

1. Save the file somewhere secure on your signing machine.

2. Double-click the .pfx file. Windows will launch the Certificate Import Wizard.

3. The wizard will ask where to store the certificate — choose Current User > Personal. This places it in the Windows Certificate Store where SignTool can find it.

4. Enter your private key password when prompted.

5. Complete the wizard — your certificate is now ready to use.

If you purchased an EV DigiCert Code Signing Certificate, you don’t download a file. Instead, DigiCert sends you a special hardware USB token, often called a SafeNet eToken or similar. This token stores your private key in a way that it can’t be copied or exported — adding a strong layer of security.

To set it up:

1. Plug the USB token into your computer.

2. Install any drivers or token management software that DigiCert provides — usually SafeNet Authentication Client.

3. Open the token management tool to make sure it recognizes your certificate.

4. The signing tool will read the certificate directly from the token every time you sign — so keep the token plugged in when signing.

Step 2: Understand Why Timestamping Is Critical

A common mistake among new developers is skipping the timestamp step — but this step is critical. Here’s why:

When you sign code, your signature is only valid as long as your certificate is valid. If your certificate expires, the signature becomes suspect unless you used timestamping.

Timestamping attaches a trusted date and time to your signature, proving that the file was signed while the certificate was still valid — even if the certificate later expires.

This means your old releases won’t suddenly fail to install or throw warnings. It’s a small step that protects you (and your users) from headaches later.

DigiCert provides a free, trusted timestamp server:

You’ll point to this when you run your signing commands.

Step 3: Use the Right Signing Tool for Your File Type

The most common tool for Windows applications is SignTool.exe, which comes with the Windows SDK. If you’re signing Java apps, you’ll use jarsigner. For macOS apps, you’d sign through Xcode with your Apple Developer ID, but that’s a separate topic.

Let’s focus on Windows here.

Step 4: Sign Your Software — Practical Example

Suppose you have an .exe installer ready to publish — MyInstaller.exe. Here’s how you’d sign it with SignTool.

For Standard (OV) Certificate:

Because your .pfx is installed in your Certificate Store, you can sign by referencing the file directly or using the subject name.

Here’s an example command using the .pfx file directly:

What does each part mean?

• /f tells SignTool where to find your .pfx file.

• /p is the password you used when exporting the .pfx.

• /tr is the timestamp server URL — so your signature remains valid after expiration.

• /td sha256 sets the timestamp digest algorithm to SHA-256.

• /fd sha256 sets the file digest algorithm — SHA-256 is the modern standard.

• The last part is the path to your installer or executable.

For EV Certificate:

With EV, you don’t use a .pfx file. Instead, your private key stays on the USB token. So the command changes slightly — you tell SignTool to look in the Windows Certificate Store for a certificate matching your publisher name.

A typical EV signing command looks like this:

Here:

• /n is your exact company name as it appears on the certificate. It must match perfectly — otherwise, SignTool won’t find it.

• /a tells SignTool to automatically choose the best signing certificate if multiple matches exist.

• The timestamp settings stay the same.

Pro tip: Always verify your final file path. Many signing failures come from typos in the path or filename.

Step 5: Confirm Your Signature

Once you sign the file, you should verify that the signature worked.

Run:

This tells SignTool to check the signature (/pa means “default Authenticode policy”). The /v flag shows detailed output.

If successful, you’ll see output confirming:

• The publisher name matches your company.

• The signature is valid.

• The timestamp was applied correctly.

Step 6: Ship Your Software

Once verified, your installer or app is ready to share with the world.

Your users will see your verified publisher name instead of “Unknown Publisher.” SmartScreen filters on Windows will trust your app more quickly — especially if you’re using an EV certificate. And antivirus or security programs are far less likely to flag your installer as suspicious.

Best Practices to Keep in Mind

1️⃣ Always sign production-ready builds only.
Never sign test builds or prototypes you’ll never release. Keep your signature for trusted, final versions only.

2️⃣ Protect your private key at all costs.
If you’re using an OV .pfx, store it securely — ideally on an encrypted drive with access controls. If you lose it or it’s stolen, an attacker could sign malware as you. With EV, the USB token protects you, but you must keep the token physically safe.

3️⃣ Always use timestamping.
This single step ensures your signature doesn’t expire with your certificate. Without it, every old build would fail signature checks when your certificate expires.

4️⃣ Renew before your certificate expires.
If you wait too long, you risk interruptions in your build or deployment pipeline. Start the renewal process at least 2–3 weeks before expiry — especially if you need an EV token re-shipped.

5️⃣ Automate where possible.
For regular releases, add signing steps to your build scripts or CI/CD pipeline. PowerShell, Batch, Jenkins, GitHub Actions — all can integrate SignTool commands so you never forget to sign.

Common Issues & How to Fix Them

Issue: SignTool can’t find your certificate.
Fix: Double-check your .pfx is imported into the right Certificate Store or that your EV token is plugged in. Use /n with the exact subject name.

Issue: Users still see “Unknown Publisher.”
Fix: Make sure you signed with the correct certificate and that your timestamp server worked. Also, verify you used SHA-256, which modern systems require.

Issue: Signature expired warnings appear.
Fix: This means you skipped timestamping. Re-sign the installer if possible, this time with a timestamp.

Conclusion

Signing your software isn’t just about avoiding warnings — it’s about earning trust every time someone clicks “Install.” With your DigiCert Code Signing Certificate, you can prove your software is legitimate, safe, and backed by one of the world’s most trusted Certificate Authorities.

Get your certificate set up, sign every build the right way, timestamp it, protect your keys — and you’ll keep your users secure while strengthening your brand.