How to Generate a CSR for a Code Signing Certificate via MMC

The Certificates snap-in in Microsoft Management Console (MMC) can build a PKCS #10 certificate request on a Windows machine without any extra software. This guide covers that wizard screen by screen for a code signing certificate, and it starts with the part most older instructions leave out: the rules for code signing private keys changed on June 1, 2023, and they decide whether an MMC request is usable at all.

Read that requirement before you open the wizard. The rest of the guide assumes you know which route your order takes.

Code signing keys must be generated on hardware

Under the CA/Browser Forum Code Signing Baseline Requirements, effective June 1, 2023, the private key for every publicly trusted code signing certificate must be generated, stored and used in a hardware crypto module certified to at least FIPS 140-2 Level 2, Common Criteria EAL 4+, or an equivalent standard. This covers both standard certificates (Organization Validation and Individual Validation) and Extended Validation. EV code signing already worked this way; the 2023 change extended the same rule to the standard products.

The requirements also fix the key itself. RSA keys must be at least 3072 bits, ECDSA keys must use NIST P-256, P-384 or P-521, and SHA-1 is not permitted for code signing certificates.

Just as important, the Certificate Authority has to prove the key really is in hardware, using one of the methods the requirements list. In practice these are the ones you will meet:

• The CA ships you a hardware token that already holds a key pair the CA generated on that device.
• You counter-sign the request with a manufacturer’s certificate, which is what key attestation means: proof that the key was created in a non-exportable way inside a compliant device.
• You use a crypto library and hardware module combination that the CA prescribes.
• You supply an IT audit, a report from a cloud key protection service, or an agreement that you sign through a compliant signing service.

None of those are satisfied by a request that MMC builds against the Microsoft Software Key Storage Provider. That provider creates the key in Windows software storage, so the resulting request will be rejected for a publicly trusted code signing certificate no matter how the rest of the wizard is filled in. Certificate Authorities also stopped offering browser-based key generation and downloadable .pfx delivery for these products at the same time.

If your goal is a publicly trusted certificate, the route is decided when you order. Either the CA generates the key on a token and mails it to you, in which case there is no CSR for you to create, or you generate the key on hardware you already own and submit an attestation with the request. The code signing certificate delivery methods guide compares the two, and the device-specific steps are here:

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

Where MMC still fits

The wizard is not obsolete. It is the provider you choose inside it that decides where the key is born, and there are three situations where it remains the right tool.

A request backed by a hardware provider. The Cryptographic Service Provider list in the wizard shows every provider installed on the machine, not just Microsoft’s software ones. Once a token’s driver or smart card minidriver is installed, its provider appears there too. The difference is where the key pair is born: a software provider generates it on your computer, while a hardware-based provider, such as a smart card or token provider, instructs the device to generate the pair, and the device then holds the private key and controls access to it. Select a hardware provider and MMC produces a request for a key that never existed in software.

Two caveats before you rely on that. MMC produces a PKCS #10 request and nothing else, so it does not generate the key attestation file that most Certificate Authorities want alongside it. That comes from the device’s own tooling. And the CA decides which verification method it will accept, with many prescribing their own utility for the job. Ask your CA which route it supports before you generate anything, because a key you create with the wrong tool cannot be moved afterwards.

An internal or enterprise CA. The Baseline Requirements govern publicly trusted certificates. A certificate issued by your own Active Directory Certificate Services CA for internal signing is outside that scope, so your own policy decides how the key is stored and a software provider is a legitimate choice. Remember what you get: code signed this way is trusted only on machines that already trust your internal root, and everywhere else Windows still treats the publisher as unknown.

Test signing and preparation. A software request is fine for a test certificate, and for working out the exact subject values you will reuse when you generate the real request against your hardware.

Step 1: Open the Certificates snap-in

Press the Windows key + R, type mmc and press Enter. You can also type mmc into the taskbar search box and open it from there. Accept the User Account Control prompt. An empty Console1 window opens.

Click File, then Add/Remove Snap-in. In the Available snap-ins list select Certificates and click Add.

Windows now asks which certificate store the snap-in should manage: My user account, Service account or Computer account. This choice matters more for a code signing certificate than for a web server certificate, because it decides where the key lives and which store your signing tool looks in:

• My user account puts the key in the personal store of the signed-in user. This is the usual choice when a developer signs interactively, because Microsoft’s signtool opens the My store of the current user by default.
• Computer account puts the key in the machine store, which suits a build server where signing runs under a service account. Signing tools need to be told to look there: signtool takes the /sm switch for the machine store.

If you choose My user account, click Finish. If you choose Computer account, click Next, leave Local computer (the computer this console is running on) selected and click Finish. Either way, click OK to close the Add or Remove Snap-ins window.

Two shortcuts skip the snap-in step entirely when you do not need a saved console: certmgr.msc opens the current user’s certificate stores directly, and certlm.msc opens the local computer stores. If you built the console by hand and expect to come back, use File then Save to keep it.

Step 2: Start a custom request

In the console tree, expand Certificates and right-click the Personal folder (or the Certificates folder beneath it, if the store already holds certificates). Choose All Tasks, then Advanced Operations, then Create Custom Request. The same commands sit on the Action menu if you prefer it.

The Certificate Enrollment wizard opens on Before You Begin. Click Next.

On Select Certificate Enrollment Policy, look under the Custom Request heading and select Proceed without enrollment policy, then click Next. That tells Windows to build a standalone request for an external CA instead of enrolling against an Active Directory template.

The Custom request page has three settings:

• Template. Choose (No template) CNG key. This uses a Key Storage Provider, which is what modern hardware providers register as. (No template) Legacy key uses the older CryptoAPI providers and is only needed when a specific device or application requires one.
• Suppress default extensions. Leave it clear unless you intend to send only the extensions you set by hand.
• Request format. Select PKCS #10. Every CA accepts it. CMC is for requests aimed at systems that specifically ask for it.

Click Next. On the Certificate Information page you will see a single row labelled Custom request with a status of Available. Click the Details arrow on the right of that row to expand it, then click the Properties button that appears. The Certificate Properties dialog opens with four tabs: General, Subject, Extensions and Private Key.

Step 3: Enter the subject details

On the General tab, type a Friendly name and, if you want, a Description. Both are local labels that help you find the certificate in the store later. Neither is part of the request, and neither is validated.

Switch to the Subject tab. This is where the identity that will appear as the software publisher is assembled. Under Subject name, pick an entry from the Type drop-down, type the matching text in the Value box, and click Add >. Each entry moves to the list on the right, where Windows shows it in short form (CN=, O=, OU=, L=, S=, C=). Repeat for each of the following:

• Common name (CN): the registered name of your organization, or the individual’s full legal name for an individual certificate. This is the identity users see when Windows names the publisher.
• Organization (O): the registered organization name the certificate belongs to. If the name contains a symbol such as an ampersand, spell it out or drop it, since these characters are not accepted in the field. “AB & C Corporation” becomes “AB and C Corporation” or “ABC Corporation”.
• Organizational unit (OU): the department handling the enrollment, for example IT. Optional.
• Locality (L): the city where the organization is registered.
• State (S): the state or province, written out in full. Use Florida, not FL.
• Country (C): the two-letter ISO country code of the place where the organization is registered, for example US.

Enter details that match your legal records exactly, because the CA validates them against public and official sources before it issues anything. A mismatch is the most common reason a code signing order stalls.

Leave the Alternative name box empty. Subject Alternative Names identify servers by host name, and a code signing certificate identifies a publisher rather than a machine, so it carries no DNS entries.

Step 4: Choose the provider, key size and hash

Open the Private Key tab. It holds several collapsible groups: Cryptographic Service Provider, Key options, Select Hash Algorithm, Select Signature Format and Key permissions. Click a heading to expand it.

Expand Cryptographic Service Provider first, because this is the setting the Baseline Requirements turn on. The list shows every provider installed on the machine, each with a check box. Make sure the only one ticked is the provider you actually want:

• For a publicly trusted code signing certificate, select the provider that belongs to your token or HSM. It appears in this list only after the device’s driver or minidriver is installed, so plug the device in and install its software first.
• RSA, Microsoft Software Key Storage Provider is the software option. Use it only for an internal CA or a test certificate.
• The list also carries ECDSA entries such as ECDSA_P256, Microsoft Software Key Storage Provider. Confirm that your CA supports ECDSA for code signing before choosing one, because not every product does.

Expand Key options. Set Key size to 3072 or 4096. RSA 3072 is the floor for code signing, and a request built with 2048 will be refused. If the drop-down does not offer 3072 for the provider you picked, use 4096.

