troubleshooting a Windows code-signing issue involving a Sectigo code-signing certificate and a YubiKey

Hello,

The combination of symptoms you’re seeing points to a mismatch between how Windows expects to interact with the private key on the YubiKey and how the certificate was provisioned. The error 0x80100014 is a smart‑card communication error that usually means the CSP/KSP cannot perform the requested private‑key operation. In your case, certutil -scinfo shows the certificate under the Microsoft Smart Card Key Storage Provider, but also reports “Could not verify certificate public key against private key”. That indicates Windows can see the certificate object but cannot successfully bind it to the private key stored in the PIV slot.

This typically happens when the certificate was imported separately from the key, rather than generated as a key pair on the YubiKey and then having the CSR signed by the CA. With modern Sectigo code‑signing certificates, the private key is marked non‑exportable, so you cannot generate the key in Windows and then move it into the YubiKey. Instead, the supported workflow is to generate the key pair directly on the YubiKey PIV slot, export a CSR, have Sectigo issue the certificate against that CSR, and then import the issued certificate back into the same slot. That ensures the certificate and private key are correctly paired and Windows can perform signing operations through the Smart Card KSP.

Because your current certificate was likely imported without a matching key container, Windows can enumerate the certificate but fails when attempting to use the private key for signing. That explains why signtool finds the certificate but fails at SignerSign().

To resolve this, you’ll need to re‑provision the certificate properly:

1. Use ykman piv generate to create a key pair in the YubiKey slot (for code signing, slot 9a is typical).
2. Export a CSR from that slot (ykman piv request) and submit it to Sectigo.
3. Import the issued certificate back into the same slot (ykman piv certificates import).

Once the certificate is bound to the key generated on the YubiKey, Windows will be able to verify the public/private key match, and signtool or InstallShield will succeed when prompted for the PIN.

In short, the failure is not a Windows bug but a provisioning mismatch: the certificate is present, but the private key is not usable because it wasn’t generated on the YubiKey. The fix is to reissue or reimport the certificate using a CSR generated directly from the YubiKey.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

The error pattern indicates a failure in the Windows smart card / cryptographic stack when attempting to use the private key on the YubiKey, not a simple certificate-visibility problem.

From the data provided:

• certutil -scinfo sees the YubiKey, the certificate, and the Microsoft Smart Card Key Storage Provider.
• Public key matching test succeeds, but ERROR: Could not verify certificate public key against private key is reported.
• SignTool fails with SignerSign() failed and smart-card error 0x80100014.

These symptoms are consistent with a problem at the smart card / minidriver / cryptographic provider layer rather than with the certificate itself:

• The certificate is valid and has correct EKU (Code Signing) and Key Usage (Digital Signature), so policy/usage is not the primary issue.
• The smart card is visible to Windows and tools, so basic device enumeration is working.
• The failure occurs when attempting a private-key operation (signing), which is where the smart card provider and minidriver are exercised.

Relevant Windows-side checks and troubleshooting steps based on the provided context:

1. Verify smart card reader and device status in Device Manager
   Use Device Manager to confirm that the smart card reader and the YubiKey smart card interface are installed and not reporting errors:
   • Open Computer → Properties → Device Manager.
   • Expand Smart card readers and check the reader/YubiKey entry.
   • If the reader is not listed, use Action → Scan for hardware changes. Any issues here (missing device, warning icons) point to a driver/minidriver problem that must be resolved before signing will work.
2. Consider smart card minidriver / provider issues
   The context describes scenarios where incorrect or incompatible smart card drivers/minidrivers interfere with devices that rely on the Windows inbox smart card minidriver, causing errors like "This smart card cannot be used" and breaking PIV-based operations. In such cases:
   • Non-native or third-party smart card drivers that override the inbox minidriver can prevent correct interaction with PIV devices.
   • The result can be that certificates are visible but private-key operations fail, which matches the observed behavior.
   Given that certutil -scinfo shows the Microsoft Smart Card Key Storage Provider but still cannot verify the public/private key pair, this strongly suggests a provider/minidriver incompatibility or misconfiguration rather than a missing key.
