Installazione del certificato YubiKey 5 FIPS HSM Code Signing

Your Certificate Authority has finished validation and sent you the issued code signing certificate. The private key never left your YubiKey 5 FIPS, and it never will. What is left is a small but easy to get wrong step: writing that certificate into the same PIV slot that holds the key which signed your Certificate Signing Request.

This guide covers both current ways to do that, the ykman command line tool and the Yubico Authenticator desktop app, then shows how to confirm the certificate landed correctly before you try to sign anything with it.

Before you start

This page picks up after the CSR. If you have not generated the key pair and the request on the YubiKey yet, do that first: see how to generate a CSR on a YubiKey 5 FIPS. Nothing here creates a key, and importing a certificate into a slot that has no matching key produces a device that looks configured and cannot sign.

You need three things in front of you:

• The issued certificate file from your CA. Sectigo normally delivers a .crt or .cer file, sometimes inside a zip with the chain alongside it.
• The PIV management key for the YubiKey. This is the credential the import operation actually requires, not the PIN. Keep the PIN to hand as well, because the optional key-matching check in Step 4 does ask for it.
• The YubiKey 5 FIPS itself, plugged directly into the computer. Avoid unpowered hubs and pass-through keyboards for this step.

YubiKey Manager (GUI) is gone, so pick one of the two current tools

Older YubiKey code signing walkthroughs, including the earlier version of this page, drive a program called YubiKey Manager (GUI). Yubico announced its End of Life on February 19, 2025 and it reached End of Life on February 19, 2026. Yubico’s current installation guide goes further than deprecating it: it tells anyone who still has it installed to uninstall it and install the latest ykman CLI instead. If a set of instructions tells you to open a window with an Applications section and a PIV tile, those instructions are describing that dead application.

Two supported tools do this job today, and for certificate import either one works:

• ykman, the YubiKey Manager command line tool. Explicitly unaffected by the GUI’s End of Life and still actively released. Download the installer from Yubico’s yubikey-manager releases page. On Windows use the .win64.msi package, on macOS run brew install ykman, and on Linux install the .tar.gz package or use pip install --user yubikey-manager. Watch the filename: an installer with -qt in the name is the old GUI, not the CLI.
• Yubico Authenticator for Desktop, which is what Yubico recommends as the replacement for the GUI. Its Certificates screen imports certificates into PIV slots.

You do not need administrator rights to run ykman. Elevation is only needed to install the package. On Windows, an elevated PowerShell window opens in the system directory, so a relative filename passed to a command lands somewhere you did not expect. Open a normal terminal and change into the folder holding the certificate file.

Confirm the tool is installed and reachable:

ykman --version

Which slot the certificate goes into, and why it matters

A PIV slot on a YubiKey stores two things that are written separately: a private key, and a certificate. Nothing in the standard forces them to correspond. You can import any certificate into any slot, and the YubiKey will accept it without complaint, because from the device’s point of view you are just storing a data object.

That is the failure mode this page’s predecessor never warned about. Import your code signing certificate into the wrong slot and everything looks fine. The import reports success. The certificate shows up. Then signing fails, or worse, you produce a signature that nobody can verify, because the public key inside the certificate does not belong to the private key that computed the signature.

So the rule is simple and absolute: the certificate must go into the same slot whose key pair generated the CSR. The four main PIV slots are:

• 9a, PIV Authentication. Yubico describes it as authenticating the user, usually for system login. This is the slot Sectigo’s YubiKey instructions use for code signing certificates, and the slot our CSR guide generates the key in.
• 9c, Digital Signature. Yubico’s description is signing email, files and executables. It is the semantically natural slot for signing work, but it is not the one CA instructions for code signing tokens generally use, and it applies a stricter PIN policy.
• 9d, Key Management, for decryption.
• 9e, Card Authentication, usually building access.

If you followed our CSR instructions, your key is in 9a and the certificate goes into 9a. If you are not certain, do not guess. Run ykman piv info and read which slots hold a private key before you import anything. Slot f9 will usually also appear: that is the factory attestation slot, it is written by Yubico, and you never import into it.

Route 1: import the certificate with ykman

Step 1: check what is already on the key

Plug in the YubiKey, open a terminal and run:

ykman piv info

The output lists the PIV version, the remaining PIN and PUK tries, the management key algorithm, and then a block per occupied slot. Before the import, the slot that generated your CSR shows a private key type and no certificate fields. That is what you want to see. If the slot you were about to import into shows no private key at all, stop: you are aiming at the wrong slot.

On a YubiKey 5 FIPS the output also carries a FIPS approved line. Certificate import is not gated on FIPS approved mode, so a False there will not block this step, but key generation is gated, so if you got this far you are almost certainly already in approved mode. Entering it requires changing the management key, PIN and PUK away from their defaults, which is covered in the CSR guide.

Step 2: check the file format your CA sent

ykman reads three certificate formats: PEM, DER, and PKCS#12 (files ending .pfx or .p12). It does not read PKCS#7, which is what a .p7b or .p7c file is, and that is a common delivery format from CAs. If you have one of those, convert it first:

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.pem

That command assumes the .p7b is PEM encoded. Open the file in a text editor: if the first line reads —–BEGIN PKCS7—– you are fine. Some CAs send the same file DER encoded instead, which is binary and shows as unreadable characters, and then the command above stops with unable to load PKCS7 object. Tell OpenSSL the input format and it works:

openssl pkcs7 -inform DER -print_certs -in certificate.p7b -out certificate.pem

One useful behaviour to know about: if the file contains several certificates, for example your certificate plus the Sectigo intermediates in one PEM bundle, ykman imports only the leaf, the one whose subject is not the issuer of any other certificate in the file. So handing it a full chain bundle does not put the chain on the key. It puts your certificate on the key and ignores the rest, which is usually what you wanted anyway.

Step 3: import into the slot

From the folder containing the certificate file, run:

ykman piv certificates import 9a certificate.crt

The slot argument accepts either the hex identifier or the slot name, so ykman piv certificates import authentication certificate.crt does the same thing. Substitute your own filename, and use the full path if the file is somewhere else.

You will be prompted with Enter a management key [blank to use default key]. Type the management key you set when you initialized the device. Yubico’s own list of operations requiring the management key includes importing a certificate, and the PIN is not on that list, so on a normal setup this step asks for the management key and nothing else. Two situations change that: if you enabled the “protect with PIN” option, the PIN stands in for the management key, and if you add the verification flag below, the PIN is requested as well.

On success the tool prints:

Certificate imported into slot AUTHENTICATION

You can supply the credential inline instead of at a prompt with -m, and the PIN with -P, but both then sit in your shell history, so prefer the prompt for anything other than an automated build.

Step 4: prove the certificate matches the key

The import command can check the certificate against the key that is already in the slot, and it runs that check before it writes anything, so a mismatched certificate never reaches the device. It is worth making a habit: run the Step 3 command with the verification flag added instead of the plain form.

ykman piv certificates import --verify 9a certificate.crt

With that flag, ykman asks the YubiKey to perform a private key operation in the slot and checks the result against the public key inside the certificate. Because a key operation is subject to the slot’s PIN policy, you are asked for the PIN as well as the management key, and on a key configured with a touch policy it will wait for you to touch the device. If the pair does not match, the import stops before storing anything and prints:

The public key of the certificate does not match the private key in slot 9A (AUTHENTICATION).

If the slot holds no key at all, it stops with No private key in slot 9A (AUTHENTICATION). instead, which means you are certainly aiming at the wrong slot. The mismatch message is the ambiguous one: either you are in the wrong slot, or the certificate was issued from a different CSR than the one this key produced. If you already ran the plain import in Step 3, run it again with the flag. Nothing is lost, and you find out either way.

Route 2: import the certificate with Yubico Authenticator

If you would rather click than type, Yubico Authenticator for Desktop covers this operation. It runs on Windows, macOS and Linux. It does not generate CSRs, which is why the CSR half of this workflow is command line only, but importing is fully supported.

Step 1: open the Certificates screen

Plug the YubiKey into your computer and open Yubico Authenticator. Click the left menu icon in the upper left corner of the app and select Certificates. The screen lists the PIV slots and shows the current PIN and PUK attempts remaining under MANAGE.

Step 2: select the slot and choose Import file

Click the slot that holds the key pair from your CSR, normally 9A, and select Import file under ACTIONS. In a narrow app window the ACTIONS section is hidden behind the right menu icon in the upper right corner.

Read the slot label before you click. This is the same wrong-slot trap as the command line route, with less feedback, because Yubico Authenticator does not offer a key-matching check.

Step 3: unlock and pick the file

Enter the PIV management key when the Unlock PIV management window appears and click Unlock. Then select your certificate file and click Choose. If the file is a password protected PKCS#12, you will be asked for its password as well.

When the import succeeds, the certificate’s details appear under the slot on the Certificates screen. Confirm the Subject and the issuer read as you expect before you move on.

Verify the installation

Whichever route you used, check the result from the command line. It is the fastest way to see everything at once:

ykman piv info

The slot you imported into now carries a full block. The shape of it is:

PIV version:              5.7.1
PIN tries remaining:      3/3
PUK tries remaining:      3/3
Management key algorithm: AES192
FIPS approved:            True
Slot 9A (AUTHENTICATION):
  Private key type: RSA3072
  Public key type:  RSA3072
  Subject DN:       CN=Example Company Ltd,O=Example Company Ltd,C=US
  Issuer DN:        CN=Sectigo Public Code Signing CA R36,O=Sectigo Limited,C=GB
  Serial:           00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
  Fingerprint:      3b1f...
  Not before:       2026-08-04T00:00:00
  Not after:        2027-11-05T23:59:59

Four things to read carefully:

1. Private key type and Public key type must agree. If Private key type says EMPTY, you imported into a slot with no key and the certificate is unusable there.
2. Subject DN must be your validated legal entity, exactly as it appeared in the CSR. A code signing certificate carries the organization the CA validated, and that is the name users will see in the Windows signature dialog.
3. Issuer DN should name your CA’s intermediate, not your own organization.
4. Not before and Not after tell you the validity window. Since March 1, 2026 the CA/Browser Forum caps code signing certificates at 460 days, so a window well under two years is normal and not a mistake by the CA.

On Windows there is a second check worth running, because signing tools do not talk to the YubiKey directly. They go through the Windows certificate store, and Windows fills that store from the card while it is inserted, using the Certificate Propagation Service and its own inbox smart card minidriver. With the YubiKey inserted, run:

certutil -user -store My

Your code signing certificate should be listed, with a line indicating it has an associated private key. If it is missing, eject the YubiKey, wait a few seconds and reinsert it so Windows re-reads the card, and check that the Smart Card and Certificate Propagation services are running. You do not need Yubico’s separate YubiKey Minidriver for this: Yubico documents it as building on top of the Windows inbox minidriver, which already handles a card that holds a certificate. The Yubico driver adds provisioning and PIN management, so it is an option if Windows still will not pick the card up, not a requirement for signing.

Where the Sectigo intermediate and root actually belong

The old version of this page ended with a tip suggesting you install Sectigo’s intermediate and root certificates for “complete trust in your digital signatures across all computers”. That sentence needs correcting, because it points at the wrong machine.

Trust is decided on the computer that runs your signed file, not on yours. Installing a root certificate on your own workstation changes what your workstation trusts and has no effect whatsoever on anybody downloading your software. And you do not need to install the root anyway: Sectigo’s code signing roots are distributed through the Microsoft Trusted Root Program, so Windows already has them.

What genuinely matters is the intermediate, and it matters on the signing machine, at signing time. When SignTool signs a file it builds the certificate chain from what Windows can find locally and embeds that chain in the Authenticode signature. If the intermediate is not available while you sign, the chain it embeds is incomplete and verification on other machines depends on them fetching the missing piece themselves. There are two reliable ways to make it available:

• Install the intermediate into the Windows Intermediate Certification Authorities store. Double-click the file your CA supplied, choose Install Certificate, keep Current User, then select Place all certificates in the following store and browse to Intermediate Certification Authorities.
• Or hand the file straight to SignTool with the /ac option, which Microsoft documents as adding another certificate from a file to the signature block. This is the better option for a build server, because the signing command carries its own chain and nothing depends on machine state.

Sectigo’s own knowledge base also suggests loading the root and intermediates onto the YubiKey. That is a portability convenience rather than a trust mechanism: Windows copies certificates from an inserted smart card into the user’s certificate store, so the chain travels with the token. If you want that, use the retired key slots and never 9a, because writing to 9a would overwrite the certificate you just installed:

ykman piv certificates import 82 SectigoIntermediate.crt

If the PIN or management key is wrong

The two credentials behave completely differently when you get them wrong, and the difference is worth knowing before you start guessing.

The management key, which is what the import asks for, has no retry counter. Yubico states plainly that it cannot be blocked. A wrong value fails the operation with Authentication with management key failed. and nothing else happens. You can try again.

The PIN is the opposite. YubiKeys ship with a retry count of 3 for both the PIN and the PUK. Enter the PIN wrong three times in a row and it blocks, and then every operation needing the PIN fails even if you afterwards supply the correct one. ykman counts down for you as you go, printing PIN verification failed, 2 tries left. and so on, then PIN is blocked. A blocked PIN is recoverable with the PUK, which resets the PIN and restores the retry count. A blocked PUK is not recoverable at all, not even with the management key.

At that point the only remaining action is resetting the PIV application, and on a code signing key that is close to catastrophic. A PIV reset deletes the keys in every PIV slot and returns the PIN, PUK and management key to their defaults. The private key your certificate was issued to is generated on the device and cannot be exported, so it cannot be backed up and it does not come back. You would have to ask your CA to reissue against a fresh CSR from a fresh key pair.

One related point that catches people who bought a token and started clicking. The factory defaults are public: PIN 123456, PUK 12345678, and a management key of 010203040506070801020304050607080102030405060708. Yubico recommends changing all three before use, and on a YubiKey 5 FIPS with firmware 5.7 or later changing all three is what puts the device into FIPS approved mode in the first place. A code signing key left on factory defaults is a code signing key anyone who picks it up can sign with.

What comes next

With the certificate in the right slot and verified against its key, the YubiKey is ready to sign. That is a separate job with its own tool, SignTool from the Windows SDK, and its own set of traps around certificate selection, timestamping and verification flags. Our guide on how to sign an EXE file with a code signing certificate covers it.

Two things to carry over from this page. Timestamp every signature, because a timestamp keeps signed files valid after the certificate expires, and certificates now expire much sooner than they used to. And when you tell SignTool which certificate to use, identify it precisely with its SHA-1 thumbprint rather than letting the tool choose, since the YubiKey is not the only certificate in your Windows store.

Frequently asked questions

For the rest of the workflow, see our code signing tutorials.