CA/Browser Forum Code Signing Certificate Requirements: what is it and what to do about it?

As long as computers exist, they needed programming code to run. Almost as long as code is running, people have been trying to change the code in one malicious way or another. One of the requirements when it comes to ensuring the trustworthiness of code in businesses is knowing it came from your developers, and that it was not changed by anybody else.

The solution to this question is to sign the code. As is common security, the key to sign the code is then protected with a certificate to vouch for its validity, a code signing certificate.

Example of signed code

The new CA/Browser Forum Requirements

A key standards body when it comes to public certificates is the CA/Browser forum, which consists of over 50 of the Public CA and over 10 Consumer members, the latter including among others the four leading Browser suppliers: Apple, Google, Microsoft and Mozilla. This forum produces requirements for certificates as well as public CAs and sometimes validation of certificates that have a global adoption.

On October 28th, 2022, the forum produced an amendment to their Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates. The most important elements in this addition are the following:

1. All code signing certificates delivered by a public CA must have their keys stored in hardware (HSM) that is compliant with FIPS 140-2 Level 2, Common Criteria EAL4+, or an equivalent. This can be done either by technically validating that the private key is generated and stored on the HSM (key attestation), the subscriber (customer) providing an audit report that proves to the CA this was done, or by generating the private key on an HSM themselves and then physically shipping it to the subscriber.
2. If the CA becomes aware that the subscriber was the victim of a take over attack, then the CA must re-establish that the private key is still safe.

Note that this applies to public certificates issued after June 1st, 2023. Also it does not impact certificates issued by a private PKI.

CA/Browser Forum Requirements do not have the status of law. However, public CAs are bound not to supply certificates that do not comply, or revoke certificates that no longer apply. Also, the four main browser suppliers as well as several other major IT infrastructure suppliers will consider noncompliant public certificates invalid. So this will have an impact.

What does this mean for my organization?

The first question for an organization is if you’re using a certificate from a private PKI or a Public one. There can be two reasons for having a public certificate:

1. A private PKI is only trusted where you explicitly set it up to be trusted. Most of the time that’s your own organization and perhaps some suppliers and/or customers. If you want a certificate trusted by a far wider base of relying parties, you’ll most likely need a public certificate.
2. Setting up and running a private PKI is an expensive business. In case of low numbers of certificates, it may be cheaper for an organization to buy public certificates even if they don’t really need the public trust.

If either is the case, then this affects you in the future. But it might not be right away. If you got your certificate delivered before June 1st (or sooner, depending on whether your public CA is applying this ahead of time), the new requirements might not yet apply to you. Since public code signing certificates can be valid up to three years, it might be 2026 before you’re really impacted.

When you are impacted, the physical cost of the hardware device can be relatively low. There are a few compliant devices that are the size of a USB thumb drive, and cost just under €100.

More important are the implications for the lead time. Key Attestation requires technical communication between the HSM and the CA, which means opening up communications. It is quickest form though. Having the device sent by the CA will take longer and submitting to an audit still longer than that.

It also means that the CA has influence on your internal practices. They can and must withhold you the certificate you need for your operations, therefore they can enforce this good practice. This is likely to spread further in the future.

A helpful response could be to centralize your code signing operations. IT has a tradition where each team facilitates their own resources, including the signing of code, in many organizations. The hassle this brings may mean the teams find it easier to form a collaboration where they share a single key for signing their code instead. An important factor is to make this central signing service the easiest and most convenient way to have code signed in the organization, if it’s hassle free and well-known, it will be used.

Finally and most importantly this means the code signing teams need to be crypto and certificate aware. This is a known challenge in some organizations, where it is assumed that all things crypto and certificate related are for the Crypto/PKI team. With requirements such as this one, an organization cannot afford that position, if a team wants to leverage a key or a certificate, they have to radically accept the ownership, with all the responsibility that this brings (though they can get some advice and/or support from a crypto team depending on the means available).

Conclusion

The CA/B Forum requirements for Code Signing certificates are but one step on the road they’re taking to maturity of public certificates. They also form good practices that could be followed by an internal PKI. The increasing maturity calls for more crypto and certificate awareness in teams that want to leverage certificates. It also means longer lead times, making the process of issuing and replacing certificates a more deliberate and planned approach and calling for a shift-left in certificate management. But the rewards of the diligence are safer and more trustworthy code that helps cement the organizations’ reputation and helps on the safety of the customers.