Certificate authentication prompt does not show up after being configured in ADFS.

  • Article

Hello everyone, we decided to write this article since the number of customers using certificate authentication is increasing, together with the number of cases.

This is one of the most common and problematic scenarios we are facing nowadays - and the reason why we are covering it today.

Scenario:

Hey Microsoft Support, we have configured all settings as the articles below state and this is not working, the user is never prompted for a certificate and the page just keeps loading:
https://blogs.msdn.microsoft.com/samueld/2016/07/19/adfs-certauth-aad-o365/

/en-us/windows-server/identity/ad-fs/operations/configure-user-certificate-authentication

 

Troubleshooting:

The quick fix (for this scenario also applies for android devices not authenticating), open the Local Computer certificates MMC, on the “Trusted Root” container check if there is any non-root CA certificate misplaced there.

If there is any, just remove them and restart the server (yes restart the server to update this information).

Important: You must do this on all ADFS and WAP servers.

Another way to find a misplaced certificate is by running the following PowerShell cmdlet:

 Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\computer_filtered.txt"

If there is any data on the output file, then you need to take action.

Moving forward with the analysis of the problem, what happens is:

When we are establishing an SSL communication for certificate authentication, the server will send the “Certificate Trust List” to the client so they can start the communication, this list is pretty much the information about all certificates placed in the “Trusted Root” container on the server.

Presenting this list to the client, the client can find a matching root certificate with one that it owns, to perform the cert based authentication.

If a non-root certificate is misplaced on the “Trusted Root” container, the server will not send the complete list, and the client will be unable to choose a personal certificate it has, that is trusted by the ADFS/WAP server.

We can see this behavior by taking a network trace on the client machine, we will use Wireshark here to make it simple:

  1. After capturing the trace, we need to configure Wireshark to show us the frames properly.First, locate a frame where the port 49443 (in ADFS 2012 R2 we use this port for cert authentication) was captured:
    With this setting applied we are telling Wireshark to consider the traffic on port 49443 as an SSL (default 443) traffic.
  2. On any frame, right-click and select “Decode As” and the following window will show, change column “Value” to 49443 and “Current” to SSL and click “Accept”:
  3. The last thing we will have to do is to apply the filter to show only SSL Handshake and the IP of the ADFS server:ssl.handshake && ip.addr == 198.1.1.1

 

Consequently, we will have a much cleaner capture to analyze now, we can seek (in this case) the last “Server Hello” frame, in the “Certificate Request” section, we are only sending one certificate, instead of the whole list:

 

If we look at the same section, for a scenario that works, we are be able to see the whole list as we do have on the server:

 

Conclusion:

To wrap it up, the rule is to have all certificates in their respective containers, Root, Intermediate, Personal and so on... If we misplace them, we will find ourselves in the scenario above.

If this is not the problem, it could be an issue with certificate’s AIA and CDP verification - but we will discuss this further in another article! :)