I am quite adept at configuring certificates and changing them around, but this one took me completely by surprise as it has a bunch of oddities to consider.
First the errors: Web Application Proxy (WAP) reported 0x80075213. In the event log the following:
The federation server proxy could not establish a trust with the Federation Service.
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Ensure that the credentials being used to establish a trust between the federation server proxy and the Federation Service are valid and that the Federation Service can be reached.
Unable to retrieve proxy configuration data from the Federation Service.
Trust Certificate Thumbprint:
System.Net.WebException: The underlying connection was closed: The connection was closed unexpectedly.
This was ultimately caused by the certificate on the AD FS Server having been replaced in the user interface, but this did not replace the certificate that HTTP was using or the published web applications and the certificates they were using.
So here are the steps to fix this issue:
AD FS Server
- Ensure the certificate is installed in the computer store of all the AD FS servers in the farm
- Grant permissions to the digital certificate to the ADFS Service account. Do this by right-clicking the new digital certificate in the MMC snap-in for certificates and choosing All Tasks > Manage Private Keys. Grant read permission to the service account that ADFS is using (you need to click Object Types and select Service Accounts to be able to select this user). Repeat for each server in the farm.
- In the AD FS management console expand service > certificates and ensure that the service communications certificate is correct and that the date is valid.
- Open this certificate by double-clicking it and on the Details tab, check the value for the Thumbprint.
- Start PowerShell on the AD FS Server and run Get-AdfsSslCertificate (not Get-AdfsCertificate). You should get back a few rows of data listing localhost and your federation service name along with a PortNumber and CertificateHash. Make sure the CertificateHash matches the Thumbprint for the service communications certificate.
- If they do not, then run Set-AdfsSslCertificate -Thumbprint XXXXXX (where XXXXX is the thumbprint value without spaces).
- Then you need to restart the ADFS Server.
- Repeat for each member of the farm, taking them out and in from any load balancer configuration you have. Ensure any SSL certs on the load balancer are updated as well.
Web Application Proxy
- Ensure the certificate is installed in the computer store of the web application proxy server as well. Permissions do not need to be set for this service.
- Run Get-WebApplicationProxySslCertificate. You should get back a few rows of data listing localhost and your federation service name along with a PortNumber and CertificateHash. Make sure the CertificateHash matches the Thumbprint for the service communications certificate. If it does not use Set-WebApplicationProxySslCertificate -Thumbprint XXXXX to change it. Here XXXXX is the thumbprint value without spaces.
- Restart WAP server and it should now connect to the AD FS endpoint and everything should be working again.
- Check that each Web Proxy Application is using the new certificate. Do this with Get-WebApplicationProxyApplication | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint XXXXXX (where XXXXX is the thumbprint value without spaces). This sets all your applications to use the same certificate. If you have different certificates in use, then do them one by one with Get-WebApplicationProxyApplication | Format-Table Name,ExternalCert* to see what the existing thumbprints are and then Get-WebApplicationProxyApplication “name” | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint XXXXXX to do just the one called “name”.
Thanks Brian. The Set-AdfsSslCertificate -Thumbprint XXXXXX command save my bacon. We had to change the Server Communication certificate and none of the Microsoft documentation advise you to change this setting. Without it the WAP and ADFS servers will never communicate with the new certificate.
fantastic article with clear concise instructions. certificate renewal certainly broke a customer’s ADFS authentication. finding out the cert being used and thumbprint of it was very important in getting it back up and running.
Thanks, a good clear exposition.
What caught me out was that if you have a load-balanced farm of adfs servers, the certificate must be updated on both of them separately. Technet (somewhere) says that changes you make on the primary get replicated, and in fact you can’t even run the adfs management snap-in on the secondary – you get a message saying “make all changes on the primary”. But it lies.
After updating the cert on the secondary adfs server, I was able to re-establish the WAP trust successfully.
I suspect you have two different farms of a single server in each. You cannot make changes on the secondaries (you can open the admin tools, but not make changes). You do though need to import the cert to each machine first.
Posts on other sites pointed to completely different and unrealted issues.
You solution has saved my bacon so thanks so much!
Thank you so much … you are great help! Not even Microsoft’s proposed solutions worked for me.