ADFS in 2012R2 – Replacing the Service Communications certificate

I’m not alone in this. Replacing the Service Communications certificate in ADFS under Server 2012R2 is an inconsistent experience to say the least. After a less than ideal run through of updating the cert on some test ADFS servers, I felt that I at least knew the pitfalls and could update the production ADFS servers without too much hassle.  Wrong.

What seems like it should be the obvious method to specify a different Service Communications certificiate, using the ADFS Management MMC, does not work reliably.  For one, you need to manually add permissions for the new cert’s private key.  NT Service\drs and NT Service\adfssrv need read access. The MMC does warn you of that, but that’s something that seems like an obvious oversight.  The installation adds those permissions, so why would the change then be manual?


Onto the problem. I found in both the Test and Prod setups that attempting to change the certificate in the MMC does not work.  The new cert is shown in the MMC, and even if queried with Get-AdfsCertificate, but the clients still see the old certificate. Several restarts of the ADFS service, and reboots of the server did not help.

On the Test server, I was able to use Set-AdfsCertificate, followed by another restart to have it start using the new cert.

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumbprint>

Made the assumption that this would be the same case for Prod.  It wasn’t. After running through those first steps, the new cert wasn’t in use and no amount of setting it to the new, back to the old, back to new was making a difference.

Finally came upon a number of posts where people mentioned having to manually bind the new cert using netsh.

netsh http delete sslcert hostnameport=<your hostname>:443
netsh http add sslcert hostnameport=<your hostname>:443 certhash=<your cert thumprint> appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices

same thing for localhost:443, and then <your hostname>:49443, but leave off the sslctlstorename for 49443.

Shoutouts to

Also to Interesting powershell script to check for issues with the cert bindings


Tags: ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: