Does NPS support SHA256 certificates?

    General discussion

  • Hi,

    We have 2 environments - 1 CA using SHA1 and the other using SHA2.

    The one using SHA1, it's working fine i.e. NPS can authenticate the computer device certs.

    However, for SHA2, it's not working. I have been troubleshooting for a few days, so before going further, I just wanted to make sure NPS supports SHA256 certificates.


    Tuesday, March 5, 2013 3:11 PM

All replies

  • Hi,

    Thank you for the post.

    As far as I understand, starting with Windows Vista and Server 2008, SHA2 is included in the operating system as per this article:


    Nick Gu - MSFT

    Friday, March 8, 2013 1:30 AM
  • Hi

    I have this problem too

    is there any workaround ?

    My NPS works with SHA-1 Cert but not with SHA-2

    Wednesday, December 24, 2014 9:57 AM
  • Today I was required to renew my 802.1x certificate, and my CA only wanted to issue me a SHA-2 certificate.   I made sure I installed the Intermediate Certificates; as I have had to do in the past when we got this system built, as I've read the NPS will send the certificate chain to the client device.   The SHA-2 certificate did not restore my 802.1x Wireless.  Clients received "Could not connect". 

    I can confirm that after calling them and obtaining a SHA-1 certificate, everything is working.  However, they informed me the expiration on SHA-1 is the end of this year; at which time they are no longer able to issue SHA-1.

    Windows Server 2008 R2 Standard SP1

    Microsoft Network Policy Server (NPS) {for RADIUS}

    Ruckus Wireless 9.5.1(50)

    The NPS server (and my domain client computers) trust the SHA-2 Root CA used (GoDaddy G2), so it was not a certificate chain issue.

    With SHA-2 Certificate installed, the following event is logged at every attempt.

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          4/7/2015 9:31:29 AM
    Event ID:      6273
    Task Category: Network Policy Server
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      <servername>
    Network Policy Server denied access to a user.

    Contact the Network Policy Server administrator for more information.

     Security ID:   DOMAIN\<username>
     Account Name:   <username>
     Account Domain:   DOMAIN
     Fully Qualified Account Name: DOMAIN\<username>

    Client Machine:
     Security ID:   NULL SID
     Account Name:   -
     Fully Qualified Account Name: -
     OS-Version:   -
     Called Station Identifier:  58-93-96-0D-3B-AC:<WiFi SSID>
     Calling Station Identifier:  10-A5-D0-CF-21-7F

     NAS IPv4 Address:  NPS Client IP_ADDRESS
     NAS IPv6 Address:  -
     NAS Identifier:   58-93-96-0D-3B-AC
     NAS Port-Type:   Wireless - IEEE 802.11
     NAS Port:   4

    RADIUS Client:
     Client Friendly Name:  <NPS Client / Wireless Controller>
     Client IP Address:   NPS Client IP_ADDRESS

    Authentication Details:
     Connection Request Policy Name: NAP 802.1X (Wireless)
     Network Policy Name:  Non NAP-Capable
     Authentication Provider:  Windows
     Authentication Server:  <servername>
     Authentication Type:  EAP
     EAP Type:   -
     Account Session Identifier:  -
     Logging Results:   Accounting information was written to the SQL data store.
     Reason Code:   22
     Reason:    The client could not be authenticated  because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.

    Log Name:      Application
    Source:        Microsoft-Windows-EapHost
    Date:          4/7/2015 9:31:30 AM
    Event ID:      1004
    Task Category: Authenticator
    Level:         Information
    User:          SYSTEM
    Computer:      <servername>
    Negotiation failed. No available EAP methods

    NPS Accounting Log:

    The most important detail here is that the client received an NPS Packet_Type 3 which is Access-Reject

    id timestamp Computer_Name Packet_Type User_Name Client_IP_Address Fully_Qualified_Machine_Name NP_Policy_Name MS_Quarantine_State MS_Extended_Quarantine_State System_Health_Result System_Health_ResultEx MS_Network_Access_Server_Type Called_Station_Id MS_Quarantine_Grace_Time MS_Quarantine_User_Class Client_IPv6_Address Not_Quarantine_Capable AFW_Zone AFW_Protection_Level Quarantine_Update_Non_Compliant MS_Machine_Name OS_Version MS_Quarantine_Session_Id Calling_Station_Id
    28211843 2015-04-07 09:31:30.030 <servername> 1 <username> NPS_Client_IP_ADDRESS NULL Non NAP-Capable NULL NULL NULL NULL NULL 58-93-96-0D-23-98:SSID NULL NULL NULL NULL NULL NULL 0 NULL NULL NULL 20-62-74-5C-22-54
    28211844 2015-04-07 09:31:30.030 <servername> 3 NULL NPS_Client_IP_ADDRESS NULL Non NAP-Capable NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL 0 NULL NULL NULL NULL

    • Edited by ECTS-ISTM Tuesday, April 7, 2015 3:16 PM
    Tuesday, April 7, 2015 2:48 PM
  • Can anyone speak to Server 2008 R2 SP1 support for SHA-2 in the NPS role for use in EAP auth?
    Wednesday, July 22, 2015 5:00 PM
  • We never did find something that gave us a definitive answer to this question.  I think "Crickets" was what we were hearing.  We were potentially looking at a wireless outage for over 20,000 people if this didn't work.

    We have 2008R2 SP1, NPS, Radius and PEAP clients plus a remote location.  We used an InCommon SHA2 SSL cert.  Everything came up fine on all NPS policies.

    Friday, February 19, 2016 5:14 PM
  • On my Windows 2008 Server running NPS, when I initially downloaded my renewed certificate from my public CA, the certificate did not work.  The expired certificate was SHA1, the renewal was SHA2.  The certification path was different, but both certificates Root CA were the same; there were just different intermediate CA's between.  I imported the intermediates into the Trusted Root CA's on the server, as well as the renewed certificate into the Personal Store on the server.

    When in NPS, the new certificate was valid, and configured on the Policies.

    However, no client could authenticate, or if they could, they had "validate certificate' disabled in their PEAP client (phone, tablet, etc...).

    In the Event Logs on the Windows 2008 Server the following events were getting logged:

    Log Name:      System
    Source:        Schannel
    Date:          4/7/2016 3:23:33 PM
    Event ID:      36869
    Task Category: None
    Level:         Error
    User:          SYSTEM
    Computer:     <servername>
    The SSL server credential's certificate does not have a private key information property attached to it. This most often occurs when a certificate is backed up incorrectly and then later restored. This message can also indicate a certificate enrollment failure.
    Event Xml:
    <Event xmlns="">
        <Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" />
        <TimeCreated SystemTime="2016-04-07T19:23:33.060755600Z" />
        <Correlation />
        <Execution ProcessID="716" ThreadID="2636" />
        <Security UserID="S-1-5-18" />
        <Data Name="Type">server</Data>

    When looking in the Certificate Management MMC of the Local Computer certificates, the new certificate was installed, but did not have a 'key' ontop of the certificate icon, indicating the new certificate did not have a private key associated with it; as the expired certificate did.

    I thought this was odd; since it was just a renewal.

    After running the following command, to repair the private key on that certificate; my 802.1x NPS/PEAP authentication issues were resolved.

    • In the Certificates snap-in, double-click the imported certificate that is in the Personal folder.
    • In the Certificate dialog box, click the Details tab.
    • Click Serial Number in the Field column of the Details tab, highlight the serial number, and then write down the serial number.
    • Click Start, click Run, type cmd, and then click OK.
    • At the command prompt, type the following:
      certutil -repairstore my "SerialNumber"

    Technology Administrator Erie County (Career and) Technical School.

    • Edited by J. Smith Thursday, April 7, 2016 7:57 PM
    Thursday, April 7, 2016 7:57 PM