Recently we ran into a bit tricky situation with one Dynamics 365 on-premise environment. This Dynamics 365 was configured to use claims-based authentication and IFD. The ADFS service was running on a separate server and was using a wildcard SSL certificate for service communications, token-decrypting and token-signing services. This wildcard certificate was purchased from a public CA. The servers in this environment were Windows Server 2012 R2 so the ADFS version was 18.104.22.168.
In June the wildcard certificate was renewed because it would expire in July. The new wildcard certificate was installed to all the servers considering this Dynamics environment. The usual steps were taken to deploy the new wildcard certificate into use also in ADFS and Dynamics web servers (used the Set Service Communications Certificate UI command in ADFS console, re-configuration of claims-based authentication and IFD etc.). Everything ran smoothly. Until when the old certificate expiration date occurred. At that time, the Dynamics IFD authentication stopped from working and a certificate expiration error was shown in the browser when trying to access CRM web site. Naturally by ignoring the expired certificate error, user could still access the CRM web site but as you all know, this is not very good practice for a production environment.
It was a bit strange situation because in the ADFS management console, it showed that the new wildcard certificate was being used but still, when trying to access the CRM service via browser, the expired certificate error was thrown. When checking the certificate details in the browser, it was still pointing to the old certificate. The initial steps that were taken to troubleshoot this issue was to remove (delete) the expired wildcard certificate from the servers. But this seemed to be a big no-no. Because after that, the CRM ADFS service communications seemed to totally stop from working. When trying to access CRM service, a 503 error was thrown by the ADFS endpoint.
Quite a lot of head banging to the wall was done next to investigate that where the old certificate was still being used. Until we tried the following PowerShell command in the ADFS server:
This command lists the SSL bindings being used for each hostname by the ADFS service. The command shows also the certificate thumbprint which was actually the best piece of information we could use to differentiate the expired and new certificate. The results of this command showed that the old wildcard certificate was still in use.
After that we ran the following PowerShell command in the ADFS server:
This command lists the details of the SSL certificates being used by the ADFS services (service communications, token-decrypting and token-signing). When checking the thumbprint of the service communications certificate that this command listed, it showed that the new wildcard certificate was actually being used for service communications.
What we did next was that we ran the following PowerShell command in the ADFS server:
And after that we restarted the ADFS windows service. This seemed to do the trick and now the STS service was back up and running again, this time fully utilizing the new wildcard certificate.
The lesson to learn from this: when deploying the new SSL certificate to be used for ADFS service, make sure that the all the relating services are actually using the certificate and there are no services that still uses the old one. The above two PowerShell commands are very useful in checking these. In more detail, it looks like the Set Service Communications Certificate command in the ADFS management console only updates the ADFS configuration database but not the HTTP.SYS. And as the Windows Server 2012 R2 version of the ADFS does not use IIS, there is no UI-based tool to set the SSL certificate binding. So the PowerShell command must be used for that.
At Cloudriven, we help organizations with their Dynamics 365 projects, so please feel free to contact us if you require any help!