Remarque
- Date de publication d’origine : 21 novembre 2025
- ID de la Base de connaissances : 5073121
Journal des modifications
| Modifier la date | Modifier la description |
|---|---|
| 12 février 2026 |
|
| 11 décembre 2025 |
|
Introduction
Les mises à jour Windows du 14 octobre 2025 portant sur CVE-2024-30098 ont révélé des problèmes dans les applications où le code n’identifie pas correctement le fournisseur qui gère la clé pour les certificats propagés d’une carte à puce vers le magasin de certificats. Cette erreur d’identification peut entraîner l’échec des opérations de chiffrement dans certains scénarios. Ce document fournit des conseils aux développeurs d’applications sur la façon de détecter le gestionnaire correct et de résoudre ces problèmes.
Récapitulatif
Lorsque les certificats sont propagés d’une carte à puce vers le magasin de certificats Windows, le processus de propagation peut utiliser l’un des fournisseurs suivants :
- fournisseur de services de chiffrement (CSP) hérité, qui s’appuie sur l’interface CAPI (Cryptographic Application Programming Interface) héritée
- fournisseur de stockage de clé (KSP), qui s’appuie sur l’API de chiffrement : nouvelle génération (CNG). Il s’agit du remplacement moderne introduit dans Windows Vista.
Avant le correctif pour CVE-2024-30098, l’algorithme de propagation utilisait CSP pour les certificats basés sur RSA et KSP pour tous les autres. Cette approche n’était pas sécurisée car CAPI ne prend pas en charge les algorithmes cryptographiques modernes, ce qui limite les capacités de sécurité.
Les mises à jour de sécurité du 14 octobre 2025 ont supprimé cette gestion spéciale et KSP est désormais utilisé pour tous les certificats.
Déterminer l’ensemble d’API à utiliser
Les applications qui s’appuient sur des clés RSA gérées par CSP peuvent échouer lorsque la clé est gérée par KSP. Pour résoudre ce problème, les applications doivent détecter quel fournisseur gère la clé et utiliser le jeu d’API correspondant (CAPI ou CNG).
Important
N’utilisez pas les fonctions CryptAcquireContextW ou CryptAcquireContextA car l’API est obsolète. Utilisez plutôt la fonction CryptAcquireCertificatePrivateKey .
Fonction CryptAcquireCertificatePrivateKey
L’appel de CryptAcquireCertificatePrivateKey retourne un handle (phCryptProvOrNCryptKey) de type HCRYPTPROV_OR_NCRYPT_KEY_HANDLE. Ce handle peut être :
- Descripteur CSP (HCRYPTPROV) : utilisez les fonctions CryptoAPI comme CryptSignHash.
- Descripteur CNG (NCRYPT_KEY_HANDLE) : utilisez les fonctions CNG comme NCryptSignHash.
Remarque
Lors de l’appel de CryptAcquireCertificatePrivateKey, veillez à inclure le CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG dans le paramètre dwFlags.
Pour déterminer le type de descripteur, vérifiez la valeur pdwKeySpec dans une case activée :
| Valeur pdwKeySpec | API Crypto à utiliser |
|---|---|
| AT_KEYEXCHANGE ou AT_SIGNATURE | CAPI |
| CERT_NCRYPT_KEY_SPEC | GNC |
Solution de contournement
Une solution de contournement temporaire est disponible pour les clients touchés par l’application de cette modification. Une clé de Registre temporaire est disponible pour faire passer le comportement du mode de mise en conformité au mode Audit .
Important : La prise en charge de cette clé de Registre sera supprimée dans les mises à jour de février 2027.
| Chemin d’accès au Registre | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais |
|---|---|
| Type | REG_DWORD |
| Nom de la valeur | DisableCapiOverrideForRSA |
| Données de la valeur |
1 = activer le correctif de sécurité (mode de mise en conformité) 0 ou clé supprimée = désactiver le correctif de sécurité et basculer en mode audit |
Références
Stockage et récupération de clés
Fonction CryptAcquireCertificatePrivateKey (wincrypt.h)
.