In the same group, leave Make private key exportable unchecked. This is the single most important correction to older MMC instructions. An exportable key can be copied off the machine as a .pfx file, which is exactly what the hardware requirement exists to prevent, and the attestation route explicitly certifies that the key was created in a non-exportable way. The only case for checking it is an internal signing setup where you must move the certificate and key to another machine, and even then it weakens the key. Leave Allow private key to be archived unchecked as well. Strong private key protection is optional and makes Windows prompt every time the key is used, which is reasonable for a signing key on a shared workstation.

Expand Select Hash Algorithm and set Hash Algorithm to sha256. SHA-1 is not allowed for code signing certificates.

The Extensions tab is worth a look if you are enrolling against an internal CA. Expand Key usage and add Digital signature, then expand Extended Key Usage (application policies) and add Code Signing. A public CA builds the certificate from the product you ordered rather than from the extensions in your request, so for a public order this tab changes nothing. An internal CA may honour it.

Click OK to close Certificate Properties, then Next.

Step 5: Save the request

The wizard asks Where do you want to save the offline request? Click Browse, pick a folder you control, give the file a name such as codesigning.req and confirm. Always browse to a folder rather than typing a bare file name: without a path the request lands in whatever folder the console happens to be running from, which is rarely where you want it and awkward to find again.

Under File format, leave Base 64 selected. That is the text form CAs paste into an enrollment box. Binary writes raw DER, which most order forms reject. Click Finish.

Open the file in any plain-text editor, such as Notepad, and copy the whole block including the first and last lines:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Windows enrollment tools normally write the longer wording shown above, with the word NEW in the marker lines, while OpenSSL writes BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST. If your file uses the shorter form, nothing is wrong: the contents are the same PKCS #10 request and Certificate Authorities accept either. Copy exactly what you see and do not rewrite the marker lines.

One thing the wizard does not produce is a private key file you can save or copy, and older guides that tell you to keep the public and private key files safe are describing a different tool. MMC keeps the new private key inside the Windows key store, under the account you selected in step 1, on that computer only. The pending request normally shows up in the snap-in under Certificate Enrollment Requests. Three consequences follow:

• Do not delete the pending request while you wait for issuance. Deleting it discards the key, and the issued certificate will then be useless.
• Complete the order on the same computer, in the same account context. A request generated in the user store cannot be finished in the machine store, or the other way round.
• Do not rebuild or re-image the machine between generating the request and installing the certificate.

Step 6: Check the request before you submit it

A request cannot be edited after it is created, so check it now rather than discovering a typo after validation starts. Windows can read it back without any extra software. Open a Command Prompt in the folder holding the file and run:

certutil -dump codesigning.req

If OpenSSL is installed, this reads the same file and also checks the request signature:

openssl req -noout -text -verify -in codesigning.req

Confirm four things in the output: the subject lists the country, state, locality, organization and common name exactly as you intend; the public key is 3072 bits or more, or an approved ECDSA curve; the signature algorithm is SHA-256; and, with the OpenSSL command, that a verify OK line appears, which confirms the request was signed by its matching private key. You can also paste the block into the CSR decoder to read it in a browser.

If anything is wrong, generate a new request from step 2. To see which providers are available on the machine, including any hardware ones you have installed, run:

certutil -csplist

Step 7: Install the issued certificate on the same machine

Submit the Base 64 block during your certificate order, complete the validation the CA asks for, and download the issued certificate when it arrives. Because the private key stayed in the Windows key store, the certificate has to come back to the same store to be usable.

In the same snap-in, right-click Personal, choose All Tasks, then Import, and point the wizard at the file. Windows matches the certificate to the key it kept from the request, and the pending entry under Certificate Enrollment Requests disappears. Open the certificate afterwards and check that the General tab says you have a private key that corresponds to this certificate. If that line is missing, the pairing did not happen, and you can re-link it with the serial number of the certificate:

certutil -repairstore My <serial-number>

Add the -user switch if the certificate belongs to the current user rather than the machine:

certutil -user -repairstore My <serial-number>

From there your signing tool picks the certificate out of the store. Remember the store you chose in step 1: signtool reads the current user’s My store unless you pass /sm for the machine store.

Other ways to create the same request are covered in the CertReq, OpenSSL, Java Keystore and macOS Keychain Access guides. You may also want the wider code signing tutorials or other ways to generate a CSR.

Frequently Asked Questions