GlobalSign offers two types of Code Signing Certificates. 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. EV Code Signing Certificates undergo strict Extended Validation vetting requirements set by the CA/B Forum.
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?
Yes. Both, the Standard Code Signing Certificates and the EV Code Signing Certificates have 3 ordering options and can be delivered to SafeNet tokens, HSMs as well deployed with Azure Key Vault. Please refer to the 'Key Storage Options' on the table comparison here
Can I use the same Certificate on multiple computers?
Yes, but not simultaneously, since the Safenet token 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?
Both the Standard Code Signing Certificates and 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.
How to enable the token Single Sign On?
To enable the token single sign on, open the Safenet Authentication Client (SAC). Then click, 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 to disable 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, 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 SHA-1 Code Signing Certificate and another signature can use a SHA-2 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 SHA-1 and SHA-2 Code Signing Certificate, you can simply reissue your SHA-1 or SHA-2 Certificate and change the signature algorithm during the process. This will result in two valid Code Signing Certificates. One signed with SHA-1 the other with SHA-2.
If you have two Certificates and would like to Dual Sign your files please follow this DualSigning Guide
Note: this option is only available for standard Code Signing Certificates, EV Code Signing is SHA-256 only and cannot be changed. You can, however, dual sign with a standard SHA-1 Code Signing Certificate and a SHA-256 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 Java KeyTool (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.