How Code Signing Certificate Works

Last updated: Nov 1, 2025

A code signing certificate is a type of digital certificate used by software developers and organizations to prove the legitimacy and integrity of the software they distribute. At its core, it is a digital credential issued by a trusted authority that verifies the identity of the software publisher. When a piece of software is “code signed,” it includes a cryptographic signature that allows users, operating systems, and security tools to confirm two important things: who created the software, and whether it has been altered or tampered with since it was originally signed.

The concept behind code signing is similar to sealing an envelope with a wax stamp. The seal guarantees that the message inside hasn’t been opened or changed, and that it was sent by the person or organization whose seal is on it. Code signing certificates serve the same purpose in the digital world. By signing software with a private key and including a certificate containing the corresponding public key, the publisher enables anyone who receives the software to verify its authenticity.

A code signing certificate contains information about the publisher, such as the organization’s name, location, and sometimes a verified individual’s identity. It also includes the public key associated with the publisher, an expiration date, and the digital signature of the issuing authority. This authority—known as a Certificate Authority (CA)—verifies the publisher’s identity before issuing the certificate, adding a layer of trust to the process.

When users download or install signed software, their device or operating system checks the embedded signature and certificate. It verifies that the certificate was issued by a recognized authority, that the certificate hasn’t expired or been revoked, and that the code has not changed since it was signed. If all checks pass, the system trusts the software and usually installs it without warnings. If something is wrong—such as a missing certificate or a signature mismatch—the user might be presented with a security warning like “Unknown Publisher” or “The software cannot be verified.”

In summary, a code signing certificate is a fundamental tool for secure software distribution. It ensures users can trust the origin and integrity of the software they install by linking the identity of the publisher to the signed application. This mechanism not only protects end users, but also helps developers maintain credibility and prevent their software from being modified or used for malicious purposes.

How Code Signing Works End-to-End

To understand how a code signing certificate works in practice, it’s useful to walk through the complete process—from the moment a software publisher obtains the certificate, to the moment a user downloads and runs the signed application. This process involves several key steps: identity verification, certificate issuance, software signing, distribution, and signature validation. Each step plays a specific role in creating a chain of trust between the software developer and the end user.

1. Certificate Issuance and Identity Verification

Before a publisher can begin signing software, they must obtain a code signing certificate from a trusted Certificate Authority (CA). The CA verifies the identity of the organization or individual requesting the certificate. This is usually done by checking government records, domain ownership, or company registrations. Once the identity is confirmed, the CA issues a digital certificate that includes details about the publisher and a public key tied to a private key generated by the publisher.

2. Generating the Private/Public Key Pair

The developer or organization creates a pair of cryptographic keys: a private key that is kept secret and a public key that is shared. The private key is used to sign software or other digital assets, while the public key is embedded in the certificate and used by others to verify the signature. The safety of the entire signing process depends on keeping the private key secure. If it’s ever stolen or compromised, an attacker could sign malicious software that appears legitimate.

3. Signing the Code

When the publisher is ready to distribute software—whether it’s an application, driver, script, or mobile file—they use their private key to generate a digital signature. The signature is not applied to the code itself, but rather to a cryptographic hash of the code. A hash is a short string of characters generated by running the code through a mathematical function. If even one character is changed in the code, the hash changes completely. This makes it an effective way to detect tampering.

The signing process attaches two components to the software:

• The digital signature (created using the private key)

• The code signing certificate (containing the public key and publisher identity)

This bundle is what gets distributed to users or installed during software deployment.

4. Timestamping (Optional but Important)

To ensure that a signature remains valid even after the certificate expires, the publisher can include a trusted timestamp during the signing process. The timestamp records when the software was signed, proving that the signature was applied during the certificate’s valid period. Without timestamping, the software may start triggering warnings after the certificate expires—even if the code hasn’t changed.

5. Distribution and User Download

