OV code signing certificates and key generation methods are getting an overhaul. They’ll be issued on physical security hardware in a process similar to how EV code signing certificates are currently issued. Explore what this change means for your organization
Earlier this year, NVIDIA experienced what happens when bad guys get their hands on some of your organization’s most sensitive digital assets: code signing certificates. Cybercriminals used these stolen certificates to sign their malicious software. The purpose? To make it look like the malware programs legitimately came from the graphics processor company.
Preventing attacks like that is why the CA/B Forum has voted to make some changes to the issuance and installation process for code signing certificates. But what do these changes mean for your business and code signing operations?
Let’s hash it out.
What You Need to Know (An Overview of the OV Code Signing Certificate Changes)
We won’t dive too deep into all of the details since they’re still being hashed out by the certificate authorities (CAs). Our intention here is to give you a quick overview of what to expect in the coming months. We’ll publish another blog posts in a few months’ time that will talk more about the specifics once we know more from the CAs.
What Will Occur Once the Change Rolls Out
Starting Nov. 15, new and reissued publicly trusted organization validation (OV) and individual validation (IV) code signing certificates will have to be issued or stored on preconfigured secure hardware by the issuing certificate authority (CA). In particular, this includes FIPS 140-2 Level 2, Common Criteria EAL 4+ (or equivalent) compliant devices or signing solutions (as a minimum) such as:
- Hardware security modules (HSMs), either cloud or physical appliances
- Physical security tokens such as USB hardware devices
- Key storage and signing services
Note: FIPS stands for the Federal Information Processing Standards (FIPS). We’ll speak more about FIPS-compliant devices in a few moments.
Practically speaking, this will mean that all code signing certificates will be delivered in a way similar to how EV code signing certificates are today — shipped to the customer on a USB device, delivered to the customer’s hardware security module (HSM), etc. (We’ll share specific details about how all of this will work once the individual CAs announce them.)
But a key takeaway is that you’ll no longer be required to complete certificate signing requests (CSRs) yourself anymore since all that technical stuff will be handled on the CA’s end.
Why These Changes Are Occurring
These changes are outlined in the CA/Browser Forum (CA/B Forum) Baseline Requirements (BR) for the Issuance and Management of Code Signing (version 2.8). It was updated via Ballot CSC-13 — Update to Subscriber Key Protections Requirements, which applied to the previous version of the baseline requirements (v. 2.7). The idea here is to make the certificates’ private keys as secure as they would be with extended validation (EV) code signing certificates.
To accomplish this, it means that keys need to be securely stored to keep them out of the hands of bad guys (and other unauthorized users). According to section 16.3.1 Subscriber Private Key Protection of the code signing certificates BR (version 2.8):
“The CA MUST obtain a contractual representation from the Subscriber that the Subscriber will use one of the following options to generate and protect their Code Signing Certificate Private Keys in a Hardware Crypto Module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+”
When the Official Change Will Take Place
The change will occur on Tuesday, Nov. 15, 2022 at 12 a.m. Coordinated Universal Time (UTC) — that’s Monday, Nov. 14, 2022 at 7 p.m. Eastern Standard Time (EST) for our U.S. readers. However, it’s important to note that some certificate authorities (such as DigiCert, Sectigo, etc.) may choose to implement the change ahead of schedule to ensure that there’s time to address any issues before the CA/B Forum’s official deadline!
Again, we’ll share more specifics once the CAs finalize their plans.
Who Will Be Impacted By These Changes
This industry-wide mandate will affect anyone who purchases new OV code signing certificates on or after the November rollout. (This also may impact current OV code signing certificate holders who reissue or renew their existing certificates as well.) What about if you’re an individual developer who has an IV code signing certificate? Yes, this change will impact you as well.
However, it’s important to note that this change won’t impact you in the same way if you have an existing valid code signing certificate issued before the official change. Of course, the CA will have to recommend that you store your keys in one of the same methods. But you can still continue signing your software and other executables as you always have.
Existing certificate holders prior to the November date will have to affirm to their CA that they will use a secure method — trusted platform module, hardware crypto module, or a hardware security token) to generate and protect their keys. After the November rollout, certificate holders must affirm that they’ll use one of the following to securely store their keys:
- An HSM or hardware security token
- A cloud-based key generation and protection solution
- A signing service that meets the requirements outlined in the CA/B Forum’s Baseline Requirements section 16.2
Why Securing Your Code Signing Certificate and Key Matters
Code signing is a way for you or your organization to assert your organization’s digital identity for your code, software, or other executables. It’s the difference between seeing “Your Company, Inc.” in the Windows User Account Control popup field versus “Publisher: Unknown” warning messages. No one wants the latter to display when they try to download or install your software.
Having those ugly warnings display isn’t a good look if you want people to trust that your software is authentic and bad guys haven’t messed with it. Not using one is like putting up a flashing neon sign that says “I’m not trustworthy” next your company name and logo. Digitally signing your software bakes your organization’s identity into your software and code in a way that users know it’s authentic and that it hasn’t been compromised since it was signed.
By not storing your key securely, you risk your certificate becoming untrusted and a liability for your organization if bad guys use it to sign and distribute malware in your name.
How Do I Order a Code Signing Certificate After Nov. 15?
This is a great question — honestly, one we’re waiting on the final details for ourselves. Each CA will have its own OV code signing certificate process. How exactly these changes will work, and what they’ll mean for you, will depend on each individual CA. For most customers, each CA will provide a streamlined order process that will likely look a lot like the current process for EV code signing certificates.
What we do know is that these changes will likely entail having to use a hardware security token that’s either issued by your CA or one that you already own that meets FIPS 140 Level 2, Common Criteria EAL 4+ compliance requirements as a minimum. Once we know more, so will you. So, stay tuned for a future follow-up article as we draw closer to the deadline.
For advanced users, you have three options for provisioning your certificates and keys:
1. USB Tokens
Hardware security tokens are typically small and convenient devices that are assigned to individual users within organizations. You can purchase these yourself, or have the certificate authority ship your code signing certificate already installed on one. For example, DigiCert currently requires the use of a specific security hardware token for storing EV code signing certificates’ private keys: SafeNet eToken 5110 CC (RSA 4096-bit key and ECC P-256-bit key). This particular device exceeds the minimum requirements outlined by the CA/B Forum — it supports FIPS 140-2 Level 3, CC EAL5+.
Another optional token you may be able to use is the SafeNet eToken 5110+ FIPS, a new token that will likely be released by Thales this summer.
Of course, each CA can choose which token(s) they’ll use. Most customers will find that using a USB token provided by the CA is the easiest and simplest option. So, we’ll go into all of that more in the future as we get closer to the rollout deadline.
2. Hardware Security Modules
If you decide to go the hardware security module route to store your private keys, then you’ll need to prove that you’re using a device that’s up to snuff. For example, you may have to provide a letter of attestation that shows the device:
- Is FIPS 140 Level 2 or Common Criteria EAL4+ (CCE 4+) compliant at a minimum, and
- Supports ECC key size of 256 bits or larger or RSA 3072 bits or larger.
With either physical security device method, you’ll need to either have to connect your systems to your organization’s hardware security module (HSM) or plug in a physical security token into your device before you can use the certificate to sign code. This allows you to access your private key for signing, which is securely stored on the device. You’ll also have to enter your unique password as well as an additional layer of security.
But there is a third option that doesn’t require you to manage and secure any physical appliances or hardware tokens…
3. Code Signing Services and Applications
Another secure key storage option you can choose to use is a signing solution like DigiCert’s Secure Software Manager (SSM), which is part of the DigiCert ONE platform. This software enables authorized users to securely store and use the private keys without requiring physical access to them. This means your employees can go about their business without you having to worry about managing a bunch of individual physical security tokens that could be damaged, lost, or stolen.
STAY TUNED: If you’re looking for more specifics about how all of these processes will work when ordering a new OV code signing certificates from The SSL Store after the November change, stay tuned. We’ll post another update as we get closer to the date when these changes will roll out.
TL;DR — A Quick Overview of the OV Code Signing Certificate Changes to Come
Alright, that was a lot of information to take in. Or, if you’re like some of our readers, you may not have bothered reading it and may have just jumped straight to this section instead. Either way is good, as long as we’re giving you the info you need! Here are the highlights you need to know:
- The CA/B Forum has issued new industry requirements for how to issue and store standard (OV) code signing certificates and private keys will roll out Nov. 15, 2022 at 12:00 a.m. UTC (Nov. 14 at 7 p.m. EST for North American users).
- These changes impact how new and reissued organizational validation (and individual validation) code signing certificates and their corresponding private keys will be created, stored, installed, renewed and reissued.
- Issuing certificate authorities will handle the certificate and key generation processes on the back end — you’ll no longer have to complete a certificate signing request (CSR) yourself to get your code signing certificate.
- Certificate requestors (i.e., you) will be contractually required to use FIPS 140 Level 2/EAL 4+ compliant secure hardware cryptographic modules or signing services as a minimum to store code signing certificates and private keys.
