Certificate based smart card logon to Windows 10/11 with FIPS certified smart card

Geoffrey 0 Reputation points
2024-01-22T03:19:29.24+00:00

Latest FIPS 140-2 Level 3 and FIPS 140-3 have limited HASH algorithm to SHA256/384/512 and SHA-1 can not be used for security reasons. If I use a FIPS certified smart card to do certificate based smart card logon to Windows 10 and Windows 11 (Windows 10/11 has been on-prem Domain joined and has smart card logon certificate provisioned), the logon process will fail because the kerberos/PKINIT always uses SHA-1, even though I changed CSP/Minidriver to report only SHA256/384/512 algorithm support list to Windows, and I changed according to https://www.anoopcnair.com/configure-hash-algorithms-for-certificate-logon/ to disable SHA-1. I logged the process of lsass.exe calling CSP/Minidriver, it will create SHA-1 hash and then sign the SHA-1 digest later.

So how to use FIPS certified smart card (without SHA-1) to logon to windows 10/11?

Windows for business | Windows Client for IT Pros | Devices and deployment | Configure application groups
Windows for business | Windows Client for IT Pros | User experience | Other

1 answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Allan Solomon Mejia 7,915 Reputation points
    2026-08-14T19:31:14.74+00:00

    Hello @Geoffrey

    Since this thread is still getting reports on newer Windows versions, one important point is that Microsoft now provides explicit PKINIT hash algorithm controls for certificate-based Kerberos authentication.

    The policy is:

    Computer Configuration > Administrative Templates > System > Kerberos > Configure hash algorithms for certificate logon

    Microsoft documents separate settings for SHA-1, SHA-256, SHA-384, and SHA-512. SHA-1 can be configured as Not Supported, while the stronger algorithms can be enabled/supported.

    However, this needs to be considered on both sides of PKINIT. Changing the smart-card CSP/minidriver or the certificate's signature algorithm alone doesn't guarantee that Kerberos will stop requesting SHA-1. Smart-card domain logon ultimately uses Kerberos PKINIT, with LSASS/Kerberos constructing the authentication request.

    For environments seeing logon failures after disabling SHA-1, I would therefore verify that the PKINIT hash policies on the Windows client and domain controllers/KDCs are compatible and that SHA-256 or stronger is enabled before enforcing SHA-1 as Not Supported.

    It may also be useful to initially configure SHA-1 as Audited rather than immediately disabling it. Microsoft documents Event ID 206 when an audited algorithm is used, which can help identify whether PKINIT is still depending on SHA-1 before enforcing the change.

    Sharing you some key references:

    Microsoft Learn: Kerberos Policy CSP / PKINIT hash configuration https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-kerberos?

    Microsoft Learn: Smart card certificate requirements and authentication flow | https://learn.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration?

    Microsoft Open Specifications: Windows PKINIT implementation | https://learn.microsoft.com/en-us/openspecs/windows_protocols/MS-PKCA/d0cf1763-3541-4008-a75f-a577fa5e8c5b?

    Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.