This FAQ gives you answers to the most common questions within Code Signing certificates. If you have any questions that are not covered in this FAQ, you are always welcome to send an email with your question to firstname.lastname@example.org
ABOUT CODE SIGNING
Introduction to Code Signing certificates
GlobalSign offers different types of Code Signing certificates separated by target platform and assurance level. In addition to multiple certificate types, the methods and requirements to sign code vary from platform to platform often creating confusion for the end user. This article will clarify the differences between code signing certificate types and answer common questions on code signing requirements for different platforms.
What is a Code Signing certificate?
HOW IS A CODE SIGNING CERTIFICATE UNIQUE FROM OTHER X.509 V3 CERTIFICATES?
Digital Certificate contain fields such as Key Usage and Extended Key Usage that dictate the purpose of a 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 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. GlobalSign offers both Standard and Extended Validation Code Signing Certificates.
What is the difference between Standard and EV Code Signing?
Standard code signing certificates undergo standard organization validation and may be delivered/downloaded locally on a computer. EV code signing certificates undergo strict Extended Validation vetting requirements set by the CA/B Forum and the certificate itself can only be installed on a hardware token in a non-exportable fashion to provide a higher level of assurance.
EV Code Signing certificates have an added benefit of providing instant reputation with Microsoft Smart Screen. Standard Code Signing certificates must build up 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 have only one ordering option and can only be delivered to a USB Hardware token. GlobalSign includes a SafeNet eToken 5100 with new EV Code Signing Orders. EV Code Signing Certificates are SHA256 only.
Standard Code Signing Certificates can be issued with either the SHA1 or SHA2 hash algorithm. Standard Code Signing Certificates comprise
- Multiplatform (Covers: Authenticode, Adobe AIR, Apple, Mozilla & Netscape Objects, VBA Macros)
What are the differences between the Standard Code Signing ordering options?
The only difference between the Multiplatform certificate and the Java certificate is the delivery method. The Multiplatform certificate will be delivered as a .pfx containing the private key, signed certificate, and intermediate. This can either be used "as is" or imported into a certificate store for most use cases.
Java Code Signing uses jarsigner to sign jar files and supports Java Keystores (.jks). Jarsigner does not support .pfx files. As such, we change the delivery method for Java Code Signing certificates to prompt the applicant for a CSR, and the system will return a signed certificate that can be imported into a Java keystore.
Can I use the same certificate on multiple computers?
With Standard Code Signing, you can copy your certificate .pfx or .jks from computer to computer to be used locally. This is ideal where multiple developers within your company might be signing code. It is highly recommended to transfer certificates between workstations via a secure method such as sftp.
GlobalSign also offers unlimited free reissues. You may also want to reissue your code signing certificate to create a new instance and download it to a new workstation. In a reissue, the keypairs will be unique.
For EV Code Signing, the USB can only be plugged in to one computer at a time. As long as the SafeNet drivers are present on another computer, the token can be plugged in to that workstation for use.
Can I sign a file remotely?
Standard Code Signing Certificates can be accessed remotely by selecting the relevant .pfx or .jks keystore. EV Code Signing Certificates cannot be accessed through Remote Desktop (RDP). The USB token must be plugged in to the local computer.
A local USB token can be used to sign a file on a remote machine but a remote USB Token cannot be used for signing at all.
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, GlobalSign 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.
Can I sign a file to support multiple Windows versions with different requirements?
In most cases, yes, you can use "Dual Signing" to place multiple signatures on a file. One signature could use a SHA1 code signing certificate and another signature can use a SHA2 certificate. Formats supporting dual signatures include: .exe, .dll, and .sys.
MSI installers do not support dual signatures. More information on dual signing including MSI support, can be found in this Microsoft article.
To get a standard SHA1 and SHA2 Code Signing certificate, you can simply reissueyour SHA1 or SHA2 certificate and change the signature algorithm during the process. This will result in two valid code signing certificates. One signed with SHA1 the other with SHA2.
Note: this option is only available for standard code signing certificates, EV Code Signing is SHA256 only and cannot be changed. You can, however, dual sign with a standard SHA1 code signing certificate and a SHA256 EV code signing certificate.
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.