3. Use CryptoAPI 2.0 diagnostics and event logs
   CryptoAPI 2.0 Diagnostics can be used to capture detailed information about certificate chain validation and signature operations:
   • Enable CryptoAPI 2.0 Diagnostics as described in the PKI troubleshooting guidance.
   • Reproduce the signing attempt (with SignTool) and review the resulting event log entries for errors related to key acquisition or smart card operations.
   Additionally, for SignTool errors, the context recommends:
   • Running signtool sign /debug ... to get more detailed certificate and filtering information.
   • Checking the relevant event logs (for example, under Applications and Services Logs for signing-related providers) for more specific error codes and messages.
4. Interpretation of KeySpec = 0 -- XCN_AT_NONE
   In the certutil -scinfo output, KeySpec = 0 -- XCN_AT_NONE indicates that the key is exposed via CNG (KSP) rather than legacy CAPI key specs (AT_KEYEXCHANGE or AT_SIGNATURE). The guidance for smart card–propagated certificates notes:
   • CryptAcquireCertificatePrivateKey returns either a CSP handle (CAPI) or a CNG handle.
   • When using this API, CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG should be set so that CNG keys are preferred.
   If any part of the signing toolchain (or an intermediate component) assumes a CAPI-style key spec instead of handling a CNG key with CERT_NCRYPT_KEY_SPEC, private-key operations can fail even though the certificate is visible. This is another way the provider/minidriver and API usage can cause the observed mismatch between visibility and usability.
5. Check for recent changes in cryptographic behavior and temporary workarounds
   The guidance for smart card–propagated certificates also describes a registry-based switch (DisableCapiOverrideForRSA) that controls enforcement vs. audit mode for a recent security change in cryptographic behavior. While that guidance is framed around CVE-2024-30098 and smart card–propagated certificates, the key points are:
   • Enforcement mode can change how keys are acquired and which APIs/providers are used.
   • A temporary registry key can switch behavior from enforcement to audit mode.
   If this environment has recently received updates that enforce new cryptographic behavior, and the YubiKey/minidriver or consuming tools are not fully aligned with the expected API usage (CNG vs. CAPI), this could contribute to private-key operation failures.
6. Next steps to isolate the root cause
   Based on the above, the most likely categories of root cause are:
   • Smart card minidriver/provider incompatibility or misconfiguration (for example, a third-party driver overriding the inbox minidriver and not correctly handling PIV keys for CNG).
   • A mismatch between how the key is exposed (CNG with KeySpec = 0) and how the signing tools or intermediate components attempt to access it.
   • Recent cryptographic enforcement changes affecting smart card key acquisition.
   To move forward:
   • Confirm in Device Manager that the smart card reader/YubiKey is using the expected driver and not an unexpected or vendor-specific minidriver that conflicts with the Windows inbox PIV minidriver.
   • Enable CryptoAPI 2.0 diagnostics, reproduce the signing attempt, and review the logs for detailed errors about key acquisition or smart card operations.
   • Use signtool sign /debug ... and correlate the debug output with event logs to see exactly where SignerSign() fails.
   • If recent updates introduced stricter cryptographic behavior, review the guidance for smart card–propagated certificates and consider whether the temporary registry-based workaround (switching from enforcement to audit mode) is appropriate in this environment, understanding that support for that key is time-limited.

These steps will help determine whether the issue is primarily with the YubiKey’s PIV/private key handling, the Windows smart card provider/minidriver, or the way the certificate and key are being accessed by the signing tools.

References:

• Can't authenticate because of an incorrect PIV smart card driver update
• Smart Card Troubleshooting
• Guidance for certificate handling for Smart Card propagated certificates