Skip to main content

Code signing is the process of digitally signing executable files and scripts using a signing tool and a digital certificate. This process is based on a technology called public key infrastructure (PKI).

Signing code requires a dedicated signing tool such as Microsoft’s SignTool, Java’s Jarsigner, or even OpenSSL depending on the type of file to sign. The signature itself is a cryptographic operation that binds the content of the file to a digital certificate.

What is the purpose of digitally signing code?

There are two main reasons for digitally signing code:

  1. To provide users with the identity of the organization publishing the signed file
  2. To provide a means to verify the integrity of the file – that is to say, that it was not corrupted or maliciously altered since it was signed

How does code signing provide the identity of the organization publishing the signed file?

A digital signature creates a cryptographic bond between a file and a digital certificate, the latter representing an organization. You can think of the certificate as a digitized rubber stamp; it contains details about the organization such as its legal name, email address, physical address, and country. Signing code therefore corresponds to applying a digital stamp to the code, which will display the organization’s details.

The details of a code signature can be checked each time the signed file is opened. In most cases, this is done automatically by operating systems, showing you the name of the organization contained in the certificate used for the signature.

User Account Control Prompt

Opening a digitally signed executable file on Microsoft Windows 10.

How does code signing provide a means to verify the integrity of the file?

Every code signature is created based on the content of the file. Without going into too much technical detail, a signing tool will calculate a condensed version of the file to sign – we call it a hash – and will sign this condensed version using the digital certificate provided. This signed hash is then embedded into the file in a place dedicated to hosting digital signatures.

Once you start distributing the signed file, operating systems and relevant applications will detect the presence of the signature. They will automatically calculate the hash of the file (without including the signed hash in the calculation) and compare it to the signed hash embedded in the file. If they are both the same, the verification passes. If the calculated hash is different than the signed hash, it fails. A failed verification means the content of the file has been modified after the signature was performed (as a result of an error or a malicious intent).

The reliability of this mechanism is based on the strength of the algorithm used to calculate the hash – the longer the hash, the better. One of the current standards used is SHA-256, an algorithm that produces 256-bit hashes.

What are the benefits of code signing?

There are several benefits of digitally signing code:

  • You increase user confidence in your software. Signed code proves that the file not only belongs to the expected organization, but also guarantees that it hasn’t been tampered with (to inject malware, for example).
  • You increase your reputation as a software developer. The more signed software you publish, the better your reputation will be. For example, Microsoft code signs their software to help ensure their customers are downloading the right files. Signed software is also helpful to antiviruses and malware detectors. If you sign your software, they’ll be able to flag suspicious, unsigned versions of your software.
  • You avoid warnings and blocks from operating systems. They indeed expect all software publishers to sign their executable files. If you publish unsigned software and your users launch it, there’s a very good chance they will see a warning message from the operating system. MacOS is known for refusing to launch unsigned files, forcing the user to bypass security to proceed with the installation.

Warning message prompt

A warning message for unsigned software installation on Microsoft Windows 10.

Blocking message prompt

A blocking message for unsigned software installation on MacOS.

For IoT devices using firmware, one of the best ways to ensure safe updates is to build your firmware with a requirement to only accept updated files that are signed using your internal (private) code signing certificates.

Read the white paper: The Importance of Code Signing

What is the difference between public code signing and private code signing?

Code signing certificates are issued by certification authorities (CAs), which are certificate-issuance engines. Most organizations own one or several “private” (internal) CA(s) and can issue all sorts of digital certificates, including code signing certificates. However, the signatures generated with these certificates are only trusted within the organization’s internal environment.

While this is perfect for many use cases involving internal applications and IoT, using a private CA doesn’t work when you plan to distribute your code outside of your environment, where your CA is not recognized.

Code signing certificates issued by publicly trusted CAs, such as Entrust’s, will generate signatures that will be recognized and trusted by all major operating systems and applications globally. Public CA organizations (also simply called public CAs) such as Entrust follow strict certificate issuance standards, must go through regular audits, and must apply to become trusted by each major operating system or application provider such as Microsoft, Apple, Google, or Mozilla.

When faced with signed code, operating systems and applications check the issuing CA of the certificate used for the signature. If the issuing CA is not in their “trust list” (also called root store), the signature won’t be trusted and the verification will fail. Hence the importance of getting publicly trusted code signing certificates when publishing software to the internet.

What is the difference between OV code signing and EV code signing?

While organizations are free to include any details they want in their private code signing certificates, public certificates must only contain information that has been thoroughly verified by the public CA before issuing the certificate.

A public CA can issue two categories of publicly trusted code signing certificates: OV and EV. These categories correspond to the level of verification of your organization that is performed by the public CA before issuing the certificate, and also the storage requirement for the certificate (specifically, for its private key).

  • OV (Organization Validation): This is a standard validation method of an organization performed by CAs. It involves company checks (Does the company exist? Is it in good standing? Where is it located?) and a verification of the person requesting the certificate on behalf of the organization (Are they indeed an employee of the organization?).
  • EV (Extended Validation): As the name suggests, this is an extended validation process that requires further verification of the organization details as well as the certificate requestor. The CA will require more information and more paperwork, and will proceed with one or several calls to the organization and the requestor before issuing the certificate. Secure storage is mandatory for EV code signing certificates, which means you will either need a secure USB token or a hardware security module (HSM) to store the certificate and its private key.

Entrust can supply USB tokens or nShield HSMs for all code signing orders, whether they are OV or EV certificates.

Learn more about code signing HSMs.

How does timestamping work with a code signing certificate?

In the context of a code signature, timestamping is the process of applying a digital timestamp, which includes the exact date and time, to a code signature.

Timestamping is a crucial yet often forgotten step of code signing. Signatures indeed have an expiration date, which corresponds to the expiration date of the code signing certificate used for the signature. An expired signature will lead to a failed verification when the signed code is launched, which would lead to warning messages and even code being prevented from running.

Private certificates can have a very long lifetime (10+ years) if needed, which is often enough because the signed code might no longer be used after such a long period. But public code signing certificates are currently valid for a maximum of three years, and there’s a very good chance your code will still be available by the end of this period. Timestamping a code signature will give it another 9-10 years of validity (depending on the validity period of the timestamping certificate used). And you can reapply a new timestamp when the current one is about to expire to further extend the validity of your code signature and avoid any warnings/blockings.

Timestamping is also useful in case you need to revoke your code signing certificate if it’s been compromised. Revocation can be backdated to the date and time you believe the certificate was compromised. If all your signatures have been timestamped, then only the signatures generated before the revocation date will remain valid. Any code signature without a timestamp will become invalid when the certificate is expired or revoked.

Timestamping can be done using private timestamping certificates from an internal CA. But for code that needs to be shared externally, you must use a public timestamping service, which will be recognized and trusted by all major operating systems and applications. Most if not all public CAs, including Entrust, offer a public timestamping service, available via a dedicated URL.


👋 Hello, if you have any
questions, I'm ready to chat.

Chat Now