Once signed, the software is ready for distribution. It may be posted online, sent through email, or delivered through an app store or update server. No matter how it’s distributed, the signature travels with the software, ready to be checked by any system that receives it.

6. Signature Validation by End Users

When a user or system attempts to install or run the software, the operating system or security software performs several checks:

• Verifies the signature matches the code (ensures no changes have been made)

• Confirms the certificate was issued by a trusted authority

• Confirms the certificate has not expired or been revoked

• Validates the certificate chain back to a trusted root authority

• If timestamped, verifies the time was valid during signing

If all checks succeed, the software is considered trustworthy. If any step fails—for example, if the certificate has been revoked or the code is altered—the user will be shown a security warning or the installation may be blocked entirely.

Why Timestamping Matters in Code Signing

Timestamping plays a crucial role in the long-term trust and validity of signed software. It ensures that even when a code signing certificate expires, the software signed with it continues to be recognized as legitimate—as long as it was signed while the certificate was still valid. Without timestamping, a perfectly safe and unchanged application may start triggering security warnings after the certificate expiration date, resulting in confusion for users and unnecessary credibility issues for publishers.

To understand why timestamping is important, think of a code signing certificate like a passport. A passport may expire after ten years, but it doesn’t invalidate past travel records or contracts signed before the expiration date. Timestamping in code signing works the same way: it records the exact time when the software was signed and proves the signature was created within the valid period of the certificate.

How Timestamping Works

The timestamping process involves adding a trusted time source into the signature during the signing process. Here’s how it fits into the workflow:

1. The software developer signs the code using their private key and code signing certificate.

2. A request is sent to a timestamp server (also known as a Time Stamp Authority or TSA).

3. The timestamp server returns a cryptographic timestamp, proving the date and time the signature was created.

4. The timestamp is embedded into the software’s digital signature.

Now, when a user installs or runs the software, their device checks not only whether the code was signed using a valid certificate, but also whether it was signed during the certificate’s valid period. If the timestamp shows the correct period—before expiration—then the signature remains trustworthy even if the certificate itself has since expired.

What Happens Without Timestamping?

When software is signed without a timestamp:

• The signature becomes invalid after the certificate expires.

• Users may encounter errors like “The digital signature is invalid” or “Unknown publisher.”

• Operating systems and security tools may block installation, display warnings, or require extra permissions from users.

• Software that was once trusted may suddenly seem suspicious, damaging the reputation of the developer or company.

This creates unnecessary obstacles and mistrust—especially for software with a long shelf life or meant for distribution beyond the developer’s immediate control.

Benefits of Timestamping

Timestamping brings several key benefits for both publishers and end users:

• Preserves trust after certificate expiration: Signed code remains trusted indefinitely, as long as the original signature and timestamp are intact.

• Reduces the need for frequent re-signing: Developers don’t need to re-sign all previously distributed builds every time a certificate expires.

• Improves distribution lifecycle: Software, installers, and drivers can be distributed and installed securely far beyond the certificate’s active life.

• Prevents unnecessary warnings: Timestamping prevents users from receiving confusing warnings or installation blocks due to certificate expiration.

• Strengthens integrity validation: Ensures the signature hasn’t been altered and that the code hasn’t been modified since signing.

Timestamping is not strictly required for code signing to work—but in practice, it is considered a best practice and a vital step for professional software distribution. Whether you’re signing desktop applications, drivers, mobile apps, or scripts, including a trusted timestamp ensures that your software doesn’t lose its integrity or trustworthiness over time.

Platform Verification Models (Windows, macOS, Android, Linux)

Once software has been signed using a code signing certificate, the next critical phase occurs on the user’s system—known as signature verification. This is where platforms like Windows, macOS, Android, and Linux assess the integrity, origin, and trustworthiness of the software before it is allowed to run. Although code signing works on a similar principle across all platforms, each operating system has its own verification method, security model, and user experience.

Understanding how each platform handles signed software is essential not only for developers but also for IT teams distributing software across multiple environments. It also helps clarify why a piece of software may install smoothly on one platform but be blocked or require additional approvals on another.

Windows (Authenticode and SmartScreen)

On Windows, code signing is primarily governed by Authenticode, Microsoft’s digital signature technology for software verification. When a user runs or installs a signed application, Windows checks the embedded signature and certificate and validates the chain of trust. If successful, the user sees that the software comes from a known publisher.

Windows also employs Microsoft SmartScreen, a reputation-based filter for downloaded software. Even properly signed applications may display a warning if they are new, rare, or if the certificate doesn’t yet have an established reputation. With an EV (Extended Validation) code signing certificate, SmartScreen reputation is often built-in, leading to fewer interruptions for users during installation.

For critical system software such as kernel-mode drivers, Windows imposes even stricter requirements. Starting with Windows 10, kernel-mode drivers must be signed using an EV certificate and submitted to Microsoft for attestation before they will be accepted at the OS level.

macOS (Developer ID and Gatekeeper)

On macOS, Apple handles code signing using a combination of Developer ID certificates, built-in signature checks, and a security feature called Gatekeeper. Software distributed outside the Mac App Store must be signed with a Developer ID certificate issued through an Apple developer account. Once signed, the software can be distributed independently and installed by users.

However, since macOS Catalina, signing alone is no longer sufficient. Apple introduced a process called notarization, requiring developers to submit signed applications to Apple for automated security scanning. Only after passing notarization can the software avoid Gatekeeper warnings during installation. If a file lacks either a valid signature or notarization status, macOS may block it entirely with messages like “This app cannot be opened because the developer cannot be verified.”

Android (APK Signing)

On Android, all applications must be signed before they can be installed, whether through the Google Play Store or sideloaded. Unlike desktop platforms, Android does not allow unsigned apps to be installed by default. The signing certificate for Android apps is tied to the app’s identity, updates, and upgrade path.

Unlike Windows or macOS, Android typically does not rely on external Certificate Authorities for code signing. Instead, developers generate their own signing keys and maintain them over the lifetime of the app. If the key is ever lost or compromised, the app cannot be updated—making key security vital.

Linux (Software Packages and Repositories)

Linux does not have a single universal code signing model, but most major package types support built-in signature verification. For example:

• RPM packages (used in Red Hat, Fedora, CentOS) support GPG signatures.

• DEB packages (used in Ubuntu, Debian) support maintainers signing metadata and release files.

• JAR files for Java applications can be signed using JAR signing tools.

• Modern DevOps workflows also use code signing-style systems for container images, using tools like cosign to ensure image integrity.

In Linux environments, package managers such as apt or dnf verify both the software and repository signatures before installation. If a package signature is missing or incorrect, it is often rejected outright.

The 2023 Hardware Key Requirement for Code Signing

Until recently, many software publishers stored their code signing private keys in software-based formats—either on local machines, build servers, or shared network drives. While convenient, this left keys vulnerable to theft, misuse, or malware-based extraction. In response to escalating attacks on code signing infrastructure, the Certificate Authority/Browser (CA/B) Forum updated its industry standards in 2023 to require that all new publicly-trusted code signing certificates use hardware-based private key protection. This applies not only to Extended Validation (EV) certificates, but also to Organization Validation (OV) certificates.

What Changed?

As of June 1, 2023, the CA/B Forum’s new Baseline Requirements state that the private keys associated with code signing certificates must be stored in secure cryptographic hardware that meets one of the following security standards:

• FIPS 140-2 Level 2 or higher

• Common Criteria EAL4+ or equivalent

The hardware must prevent direct extraction of the private key, and must enforce strong authentication before the key can be used for signing. This includes devices such as hardware security modules (HSMs), USB cryptographic tokens, or smart cards—rather than unprotected software-based .pfx or .pem files.

Why This Matters

