What is a Code Signing Certificate: Differences from SSL Certificates and Use Cases

Code signing certificates and SSL certificates both belong to the category of digital certificates, but their purposes are entirely different: SSL certificates are used for encrypting communications, while code signing certificates are used to prove software origin and integrity. Purchasing the wrong type will render it useless.

Differences Between the Two

What Problems Does It Solve?

When a user downloads a program, the operating system cannot determine two things:

• Whether this file was published by you (origin)
• Whether it has been tampered with after publication (integrity)

After signing, these two aspects become verifiable. Unsigned programs on mainstream systems will trigger warnings, and in some scenarios (such as drivers), they may be directly blocked.

Types

An important feature of EV code signing: The private key must be stored in a hardware token. This enhances security but also means that physical presence of the device is required for signing operations—automated build processes must account for this.

Basic Signing Process

# Windows signing example
signtool sign /f cert.pfx /p password 
  /tr http://timestamp.server.address /td sha256 /fd sha256 app.exe

# Parameter notes:
#   /f    Certificate file (pfx, containing private key)
#   /tr   Timestamp service URL
#   /fd   Hash algorithm (use sha256)

# macOS signing
codesign --sign "Developer ID Application: Name" --timestamp app.dmg

# Verification
codesign --verify --verbose app.dmg
spctl --assess --verbose app.dmg

# Java JAR signing
jarsigner -keystore keystore.jks -tsa http://timestamp.server.address app.jar alias

# Verification
jarsigner -verify -verbose app.jar

Timestamps (Critical, Often Overlooked)

A signature without a timestamp becomes invalid after the certificate expires.

The purpose of a timestamp is to prove that “the signing was completed within the certificate’s validity period.” With it, even if the certificate expires later, the signature of the already released software remains valid.

# Always include timestamp parameters when signing
signtool sign /f cert.pfx /tr http://timestamp.server.address ...   # Windows
codesign --timestamp ...                                # macOS
jarsigner -tsa http://timestamp.server.address ...                   # Java

This is highly practical: Certificates typically expire in one or two years, while the lifecycle of software is much longer. Forgetting the timestamp is like planting a time bomb for your released software.

Verifying Signatures

# Windows
signtool verify /pa app.exe

# macOS
codesign --verify --verbose=4 app.dmg
spctl --assess --type install --verbose app.dmg

# Java
jarsigner -verify -verbose -certs app.jar

# Windows alternative: Right-click file → Properties → Digital Signatures tab to view signer and timestamp

Private Key Protection

The consequences of leaking a code signing private key are more severe than an SSL private key leak: Attackers can use your identity to publish any program, which the system will consider “trusted.”

When Is It Needed?

The criterion is simple: Do you have “programs distributed to users to run on their devices”? If yes, you need it; if only websites, you don’t.

Decision Tree

Should I buy a Code Signing Certificate?
├─ Do you have programs distributed to users?
│  ├─ No (only website) → Not needed, use SSL certificate
│  └─ Yes → Needed
├─ Which type to choose?
│  ├─ Standard apps → Standard code signing
│  └─ Need faster reputation / drivers → EV
├─ During signing
│  └─ Must add timestamp            ← Most critical; missing it causes timed expiration
├─ Private Key
│  ├─ Hardware storage (EV usually mandatory)
│  └─ Never put in code repositories
└─ After release
   └─ Verify signature validity

Scenario Simulation: Software Released for Two Years Without Issues, Suddenly Blocked by System

Phenomenon: An installer released two years ago could be downloaded and installed normally.
Suddenly, users are told there is a risk or cannot run it at all, despite no changes to the installer itself.

1. First, confirm if the installer was replaced →
   Compare the hash value of the installer with the record from when it was originally released.
   Do this step first to distinguish between “file tampering” and “signature expiry.”
2. If hashes match, the issue lies with the signature →
   Signatures themselves have an有效期 (validity period); after expiry, the original signature is no longer recognized.
3. Check if the signature had long-term validity capability →
   A timestamp marker can be attached during signing; with it, the signature is acknowledged long-term.
4. Confirm that this marker was indeed missing →
   The original signing did not include the timestamp parameter, so validity was limited to the certificate’s expiry.
5. Resign with timestamp added →
   Resign this time with the timestamp parameter; existing users can upgrade smoothly.
6. Improve communication and monitoring →
   Make public statements and include signature expiry times in monitoring to avoid passive discovery again.

# ① First rule out file tampering
sha256sum installer.exe

# ② Check signature info (Windows side)
signtool verify /v /pa installer.exe 2>&1 | findstr /i "timestamp expires valid"

# ③ macOS side
codesign -dv --verbose=4 App.app 2>&1 | grep -i 'timestamp|expires'

# ④ When resigning,务必 (must) include timestamp parameters
signtool sign /tr timestamp_server_address /td sha256 /fd sha256 /f cert.pfx /p password installer.exe

Root Cause: No timestamp marker was attached during signing.
Without it, the validity of the signature only lasts until the certificate expires, while the software’s lifecycle is much longer.

Two points worth remembering:

• Signatures must include timestamps, otherwise they only last until certificate expiry.
  This single parameter determines whether software can be recognized long-term.
• When encountering such feedback, compare hashes first.
  It immediately distinguishes between “file replacement” and “signature expiry,” which have completely different handling directions.

8 Common Pitfalls

1. Using SSL certificates for code signing: Different purposes; they are not interchangeable.
2. Signing without timestamps: Everything becomes invalid after certificate expiry.
3. Using weak hash algorithms: Should be at least SHA-256.
4. Putting private keys in code repos or build artifacts: Severe leakage risk.
5. EV private keys not stored in hardware: Non-compliant with requirements.
6. Not verifying after signing: Unaware if it actually took effect.
7. Remembering historical versions only after certificate expiry: Timestamps prevent this issue.
8. Automated processes ignoring hardware tokens: EV signing requires device presence.

Real Customer Feedback (From Cloud Market Similar Product Reviews and Consultations)

The following excerpts are taken from real buyer reviews and consultations for similar O&M services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and peers, provided solely for reference of real feedback, not fictional tickets from this site):

2****7 Rating: 5.0 Points 2022-02-18 14:38

Jian****wei Rating: 5.0 Points 2021-01-20 15:02

b****9 Rating: 5.0 Points 2018-11-29 16:31 Fast follow-up, efficient, great 1