FAQ: Code Signing
This FAQ answers some of the most common questions regarding Code Signing certificates.
How is a Code Signing certificate different from other x.509 v3 certificates?
Digital certificates contain fields such as Key Usage and Extended Key Usage that dictate the purpose of the certificate.
Where an SSL certificate for a website would contain an extended key usage of Server Authentication (showing it can be used to identify a server), a code signing certificate has an extended key usage of Code Signing to indicate that it may be used to sign code.
There are other values that get populated into these fields depending on certificate type. Limiting the use cases of digital certificates mitigates some risk in the event of a compromised certificate. A certificate with all key purposes enabled would pose a much greater risk in the event of a compromise.
Are there different types of Code Signing certificates?
Yes. TRUSTZONE offers both Standard and EV (Extended Validation) Code Signing certificates.
What is the difference between Standard and EV Code Signing?
Standard code signing certificates undergo standard organization validation. EV code signing certificates go through strict Extended Validation vetting requirements set by the CA/B Forum.
Among added benefits of EV Code Signing certificates is the fact that they provide an instant reputation with Microsoft Smart Screen. Standard Code Signing certificates must build up a reputation with the Smart Screen program before Smart Screen warnings disappear.
EV Code Signing certificates are also required to access the Windows Hardware Developer Center Dashboard Portal through which all kernel-mode drivers targeting Windows 10 (Build 1607 and later) must be signed.
Are there different ordering options for Standard and EV Code Signing certificates?
EV Code Signing Certificates are SHA256 only. An EV Code Signing Certificate can be delivered to a USB Hardware token that hosts the certificate’s private key.
TRUSTZONE includes a USB SafeNet eToken 5110 with every new EV Code Signing Order, but you can also rent space for your private key on an HSM (hardware security module) or for that matter invest in an HSM situated on your own premises.
Standard Code Signing Certificates can only be issued with the SHA2 hash algorithm. These certificates can be delivered with a USB token or be used with an HSM. Other standard Code Signing certificates can be installed as a .pfx-file (p12).
Can I use the same certificate on multiple computers?
With certain types of Standard Code Signing certificates, you can copy your certificate .pfx file from one computer to another. This is beneficial when multiple developers within your company sign your code. It is highly recommended though to transfer certificates between workstations via a secure method such as sftp.
The token-based type of Standard Code Signing certificates can also be used on multiple computers. The same goes for token-based EV certificates. But no token-based certificate can ever be used simultaneously on two computers since the SafeNet token can only be plugged into one computer at a time. As long as the SafeNet drivers are present on another computer though, the token can be plugged into that workstation for use.
Naturally, HSM-based certificates can be shared and used simultaneously on multiple computers. These certificated are specially designed to make way for code signing performed by several developers within your organization.
Can I sign a file remotely?
Some Standard Code Signing Certificates can function if you have access to the relevant .pfx file. With such access, you will indeed be able to sign code on a computer outside your normal office parameters.
Standard and EV Code Signing certificates using HSM to host the private key also allows for remote signing, while all token-based certificates prohibit that option.
How to enable the token Single Sign-On?
To enable the token single sign-on, open the SafeNet Authentication Client (SAC). Click on “Client Settings”. Under the “Advanced” tab, tick the box for “Enable single logon” as shown in the diagram below. Click “Save” for the changes to take effect.
Note: This feature is best for customers who wish to batch sign code. This way you don’t have to enter the token password every time. However, for regular code signing, we highly recommend disabling this feature as this is not a good practice.
Do different platforms have different requirements for signing code?
Yes. The code signing requirements will vary from platform to platform. The requirements for signing Java JAR files will differ from signing a Windows portable executable.
There are also separate requirements for signing apps on OS X and iOS. How and where your application(s) will be distributed, may also be a factor in signing requirements.
What are the requirements for signing code in Windows?
The requirements for Windows code signing will vary depending on which version(s) of Windows you are targeting and what type of code you are signing.
Microsoft has different requirements for code that will run in user-mode versus code that will run in kernel-mode.
Code that runs in user-mode can use certificates that chain back to a trusted CA, such as GlobalSign. For kernel-mode signing, the certificate chain must terminate at Microsoft’s Root CA.
To accomplish this, TRUSTZONE provides a cross-certificate that allows our code signing certificates to chain back to Microsoft’s Root CA and be trusted for kernel-mode signing.
Windows 10 has an additional requirement. Kernel-mode drivers must be signed by the Windows Hardware Developer Center Dashboard Portal which requires an EV Code Signing certificate to access.
Are there any additional requirements or factors with Windows code signing?
Another factor is the signature algorithm used to sign your certificate as well as the signature algorithm used to sign code. For more specifics on these requirements, view our Windows Code Signing Hash Algorithm Support article.
Do I need to sign all DLL’s included with my application?
Windows does not check signatures on DLLs when loaded by an executable. There are exceptions to this such as DRM-related DLLs, and all modules on WindowsRT/ARM.
If those scenarios do not apply, it is not necessary to sign the DLLs, however, a reason to sign each DLL is to run an integrity check each time your application launches.
What utilities are generally required to sign files?
Microsoft SignTool is the standard utility for signing drivers and executable files. It is bundled as part of the Windows SDK. SignTool can sign using a local .pfx or it can leverage certs in your Windows certificate store. It works with both standard and EV code signing certificates.
Many development applications have native support for code signing using either the .pfx or certificate store method. For example, when signing VBA macros through Excel, the application will use certs from your local certificate store. Other applications such as InstallShield also support integrated code signing.
Jarsigner is a utility bundled with the Java JDK and can be used to sign certificates. Generally, if signing code for Java, you’ll create a Java Keystore (.jks) with JavaKeyTool (also bundled with the JDK), however, Jarsigner also has support for .pfx files, provided you know the alias.
EV Code Signing also works with Jarsigner. It is a bit more advanced and involves editing a configuration file to specify the slot of the USB token. More details in Java EV Code Signing article.
While both standard and EV Code Signing certificates can sign .dmg and .app files, the local default Gatekeeper policy on OS X and the Apple App Store policy requires the use of a certificate issued by Apple tied to an Apple Developer ID.
Code signing certificates from other CAs can still be used to sign things like profiles and policies on OS X. The default utility on OS X to sign code is called codesign. More information on this utility can be found in the product manual.