This change was introduced to combat a growing trend: attackers stealing code signing keys and using them to sign and distribute malware that appears legitimate. The private key is the single most sensitive asset in the code signing process. Any compromise of it effectively allows attackers to impersonate a trusted developer and bypass security controls on platforms like Windows and macOS. Well-known supply chain attacks—including those affecting major software vendors—have exposed how easily unsigned or forged code can slip through defenses if the signing key isn’t properly protected.

By requiring hardware-backed storage, the industry has significantly raised the bar for code signing security. A stolen code signing certificate stored as a file might once have been extracted in minutes, but extracting one from an HSM or cryptographic token would require physical access, advanced tooling, and often bypassing tamper-resistant protection.

What This Means for Developers and Organizations

Whether you’re a solo developer or part of a large engineering team, the new standard affects how you acquire, store, and use code signing certificates:

• You must use hardware-backed storage when purchasing or renewing a code signing certificate.

• You’ll need compatible tooling that integrates with physical tokens or HSM-backed certificate stores for signing operations.

• Automated signing in CI/CD pipelines now requires new workflows, such as remote signing or delegated signing services that keep keys in compliant hardware.

• Shared access to signing keys must be controlled and audited, since keys can no longer be copied between machines or shared as files.

In practical terms, this means that the traditional model—where a .pfx file was installed on a build server and used silently by the signing tool—is no longer acceptable for public code signing. Many certificate providers now issue OV and EV certificates pre-loaded on USB hardware tokens, and most also support cloud HSM alternatives that allow secure signing over API-based workflows.

Adapting to the 2023 Requirements

For development teams, adapting to this requirement often involves changes such as:

• Using signing tools that support hardware devices (e.g., signtool, jarsigner, osslsigncode, macOS codesign)

• Moving signing operations out of fully automated CI/CD and into secure build stages with controlled manual approvals

• Using cloud-based signing services or HSM-backed platforms (e.g., Azure Key Vault with a code signing extension)

• Implementing key usage policies and maintaining audit logs for compliance tracking

Even though these changes may introduce new workflows and costs, they provide vital safeguards against certificate theft and code forgery, especially in high-risk environments like open-source distribution or enterprise software delivery.

Signing and Verifying Software (Step-by-Step Examples)

Code signing isn’t a single process—it varies depending on the platform, type of file being signed, and the tools used to execute the signing and verification. Below are step-by-step examples for some of the most common environments, including Windows, macOS, Java applications, and Linux package workflows. These snippets are crafted to be beginner-friendly, while still useful for experienced engineers who need a quick reference.

1. Signing and Verifying on Windows (Executable Files)

On Windows, software signing is handled using Microsoft’s Authenticode. The most widely used tool for code signing and verification is signtool.exe, which is part of the Windows SDK.

Signing a .exe or .dll file

• /f — Path to the certificate file (often .pfx)

• /p — Password for the private key

• /tr — URL of the timestamp server

• /td — Timestamp hash algorithm (SHA-256 recommended)

• /fd — File digest algorithm

Verifying the signature

• /pa uses the default Authenticode verification policy

• /v enables verbose output to display certificate details and chain validation

2. Signing and Verifying Apps on macOS (Apple Developer ID)

macOS requires that software distributed outside the App Store be signed using a Developer ID Application certificate obtained through an Apple Developer account. Signed apps must also be notarized by Apple to avoid Gatekeeper warnings.

Signing a macOS application

• --deep ensures nested binaries (like frameworks) are also signed

• --sign specifies the Developer ID certificate

Submitting for notarization

Apple will issue a ticket upon success, which will be stapled to the app during distribution.

Verifying signature and notarization

The spctl tool checks both signature and notarization status.

3. Signing Java Applications (JAR Files)

Java Archives (JARs) are commonly used to distribute Java-based software. The jarsigner tool is used to sign JARs using a keystore that contains the developer’s private key and certificate.

Signing a JAR file

The -tsa flag timestamps the signature.

Verifying a JAR file

Verification checks the signature integrity and displays certificate chain information.

4. Verifying Linux Software Packages

Linux distributions use several types of packaging formats that support built-in signature validation.

Checking an RPM package

Checking an APT repository or package signature

Package metadata in APT-based distributions (like Ubuntu) is signed using GPG. Verification is handled automatically when you install a package using apt, but can be checked manually:

Container Image Signing Example (Cosign)

Modern DevSecOps pipelines often include signing artifacts like container images, binaries, or deployment packages, to validate them before executing in production environments.

These code signing workflows form the backbone of secure software distribution across platforms. They protect users from tampered or impersonated applications and help developers establish long-term credibility and trust.

Common Errors and Troubleshooting in Code Signing

While code signing provides a trusted mechanism for distributing software, issues can still arise—either during the signing process itself or when end users attempt to install or run signed applications. These problems can lead to confusing error messages, installation blocks, or trust failures. Understanding the most common code signing errors and their causes can save valuable time during development and reduce friction for end users and IT teams.

Below are some of the most frequent code signing-related errors across platforms, along with clear reasons and fixes.

1. “Unknown Publisher” Warning (Windows)

Where it appears: When installing or opening a Windows executable or installer.

What it means: The application is either not signed or the certificate chain used for signing cannot be verified. Windows does not recognize the identity of the application’s publisher.

Common causes:

• The executable or installer was not signed.

• The wrong certificate was used (e.g., a test certificate).

• The certificate’s root or intermediate certificates are missing.

• No timestamp was applied, and the certificate is now expired.

How to fix:

• Ensure the application is properly signed with a valid public code signing certificate.

• Include all intermediate certificates in the signature chain.

• Use a timestamp server while signing to preserve trust after certificate expiration.

• Test signature validity using signtool verify /pa /v.

2. SmartScreen Blocks the Application (Windows)

Where it appears: When downloading or running an application that triggers Microsoft SmartScreen filter warnings.

What it means: Windows SmartScreen has not yet established a trust reputation for the signed application, or the signature does not meet the criteria for automatic trust.

Common causes:

• The code signing certificate is new and has no reputation.

• An OV (Organization Validation) certificate was used instead of EV (Extended Validation).

• The software was distributed in small volumes, limiting reputation data.

How to fix:

• Use an EV certificate to bypass SmartScreen for most new applications.

• Release software via trusted distribution channels to build reputation faster.

• Ensure the application has been properly timestamped and signed by the correct identity.

3. “The Application Cannot Be Opened” (macOS Gatekeeper)

Where it appears: When opening a downloaded .app or autonomous script on macOS.

What it means: The app has either not been signed with a valid Apple Developer ID, or it was not properly notarized after signing.

Common causes:

• Developer did not sign the binary with a valid certificate.

• The binary was not submitted for notarization with Apple.

• The certificate used for signing was revoked or expired.

How to fix:

• Sign the application using a Developer ID Application certificate.

• Submit it to Apple for notarization using xcrun altool or notarytool.

• After notarization, staple the ticket to the .app with xcrun stapler.

• Test the app with spctl --assess --verbose=4.

4. “Signature Invalid or Has Been Altered” (Any Platform)

Where it appears: During installation, update checks, launch, or verification of signed software.

What it means: The signature does not match the content. Either the code was modified after signing or the signer certificate is no longer valid.

Common causes:

• The code was re-packaged, updated, or edited after being signed.

• The hash of the code does not match the original signature.

• The certificate was revoked by the issuing authority.

How to fix:

• Re-sign the application after making any changes.

• Check whether the code signing certificate has been revoked or replaced.

• Avoid manual changes to the binary, installer, or package after signing.

5. Timestamp or Expired Certificate Errors

Where it appears: Signed application installs fail or display warnings after the certificate expiration date.

What it means: Either the code was not timestamped during signing, or the timestamp is missing or invalid.

Common causes:

• Lack of timestamp at the time of signing.

• Timestamp server was unavailable or rejected the request.

• Unsigned metadata or installer wrapper.

How to fix:

