A Code Signing Certificate is a digital certificate that contains information that fully identifies an entity and is issued by a Certificate Authority such as Corporate CA. The Digital Certificate binds the identity of an organization to a public key that is mathematically related to a private key pair. The use of private and public key systems is called Public Key Infrastructure (PKI). The developer signs code with its private key and the end user uses the developer’s public key to verify the developer's identity.

Most mass-market computing devices sold today come with pre-loaded software, but the software that comes “out of the box” with the device is not all that will be needed for the full life of the device. Whether for a personal computer or a mobile device, users will frequently need to download additional software or applications. In other cases users are often advised by an application on their device, or the site they are visiting, that in order to experience or use the offered service they need to upgrade, patch or augment their current software. Users are asked to make a spot decision:

“Run or Don’t Run,” “Install or Don’t Install” or “Run or Cancel.”
In these situations, “Run/Don’t Run” asks the user whether or not to run the downloaded code. How does a user decide? How does a user or user agent (usually a “browser”) know whether or not to trust the software?

The answer is code signing.

To help users determine whether or not they can trust software before they install it, software publishers can digitally sign their code. A digital signature verifies who signed the code and that the code has not been subject to tampering. Digitally signed code, which is backed by a certificate issued by a CA acting as a trusted third party, is granted greater reliability than unsigned code. Generally, unsigned code should not be trusted, as it does not provide any evidence of origin or file integrity, which means the publisher cannot be held accountable for errors and the code is subject to tampering.

Armed with the information provided by a digital signature, users can make a more informed “Run/Don’t Run” decision.

Code signing is the process of digitally signing executables and scripts to confirm the identity of the software author and guarantee that the code has not been altered or corrupted since it was signed. In order to sign the code, a software publisher needs to generate a private-public key pair and submit the public key to a CA, along with a request to issue a code signing certificate. The CA verifies the identity of the publisher and authenticates the publisher’s digitally-signed certificate request. If this vetting and key-verification process is successful, the CA bundles the identity of the publisher with the public key and signs the bundle, thus creating the code signing certificate.

Armed with the code signing certificate, the publisher is ready to sign the code. When the code is signed, several pieces of information are added to the original file holding the executable code. This bundled information is used by the software publisher’s users to authenticate the publisher and check for code-tampering. The entire sequence for bundling the digitally-signed code takes place as follows:

When a user agent loads the code, it checks the authenticity of the software using the packaged signer’s public key, signature and the hash of the file. If the signature is verified successfully, the user agent accepts the code as valid. If the signature is not successfully verified, the user agent will react by either warning the user or rejecting the code, according to the level of security being used. The signature is verified as follows:

If the hash and the certificate are valid, then the code is considered valid. As such, it is accepted by the user agent and presented for installation. If the file is not considered valid, the user agent displays a warning message.

The code has been signed, the user has started installation and verification has taken place. How does the user know whether or not to accept the code?

The user must decide if they trust the software based on the messages above. The statement provides the following:

Program Name:	Adobe Flash Player Installer
Publisher Name:	Adobe Systems, Incorporated
Code Signing Certificate:	The user would need to click on ”Show Details” drop down button, which will display a link to review the certificate.

There are five simple steps users should take to determine whether software can be trusted:

Conversely, here is a dialogue for code that may be untrustworthy:

The program name is “Install.exe,” which is not specific enough to determine what code is being installed. The publisher’s name is “Unknown,” which means that a public CA did not verify the code signing certificate. The code may not be harmful, but it was likely signed with a self-issued code signing certificate. This means the user cannot trust who signed the code.

What happens to signed code when the code signing certificate expires? In many cases, an expired certificate means that the signature validation will fail and a trust warning will appear in the user agent.

Time-stamping was designed to alleviate this problem. The idea is that if a user knows the time when the code was signed and the certificate was confirmed to be valid, then the user will also know the signature was valid at the time the software was published. Put another way, time-stamping is similar to a notarized handwritten signature which includes a third-party’s confirmation of when the document was signed.

The main benefit of time-stamping is that it extends code trust beyond the validity period of the code signing certificate. The code stays good as long as the user can run it. Also, the code signing certificate may be revoked or expire in the future, but the code can remain trusted.

Please note that with some client software, the code verification may not be valid after the time-stamp certificate has expired. The new Minimum Requirements for Code Signing, discussed below, will require time-stamping authorities (TSAs) to use a time-stamping certificate with a maximum validity of 135 months that will be renewed every 15 months. As such, expect time-stamp certificates to have a lifetime of at least 10 years.

Time-stamping the signature is implemented as follows:

Upon receipt of a time-stamped signature, the following steps are completed by the user agent for verification (in addition to verification of the signature on the code itself):

In the event that the code signing certificate must be revoked due to a compromise, the revocation will be made dependent on a specific date. The idea is that code signatures issued before the revocation date will remain valid and the software should still work.

In most cases, software publishers have to sign their code in order to get it installed on an operating system. Publishers can sign their code using a self-signed certificate or using a certificate issued by a publicly trusted CA.

Due to the costs of buying a code signing certificate from a publicly trusted CA, some publishers may decide to try a self-signed certificate, but there are differences between the two types of certificates that should be considered.

Self-Signed Certificate	Certificate issued from a Publicly Trusted CA
Issuer provides their own identity, which is not published as part of the code verification security message	CA performs identity verification, which is displayed in a code verification security message
Issuer provides their own policy and quality	CA issues certificates in accordance with the industry policy and quality
Signatures will provide a warning indicating that the software was created by an “Unknown Publisher”	Signatures will clearly identify the publisher’s name
Compromised certificates cannot be revoked and could harm software user	Compromised certificates can be revoked, and if time-stamping was used, code signed before revocation will remain trusted

To ensure user trust and code longevity, it is recommended that software publishers use a certificate issued from a publicly trusted CA.

Through 2016, there are only requirements for the management and issuance of EV code signing certificates. As of February 2017, a new standard for non-EV code signing certificates will be supported. This standard is required by Microsoft, so all publicly trusted CAs will issue certificates to meet the requirements.

The minimum requirements for code signing were not published by the CA/Browser Forum, but many of the requirements are from their Baseline Requirements. For code signing the minimum requirements also address other items such as

The biggest issue with code signing is the protection of the private signing key associated with the code signing certificate. If a key is compromised, the certificate loses trust and value, jeopardizing the software that you have already signed.

Seven best practices for code signing include:

The biggest issue with code signing is the protection of the private signing key associated with the code signing certificate. If a key is compromised, the certificate loses trust and value, jeopardizing the software that you have already signed.

Seven best practices for code signing include: