ADFS WAP : No 443 Binding

I recently ran into a frustrating issue while updating SSL certificates on an ADFS Web Application Proxy (WAP) server that I thought was worth sharing. Sometimes the simplest tasks can throw you the biggest curveballs!

The Problem

When I updated the SSL certificate on my ADFS WAP server using the standard PowerShell command, which is the correct command:

Set-WebApplicationProxySslCertificate -Thumbprint A7F2C8E9B1D4567890ABCDEF1234567890FEDCBA

Instead of getting the expected certificate bindings, I ended up with this weird configuration where the main ADFS service wasn't bound to the standard HTTPS port 443:

HostName                           PortNumber  CertificateHash
--------                           ----------  ---------------
EnterpriseRegistration.pokeb...     443       A7F2C8E9B1D4567890ABCDEF1234567890FEDCBA
adfs.bythepowerofgreyskull.com      49443     A7F2C8E9B1D4567890ABCDEF1234567890FEDCBA

Notice how adfs.severntrent.co.uk is bound to port 49443 instead of 443? That's definitely not what we want for production traffic.

Monitoring alerted of "issues"

Monitoring then confirmed something was not correct as you can see below:

The SSL handshake incident was the problem and failed as the service was no longer listening on TCP:443 as you can see below:

Review Event Log

Yes, its all in the Event Log if you look at this event log Microsoft-Windows-WebApplicationProxy/Admin you will notice this event : 

Web Application Proxy encountered an error while retrieving the configuration 
from configuration storage.

Details: (0x80072efd).
Web Application Proxy will continue to use the existing configuration.

You can see that here in the event log:

This means the binding did not work and its incomplete and the configuration is still using the old certificates despite updating the thumbprint.

The Solution

After some troubleshooting, I discovered this issue stems from the WAP configuration status getting a bit confused. Here's the fix that worked for me:

Step 1: Reset the Proxy Configuration Status

First, I needed to tell the system that the WAP wasn't properly configured:

1. Launch regedit
2. Navigate to HKLM\Software\Microsoft\ADFS\ProxyConfigurationStatus
3. Change the ProxyConfigurationStatus value from "2" (configured) to "1" (not configured)

Step 2: Reconfigure the Web Application Proxy

Next, I ran through the configuration wizard again to properly bind everything:

1. Launch the Remote Access Manager snap-in
2. Select Web Application Proxy
   
   
   
   
   
3. Select Run the Web Application Proxy Configuration Wizard
   
   

   
4. Enter the name of the service for ADFS and provide administrator credentials for the ADFS Federation servers:
   
   

   

   
   
   
5. When prompted, select the certificate you have previously installed as below:
   
   
   
   
   
   
6. Then confirm the details and click Configure:
   
   
   
   
   
7. The ADFS WAP service will then configure itself:
   
   

   

   
   
   
8. When configured it will confirm this and you can click Close:
   
   

   

   
   

The Result

After running through this process, the certificate bindings looked exactly as they should:

HostName                           PortNumber  CertificateHash
--------                           ----------  ---------------
adfs.bythepowerofgreyskull.com       443      A7F2C8E9B1D4567890ABCDEF1234567890FEDCBA
EnterpriseRegistration.bythepow.     443      A7F2C8E9B1D4567890ABCDEF1234567890FEDCBA
adfs.bythepowerofgreyskull.com       49443    A7F2C8E9B1D4567890ABCDEF1234567890FEDCBA

Perfect! Now both the main ADFS service and Enterprise Registration are properly bound to port 443 with the new certificate.

Monitoring Recovers

When the reconfiguration was completed the monitor then recovered as you can see below as the port was now available on TCP:443 and the handshake error had been resolved:

Why did this happens?

This actually occurred as when you try to copy the command from notepad, sometimes it adds characters into this text that it should not, in this example it added a space:

This then causes the command to fail but then when you remove the weird space character and run the command again it then works, but this success is a lie after that error, it has corrupted its configuration at this point.

Message                                   Context              Status
-------                                   -------              ------
The configuration completed successfully. DeploymentSucceeded Success

When you are in this state you need to rebuild the configuration and next time remove the "special space" character before pressing enter, if you run the command without the space the update does work as it should