Create a CSR for Code Signing in Azure Key Vault Premium

This page is for the person who creates the CSR. It covers exactly what needs to happen in Azure Key Vault, from generating the key to having the finished certificate merged and ready to use. Applies to both DigiCert and GlobalSign, OV and EV.

If you also need to set up signing with AzureSignTool, service principals and CI/CD, that is covered in the full Azure Key Vault setup guide.

Read this first: it must be a Premium Key Vault

The most common mistake is creating a Key Vault on the Standard pricing tier. A Standard Key Vault cannot create HSM-protected keys. The RSA-HSM option is simply missing, and you end up selecting plain RSA instead. The private key then sits in software, the certificate cannot be issued, and the whole setup has to be redone.

The pricing tier cannot be changed in the Azure portal. A Standard vault can only be upgraded to Premium from the command line, and a key already created as a software key does not become HSM-protected by an upgrade. Check the pricing tier before you create the certificate. See step 1.

In short

✓
The Key Vault must be Premium. A Standard Key Vault cannot create RSA-HSM keys
✓
You need Key Vault Administrator on the vault itself, not just on the subscription
✓
The key must be 4096 bit RSA-HSM and must not be exportable
✓
A technically responsible person must sign an HSM declaration for the CA
✓
The timing of when the CSR is submitted differs between DigiCert and GlobalSign

The order differs between DigiCert and GlobalSign

The Azure setup itself is the same regardless of CA. But the point at which the CSR is used is different. Read the section that matches your order.

DigiCert: the CSR must be ready first

Create the key and CSR in Key Vault. See steps 1 to 3 below
Submit the CSR, see step 4. The order cannot be created with DigiCert without a CSR
Organisation validation starts and the HSM declaration is signed
Once validation is approved, the certificate is issued and sent to you
Merge the certificate in Key Vault. See step 5

GlobalSign: validation first, CSR afterwards

The order is created without a CSR
You receive documents to sign and date, and the HSM declaration is signed
The approver is called on the company main number, or contacted at the company's registered email address, and must confirm that the company ordered the certificate
Once validation is approved, GlobalSign sends an issuance link to the approver's email, along with a one-time code
Only then is the CSR used. Create the key and CSR in Key Vault, see steps 1 to 3, and submit the CSR through the link, see step 4
The certificate is issued immediately. Merge it in Key Vault, see step 5

A direct number can only be used if it is given out via the main number. If the approver is only available at certain hours, or a specific extension has to be dialled, let us know and we will pass it on.

Do not delete the pending certificate in Key Vault while you wait. The issued certificate can only be merged into the exact pending request the CSR came from. If you recreate the certificate you get a new key, and the issued certificate cannot be used.

Step 1: Confirm the Key Vault is Premium

Open the Key Vault resource in the Azure portal and check under Overview that the pricing tier is Premium. A Standard Key Vault can only create software-protected keys, and the RSA-HSM option will be missing in step 3.

If a new vault is needed, create it from the portal or with the Azure CLI:

az keyvault create \
  --name your-codesign-vault \
  --resource-group your-resource-group \
  --location westeurope \
  --sku premium \
  --enable-purge-protection true

If you already have a Standard Key Vault, the tier can be upgraded to Premium from the command line. This cannot be done in the Azure portal:

az keyvault update \
  --name your-codesign-vault \
  --resource-group your-resource-group \
  --set properties.sku.name=premium

Keys already created as software keys do not become HSM-protected by an upgrade.

Step 2: Make sure you have the right permissions

Azure Key Vault uses a separate permission model for certificates and keys. Being Owner or Contributor on the subscription does not grant access to create certificates inside the vault. The permission often has to be added specifically, on top of the administrator rights you already have.

With RBAC as the permission model

Assign the Key Vault Administrator role on the Key Vault resource: Key Vault → Access control (IAM) → Add role assignment → Key Vault Administrator → select your user. Role assignments can take up to 10 minutes to take effect.

With access policies as the permission model

Add an access policy for your user with the certificate permissions Get, List, Create, Update and Import, plus the key permissions Get, List and Create.

Step 3: Create the certificate and download the CSR

Go to Key Vault → Certificates → Generate/Import.

Create a certificate

Method of Certificate Creation: Generate
Certificate Name: your internal name, for example codesign-2026
Type of Certificate Authority (CA): Certificate issued by a non-integrated CA
Subject: CN=Your full registered company name, no abbreviations, identical to the name validation is completed against
DNS Names: none
Validity Period (in months): 12
Content Type: PEM

