Note
- Original publish date: November 21, 2025
- KB ID: 5073121
Change log
| Change date | Change description |
|---|---|
| February 12, 2026 |
|
| December 11, 2025 |
|
Introduction
The October 14, 2025, Windows updates addressing CVE-2024-30098 revealed issues in applications where the code does not correctly identify which provider is managing the key for certificates propagated from a smart card to the certificate store. This misidentification can cause cryptographic operations to fail in certain scenarios. This document provides guidance for application developers on how to detect the correct handler and resolve these issues.
Summary
When certificates are propagated from a smart card to the Windows certificate store, the propagation process can use either of the following providers:
- Legacy Cryptographic Service Provider (CSP), which relies on the legacy Cryptographic Application Programming Interface (CAPI)
- Key Storage Provider (KSP), which relies on Cryptography API: Next Generation (CNG). This was the modern replacement introduced in Windows Vista.
Prior to the fix for CVE-2024-30098, the propagation algorithm used CSP for RSA-based certificates and KSP for all others. This approach was insecure because CAPI does not support modern cryptographic algorithms, limiting security capabilities.
The October 14, 2025, security updates removed this special handling and now KSP is used for all certificates.
Determine the API set to use
Applications that rely on RSA keys being managed by CSP may fail when the key is managed by KSP. To resolve this, applications must detect which provider manages the key and use the corresponding API set (CAPI or CNG).
Important
Do not use the CryptAcquireContextW or the CryptAcquireContextA functions as the API is deprecated. Instead, use the CryptAcquireCertificatePrivateKey function.
CryptAcquireCertificatePrivateKey function
Calling CryptAcquireCertificatePrivateKey returns a handle (phCryptProvOrNCryptKey) of type HCRYPTPROV_OR_NCRYPT_KEY_HANDLE. This handle can be:
- CSP handle (HCRYPTPROV): Use CryptoAPI functions like CryptSignHash.
- CNG handle (NCRYPT_KEY_HANDLE): Use CNG functions like NCryptSignHash.
Note
When calling CryptAcquireCertificatePrivateKey, be sure to include the CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG in the dwFlags parameter.
To determine the handle type, check the pdwKeySpec value:
| pdwKeySpec value | Crypto API to use |
|---|---|
| AT_KEYEXCHANGE or AT_SIGNATURE | CAPI |
| CERT_NCRYPT_KEY_SPEC | CNG |
Workaround
A temporary work around is available for customers that are impacted by the enforcement of this change. A temporary registry key is available to switch the behavior from Enforcement to Audit mode.
Important: Support for this registry key will be removed in the February 2027 updates.
| Registry path | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais |
|---|---|
| Type | REG_DWORD |
| Value name | DisableCapiOverrideForRSA |
| Value data | 1 = enable the security fix (enforcement mode) 0 or key removed = disable the security fix and switch to audit mode |
References
CryptAcquireCertificatePrivateKey function (wincrypt.h)
CVE-2024-30098 | Windows Cryptographic Services Security Feature Bypass Vulnerability
.