How to Generate a CSR for a Code Signing Certificate

A code signing certificate proves who published a piece of software and shows that the code has not been changed since it was signed. To order one, you create a CSR (Certificate Signing Request), the block of encoded text the Certificate Authority (CA) uses to identify you and issue the certificate. Code signing CSRs follow different rules from the CSRs you create for a website, and those rules changed in 2023. This guide explains the current process and the methods that still apply.

The private key must live on hardware

Since June 1, 2023, the CA/Browser Forum Code Signing Baseline Requirements have required the private key for every publicly trusted code signing certificate to be generated and stored on hardware that meets FIPS 140-2 Level 2, Common Criteria EAL4+, or an equivalent standard. This applies to both standard certificates (Organization Validation and Individual Validation) and Extended Validation (EV) certificates. EV code signing already required hardware before this date; the 2023 change extended the same rule to standard certificates.

The practical consequence is important: a private key and CSR generated purely in software, in a browser, or in a regular file on a laptop or server, is no longer accepted for a publicly trusted code signing certificate. CAs have stopped supporting browser-based key generation and downloadable .pfx delivery for these products. The key has to originate on, and stay on, a compliant device. That leaves two valid routes:

• A pre-configured hardware token from the CA. The CA generates the key pair and the CSR directly on a certified USB token, installs the issued certificate on it, and ships the token to you. You sign with the token plugged in. With this method you do not generate the CSR yourself.
• Your own HSM or cloud HSM, with key attestation. If you already run a compliant Hardware Security Module (or a cloud HSM such as AWS CloudHSM, Azure Dedicated HSM, or Google Cloud HSM), you generate the key and CSR on that device and provide an attestation file that proves to the CA the key was created on, and cannot be exported from, compliant hardware.

Which route you take is set when you order. For a side-by-side comparison, see the code signing certificate delivery methods.

Option 1: token plus shipment (the CA creates the CSR)

This is the route most individuals and small teams choose, because it needs no hardware of your own. When you select token plus shipment at checkout, the CA handles key generation and CSR creation on a certified token on its side, then mails you the token with the certificate already loaded. There is no CSR for you to paste into an order form.

What you do instead:

• Complete the validation steps the CA asks for (organization or identity verification).
• Wait for the physical token to arrive.
• Install the token drivers (commonly SafeNet Authentication Client) and sign your software with the token connected.

Option 2: generate the CSR on your own HSM or token

If you already own compliant hardware, you generate the key pair and the CSR on that device and supply a matching attestation. The exact steps depend on the hardware, so follow the guide for your device or your provider’s own documentation:

• YubiKey 5 FIPS: CSR generation and attestation
• Luna Network Attached HSM v7.x: CSR and attestation guide

For cloud HSMs (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM), generate the key inside the HSM, export the CSR and the attestation file the platform produces, and submit both to your CA during the order.

A few details apply across hardware-backed CSRs:

• Use an RSA key of at least 3072 bits, or an equivalent ECDSA key, as the Baseline Requirements specify.
• Mark the key as non-exportable so it cannot leave the device.
• Generate the attestation at the same time as the key. A CSR without valid attestation will be rejected.

Where the OpenSSL, Java Keytool, MMC, CertReq, and Keychain methods fit now

You may have seen older instructions that create a code signing CSR with OpenSSL, the Java keytool utility, Microsoft Management Console (MMC), the Windows certreq command, or Keychain Access on macOS. On their own, these tools generate a key in software, so a CSR produced that way is not valid for a publicly trusted code signing certificate today.

They still have a place when you point them at compliant hardware rather than a software keystore. For example, OpenSSL can create a CSR against an HSM through a PKCS#11 module, and CertReq or MMC can build a request that uses a hardware key storage provider. Use these references only in that context, and always pair the request with attestation from the device:

• Generate a code signing CSR with OpenSSL
• Generate a code signing CSR with Java Keystore
• Generate a code signing CSR with CertReq
• Generate a code signing CSR with Microsoft Management Console
• Generate a code signing CSR with macOS Keychain Access

Check the contents of your CSR

Before you submit a CSR, confirm that the subject details are correct. If you have OpenSSL available, decode the request locally and read it back in plain text:

openssl req -noout -text -in codesigning.csr

Review the organization or common name and the key size in the output. A standard website CSR checker is not the right tool here, because a code signing CSR is tied to hardware and is validated through attestation rather than a public HTTPS scan.

Frequently Asked Questions