[probably a bug] ECDSA (NIST P-384)/SHA384-signed certificates are not recognized on Windows 10

[vessokolev]

Description of the problem: If the HSM token hosts both RSA and ECDSA certificates (the latter based on NIST P-384 curve and signed by SHA-384), only the RSA-based ones are detected by Windows.

Note: It is not clear what causes the problem. Consider this issue primarily as a request for comment.

Expected result: ECDSA certificates to be accessible as Windows Digital IDs

Is reproducible: Yes, always (three fresh Windows 10 Pro and one Windows 10 Enterprise installations are currently being examined)

Environment: Freshly installed Windows 10 Pro/Enterprise with all security updates applied; OpenSC 0.24, shm-middleware-x64-2.12, SHA-384 and SHA-512 support is added to the Registry.

Other symptoms: Mozilla Firefox and Thunderbird are capable of displaying all certificates installed in the token (both RSA and ECDSA-based) and operating with them, provided the correct PKCS#11 module is configured with the NSS (either sc-hsm-pkcs11.dll or opensc-pkcs11.dll). Google Chrome, Brave, and Microsoft Edge can operate only with the RSA-based certificates hosted by the token. Adobe Acrobat can operate with the RSA-based certificates natively (no custom PKCS#11 provider is configured). If PKCS#11 provider is loaded in Adobe Acrobat (either sc-hsm-pkcs11.dll or opensc-pkcs11.dll), the ECDSA-based certificates become visible in the list with DigitalIDs, but due to the limitation of Adobe Acrobat and its well-know lack of cryptography support, those ECDSA certificates cannot be used for signing through any PKCS#11 provider (correct me if I am wrong). FoxitReader cannot utilize ECDSA certificates at all (regardless of the provider).

Logs and tests: (see the attached file - output generated by The Microsoft Smart Card Resource Manager) It misses to show two ECDSA-based certificates installed inside the token and shows information only about the RSA-based certificates stored there.
log_windows_ecdsa_sha384_issues.log

[vessokolev]

Just a short update. It appears that the SHM tokens produced by Yubico, like YubiKey 5 Nano, express the same issue on Windows 10 Pro/Enterprise, so it is likely a general bug of misconfiguration. I would greatly appreciate any comments or suggestions that could help me identify the source of the issue.

[vessokolev]

After some discussion with Yubico support, we managed to solve the problem with their tokens - once their mini driver is installed, the ECDSA token on the token is recognized as Windows Digital ID. Does that mean that the problem reported above is due to a problem with sc-hsm-middleware?