• Always use a timestamp server when signing (e.g., /tr http://timestamp.digicert.com).

• Re-sign with timestamp and redeploy if possible.

• Verify timestamp validity using platform tools (e.g., signtool verify or jarsigner -verify -verbose).

These common issues can often be avoided by following best practices in code signing: secure private key storage, using platform-appropriate signing methods, applying timestamping, and leveraging Extended Validation certificates where appropriate. By understanding the root causes of failure and preparing for platform-specific requirements, developers can ensure their software is trusted and installable across environments.

Best Practices for Secure and Scalable Code Signing

Code signing is a powerful tool for establishing trust and preventing unauthorized software distribution, but its effectiveness depends heavily on how well it is implemented. A weak or poorly protected code signing process can expose your organization to serious risks, including malware impersonation, certificate theft, and application blockages. Following best practices ensures not only secure but also scalable management of code signing certificates across development and deployment environments.

Below are the essential best practices for building an effective and secure code signing process.

1. Protect Private Keys with Hardware-Based Storage

The most critical asset in the code signing process is the private key. If a private key is exposed or stolen, attackers can impersonate your identity and sign malicious code that appears trustworthy. To mitigate this risk:

• Store private keys exclusively in tamper-resistant hardware such as USB cryptographic tokens, smart cards, or Hardware Security Modules (HSMs).

• Avoid storing keys in plain files or shared systems like build servers or source control.

• Make key access depend on physical possession (e.g., USB token) or secure policies (e.g., HSM-based access control).

As of 2023, public code signing standards require hardware protection for most certificates. Treat this not just as a requirement, but as a critical safety measure.

2. Always Timestamp Your Signed Code

Without timestamping, a software signature becomes invalid once the certificate expires, even if the code hasn’t changed. Timestamping extends the life of your signature indefinitely as long as the signing time is within the certificate’s valid period. It ensures:

• Signed releases remain trusted after certificate expiration.

• End users don’t see “invalid signature” or “expired certificate” warnings.

Make timestamping a mandatory part of the signing process, using a public timestamp service from a trusted provider.

3. Use Appropriate Certificate Types for Distribution Needs

Code signing certificates come in different validation levels, such as OV (Organization Validation) and EV (Extended Validation). Choosing the right one matters:

• EV certificates provide immediate trust and SmartScreen reputation in Windows, and are required for signing kernel drivers.

• OV certificates are suitable for internal or less public use cases but take longer to build SmartScreen trust.

Match the certificate type to your distribution model and audience to reduce unnecessary barriers for your users.

4. Integrate Signing into Automated Build Systems — Safely

Developers and DevOps teams often want to automate code signing as part of continuous integration (CI) pipelines. This is possible, but only if done securely:

• Use remote signing services or HSM-backed certificates rather than exposing private keys to the build system.

• Avoid storing certificate files or passwords in scripts, environment variables, or shared build artifacts.

• Enforce access control and auditing where signing is part of CI/CD.

Secure automation reduces manual work while protecting the key integrity that code signing depends on.

5. Implement Role-Based Access and Approval Workflows

Only authorized personnel should be able to sign code. A scalable signing practice requires that:

• Key access is limited to specific roles (e.g., release managers, build engineers).

• All signing operations are logged and traceable.

• Higher-risk signing tasks (e.g., production releases) require peer review or approval.

This prevents misuse and maintains compliance with internal and external security policies.

6. Monitor Certificates and Prepare for Revocation

Code signing certificates should be continuously monitored, just like TLS certificates. This includes:

• Tracking expiration dates and renewal cycles.

• Watching for revocation events from the Certificate Authority.

• Maintaining an incident response plan in case a private key is compromised.

If a code signing certificate is ever revoked, you should be ready to quickly reissue a new one, re-sign your software, and notify users if necessary.

7. Separate Development, Test, and Production Signing

Never use the same certificate to sign applications in development, QA, and production environments. This can lead to:

• Test software being mistakenly trusted in production.

• Exposure of certificate details unnecessarily across environments.

Assign separate certificates (or test certificates) for internal builds, keeping production certificates reserved for public or customer-facing releases.

Conclusion

Code signing certificates play a crucial role in the modern software ecosystem. Whether you are distributing a desktop application, mobile app, driver, script, or embedded system, code signing establishes an unbroken chain of trust between your product and the people who use it. It ensures that users can verify where your software came from and that it hasn’t been altered or tampered with along the way.

But code signing is more than just a technical checkbox—it’s a security commitment. From protecting private keys with hardware to using timestamping for long-term validity and adapting to platform-specific requirements like Apple notarization or Windows SmartScreen reputation, a strong code signing strategy protects both your software and your reputation.

As software supply chain attacks become more sophisticated, properly managing and securing your code signing certificates isn’t just good practice—it’s essential. By following the best practices outlined in this guide and treating your signing workflow as a core part of your development lifecycle, you’re not only safeguarding your users, but also elevating the trust and professionalism of your brand.

If you’re ready to implement or optimize your code signing process, use this article as a roadmap. Build securely. Sign responsibly. And distribute software that users—and operating systems—can trust from the first click.

Frequently Asked Questions (FAQs)

What is a code signing certificate?

A code signing certificate is a digital certificate used by software publishers to sign applications, scripts, or executables. It binds the identity of the publisher to the signed code and prevents tampering by verifying the integrity of the content. When the software is opened or installed, the operating system checks the signature and certificate to ensure the code is safe and authentic.

How does code signing prove software integrity?

When software is signed, a cryptographic hash of the application is generated and encrypted with the publisher’s private key. This digital signature is validated using the corresponding public key. If the hash of the executable no longer matches the signature, the operating system knows the software has been modified and will refuse to trust it.

What’s the difference between OV and EV code signing certificates?

An OV (Organization Validation) certificate confirms the identity of an organization or developer, while an EV (Extended Validation) certificate includes stricter identity vetting and offers higher trust from systems like Microsoft SmartScreen. EV certificates are required for signing Windows kernel-mode drivers and often allow software to avoid initial reputation warnings.

Does code signing guarantee software is safe?

No. Code signing verifies who published the software and whether it has been altered, but it doesn’t guarantee the software is bug-free, safe, or free from vulnerabilities. It prevents tampering but doesn’t replace proper testing or security reviews.

Why do I still see a warning for my signed application?

Warnings such as “Unknown Publisher” or SmartScreen prompts can appear if:

• The software isn’t timestamped and the certificate has expired.

• The certificate’s trust chain isn’t fully installed.

• The signing certificate doesn’t yet have enough reputation on Windows.

• The application was re-packaged or modified after signing.

What happens if a code signing certificate is compromised?

If a certificate’s private key is stolen or misused, the publisher must immediately revoke the certificate. Signed applications may start to show warnings or be blocked by operating systems. A new certificate should be issued, and all software must be re-signed using the new certificate to restore trust.

Why is timestamping important in code signing?

Timestamping ensures that the software signature remains valid even after the certificate has expired, as long as the code was signed while the certificate was still valid. Without timestamping, software will start showing errors once the certificate expires, even if the software hasn’t changed.

Do I need a code signing certificate to distribute macOS apps?

Yes, if you plan to distribute apps outside the Mac App Store. macOS requires applications to be signed with a Developer ID certificate, and most software must also be notarized by Apple to run without warnings from Gatekeeper.

Can I use the same certificate for testing and production?

It is not recommended. Test certificates should be separate from production certificates to prevent untrusted builds from being mistakenly released. Production code signing certificates should only be used in controlled environments with strict access control.

Are code signing certificates required for Android apps?

Yes. Android apps must be signed before installation. Developers generate their own signing keys and use them consistently across application updates. Unlike Windows and macOS, Android doesn’t use public CAs to verify publisher identity but relies on key-based trust between versions.