Validity: choose 12 months. FairSSL issues Code Signing certificates with 1 year validity. If you bought coverage for several years, the later years are renewals of the existing certificate, not one long certificate. The industry cap is 460 days, roughly 15 months (DigiCert issues 459), but that is an upper limit and not what gets issued to you.

Advanced Policy Configuration

The field shows Not configured. Click it and fill in:

Extended Key Usages (EKUs): 1.3.6.1.5.5.7.3.3 (Code Signing). Remove the EKUs already listed
X.509 Key Usage Flags: leave unchanged
Reuse Key on Renewal: Yes
Exportable Private Key: No
Key Type: RSA-HSM
Key Size: 4096
Enable Certificate Transparency: No (Yes is allowed but not needed)
Certificate Type: leave empty. The field is only used with an integrated CA

Advanced Policy Configuration in Azure Key Vault with EKU 1.3.6.1.5.5.7.3.3, Reuse Key on Renewal Yes, Exportable Private Key No, Key Type RSA-HSM and Key Size 4096 — Advanced Policy Configuration with the settings that must be used.

RSA-HSM missing as an option? Then the vault is not Premium. Go back to step 1. Do not create the certificate with plain RSA, because then the private key is not in an HSM and the certificate cannot be issued.

Download the CSR

Click Create. The certificate appears in the list with status "In progress". Click the certificate, choose Certificate Operation and click Download CSR.

The private key stays inside the HSM and never leaves it. The CSR file contains only the public key and the name, so it can safely be sent by email.

Step 4: Submit the CSR

Open the CSR file in a text editor. The content starts with -----BEGIN CERTIFICATE REQUEST----- and ends with -----END CERTIFICATE REQUEST-----. The whole block, including both lines, is what the CA needs.

DigiCert order

Paste the PEM text into the order, or send the file to us at info@fairssl.dk and we will submit it to DigiCert. The order cannot be created without the CSR.

GlobalSign order

Use the issuance link from GlobalSign, sent to the approver's email once validation is complete. Paste the CSR there together with the one-time code. The certificate is issued immediately afterwards.

The HSM declaration

Before the certificate is issued, you must confirm by signature that it will be installed in hardware protection, in this case an Azure Key Vault Premium with an RSA-HSM key, and that the key cannot be exported. The declaration must be completed and signed by someone who can technically vouch for it, normally the person who creates the CSR and installs the certificate.

Once the certificate is issued you normally receive either a single .p7b file or several separate files: your Code Signing certificate, an intermediate certificate and a root certificate.

Step 5: Merge the issued certificate

Upload the whole chain. It can only be done once

The most common mistake in the whole process is uploading your own certificate on its own, without the intermediate certificates. It cannot be corrected afterwards. Merge Signed Request can only be run once on a pending request.

If it happens, every signing from then on has to be done with extra parameters pointing at the intermediate certificate. And if you delete the certificate to upload it again with the full chain, the private key is deleted along with it. The whole process then starts over: new key, new CSR and a new issuance from the CA.

So check the file before uploading. It must contain your own certificate and the intermediate certificate, yours first.

Go back to Key Vault → Certificates → click the certificate with status "In progress" → Certificate Operation → Merge Signed Request. Select the certificate file and upload.

Which file to use

Use a single .p7b file, or a combined .pem text file containing all the certificates, starting with your Code Signing certificate.

-----BEGIN CERTIFICATE-----
(your Code Signing certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(root certificate)
-----END CERTIFICATE-----

From the command line the file can be assembled with cat codesign.pem intermediate.pem root.pem > fullchain.pem.

Azure CLI alternative

az keyvault certificate pending merge \
  --vault-name your-codesign-vault \
  --name codesign-2026 \
  --file fullchain.pem

On success the certificate status changes to Completed and it is ready to use. The certificate name, for example codesign-2026, is what the signing tool points at.

Common problems

RSA-HSM cannot be selected

The Key Vault is not Premium. Upgrade the vault with the Azure CLI, or create a new one with the Premium SKU.

"The user, group or application does not have certificates create permission"

You are missing permissions on the vault itself, see step 2. Permissions on the subscription do not count. On an RBAC vault this is the Key Vault Administrator role, and role assignments can take up to 10 minutes to propagate. On a vault using access policies it is the access policy that is missing.

The CA rejects the CSR

Usually because Subject CN is not identical to the legal name validation was completed against, or because the key is not 4096 bit RSA. Create a new certificate under a different name with the correct fields and submit the new CSR. Leave the incorrect certificate in place, see the FAQ below for why it should not be deleted.

Merge Signed Request fails

Either the certificate does not match the pending request, or the chain is incomplete. Check that the certificate was issued against the exact CSR Key Vault generated, that the pending certificate was not deleted or recreated in the meantime, and that the file contains both your certificate and the intermediate, yours first.

The certificate still shows "In progress"

The issued certificate has not been merged yet. This does not happen automatically with a non-integrated CA. Go to Certificate Operation and Merge Signed Request.

Once the certificate is ready

Always use timestamping

With an RFC 3161 timestamp the signature keeps validating after the certificate expires. Without a timestamp the signature only holds while the certificate is valid. With signtool it is set with /tr.

http://timestamp.digicert.com
http://timestamp.globalsign.com/tsa/r6advanced1

If only one can be selected we recommend DigiCert's, as it has historically been the most stable. See DigiCert's guide to timestamping problems ↗.

Signing tools

AzureSignTool ↗ for Microsoft-related code. Signs directly against Key Vault. See the Walkthrough link on the GitHub page for how to set up access to the certificate.
Jsign ↗ if advanced file types or Java-based code need signing, or it is used as a bridge to jarsigner.

Concrete commands, service principal setup and CI/CD examples are in the full Azure Key Vault setup guide.

Extra backwards compatibility

If signatures also need to validate on older systems, import the CA certificate "GlobalSign Code Signing Root R45 (R3 cross)". It is available from GlobalSign's intermediate certificate overview ↗.

The CAs' own guides

Note that the fields on this page take precedence over the CAs' general guides, which do not always match what the Azure portal shows today.

Get in touch if you have questions

Email info@fairssl.dk or call +45 77 34 56 78. Describe in detail which command or which screen it concerns, so we can answer precisely the first time.

Frequently asked questions about CSRs in Azure Key Vault

Find answers to the most common questions about SSL certificates and FairSSL.

Do I create the CSR before or after the order?

It depends on the CA. With DigiCert the CSR must be ready before the order can be created, because the CSR is submitted as part of the order. With GlobalSign the organisation validation is completed first, and the CSR is submitted afterwards through the issuance link GlobalSign sends once validation is approved. If you are unsure which CA your order sits with, ask us.

RSA-HSM is missing as an option. What is wrong?

Your Key Vault is not Premium. Only the Premium pricing tier supports HSM-protected keys. The tier cannot be changed in the portal, but a Standard vault can be upgraded to Premium through the Azure CLI. Alternatively, create a new Key Vault with the Premium SKU.

Which Validity Period should I choose?

Choose 12 months. FairSSL issues Code Signing certificates with 1 year validity. If you buy coverage for several years, the later years are renewals of the existing certificate, not one long certificate. The industry cap is 460 days, roughly 15 months, but that is an upper limit and not what gets issued to you. The field in Azure only controls Key Vault policy, not the validity the CA issues.

What exactly goes in Subject?

Only CN with the full legal company name, written exactly as it is registered, without abbreviations. The name must be identical to the one the organisation validation is completed against. If it differs, the CSR is rejected. O, OU, L and C are not required, the CA fills in the rest from the validation.

Why must Exportable Private Key be set to No?

The whole point of an HSM-protected Code Signing certificate is that the private key can never leave the hardware protection. That is also what you confirm by signature in the HSM declaration to the CA. With Yes the key could be exported and the certificate would not meet the requirements.

I already created the certificate with the wrong fields. Can I fix it?

No, a pending request cannot be edited. Create a new certificate under a different name instead, for example codesign-2026b, and use the new CSR. Do not delete the incorrect certificate: Key Vault has soft delete, so the name stays taken for the retention period, and with purge protection enabled it cannot be released before that period expires. The incorrect certificate does no harm where it sits. If you already submitted a CSR to the CA, let us know so we can have the order reissued against the new CSR.

Can I reuse the key on renewal?

Yes, if Reuse Key on Renewal is set to Yes. You can then choose New Version on the certificate later and get a new CSR on the same HSM key pair. The certificate name stays the same, so your signing configuration does not need changing.

Need a Code Signing certificate?

Create a free account and issue your first certificate in under 10 minutes.

Create free account Compare certificates