Fixing a problem recently where our ADFS servers or more specifically our ADFS WAP servers seem to hold onto an old expired certificate as part of the certificate chain that was causing us issues because the root certificate had expired as below:
The expired route certificate in this example expired on 22nd September 2024, however, in your example, this could be a random date in the future the time it expires is not the important thing here.
ADFS Federation Servers
The ADFS federation servers - these are the ones that are joined to the domain that process the actual token and talk to active directory and an SQL server use the local certificate store for the computer, this means if you wish to update the service communication certificate (This is the one bound to your public name) then you can choose the certificate from the local certificate store either via the MMC or Powershell.
ADFS WAP Servers (where the issue is)
However, on the ADFS WAP you have an extra layer of complication because the website is actually served by HTTPAPI engine, which means when you add a certificate, the hierarchy of that certificate, including the chain is imported into the running configuration - you will get no management tools in the form of a GUI That will allow you to manage certificates or for that matter anything related to the WAP server.
WAP Server?
WAP stands for web application proxy, and in this particular instance, it is part of the remote access Role that will let you serve applications publicly to end points, These servers are usually always in a work group so any automatic updating of certificates will not apply to the servers unless specifically configured manually.
WAP running configuration does not include local certificate store
When you change the certificate, you import the certificate with the chain into the running configuration of the WAP server, which means if you reboot the server or even restart a services the configuration does not change from the last time it was read, the certificate was imported using Powershell.
This also means by the same token if you manually update the local computer store, this is there not reflected in the running configuration on the WAP server because there is no link between that certificate store and the running configuration, Even if you update the local certificate store and then recycle of the services or even reboot, the server.
In this particular example, the certificate doesn’t expire until the year 2025, however it was imported 11 months earlier in 2024, during that import, the certificate and the chain will have been read by the application and stored in the running configuration
Back to the Expired Root
If we then roll the clock forward to the current day, and by that I mean, since the certificate was renewed, We have obviously had something changed with the root certificate authority because the original certificate has expired and the new one has been issued that ironically expires in the year 2030, This certificate has been been installed locally Into the local computer certificate store.
Unfortunately, this has no impact on the WAP configuration, which is where the problem is located, our particular problem was the fact that one of the root certificates had expired and was still in the running configuration as you can see below:
In this examples, this clearly shows that the certificate "Entrust Root Certification Authority - G2" is still being used but has expired, expired certificates have a undesired effect of Federated traffic with the fact that the chain and the certificate need to be trusted in order for the Federation to successfully work, obviously, if the chain is incorrect, and your certificates are not already installed with Windows then new devices will not be able to verify their authenticity.
This problem will usually affect new devices, not existing ones
It is also worth noting that existing devices have the ability to automatically update missing root certificates, which means they will not likely to be affected as much as a new client that needs to discover it for itself, this is usually taken care of either by Windows updates (If your certificate provider is in the SSL insider program) and the Windows feature called “Update Root certificates” however as I said earlier this has been rollup into Windows updates now.
Fixing the Issue
Right, let’s get back to the problem at hand, First, we need to check the running configuration on the WAP server, so start a Powershell console as an administrator and then run this command:
Get-WebApplicationProxySSLCertificate
They should then return a list of host names, ports, and the certificate thumbprint like this:
You are not really able to query in depth, the running configuration of the WAP service with this command, even if you get a more detailed overview, it will simply give you the name of the certificate and no further information like this:
Note : Ensure you make a note of the value under the column thumbprint you will need it later
Does this mean the problem cannot be fixed? Well no, absolutely not, in this particular instance, the certificate is correct in the local computer store, but fails to be consistent in the WAP service - This means the solution is to run the following command:
Set-WebApplicationProxySSLCertificate
However, hold on one moment, you need to know the syntax, The variable we are going to use on the end of this command is “thumbprint” - the source of the thumbprint is the value you get when you run the previous command like this:
Set-WebApplicationSSLCertificate -Thumbprint <id>
When you execute that commands, you will get a confirmation that the deployment was successful as below:
When you see this confirmation, you do not need to restart the services. It will do this for you automatically, and it will also remove all the incorrect bindings and add new ones which you could observe if you check the System event log you should see warning events to say the endpoint bindings have been removed and added as below:
Warning : You will need to repeat this command on all your WAP servers
Once this command has been run, your certificate will then due to a deployment be updated to the current active certificate that does not have an expiring root certificate linked to it as you can see below:
