Incorrect CNG/CSP detection breaks certificate probing when an expired Xbox Live certificate is installed

[episource]

I encountered this issue on two Windows systems that still had expired Xbox Live infrastructure certificates installed. The affected certificates had the issuer XBL Client IPsec Issuing CA and a subject CN consisting of a seemingly random 16-digit hexadecimal number.

When NativeCapi.QueryCertificatePrivateKey probes one of these certificates, it selects the legacy CSP path and calls CryptAcquireContext. CryptAcquireContext then fails with:

0x80090014 NTE_BAD_PROV_TYPE
Invalid provider type specified / ungültiger Anbietertyp angegeben

(Note: in the user display of the error, the error code is mapped to a generic 0x80004005 E_FAIL, message is preserved)

The more severe consequence is that this exception occurs while certificates available on the local system are being probed. On the affected systems, the exception aborts enumeration of smart-card-backed certificates entirely, rendering the plugin unusable even though the problematic Xbox Live certificate isn't relevant anyway and would have been ruled out.

[episource]

The underlying problem appears to be the distinction between CNG key storage providers and legacy CSPs.

GetParameters obtains the certificate's CERT_KEY_PROV_INFO_PROP_ID and maps its fields as follows:

• dwProvType → CspParameters.ProviderType
• dwKeySpec → CspParameters.KeyNumber

However, QueryCertificatePrivateKey currently uses CspParameters.KeyNumber to select the API:

if (cspParams.KeyNumber == 0) {
    // NCryptOpenStorageProvider
} else {
    // CryptAcquireContext
}

According to the CRYPT_KEY_PROV_INFO documentation, dwProvType is the relevant discriminator and dwKeySpec != 0 aka KeyNumber isn't a clear indication of a CSP key.

[episource]

Confirmed 1c1c30d fixes this. Part of next release.