ADFS Certificate Maintenance Part 1

Scenario

It seemed like a straightforward job – update the service communications certificate for an ADFS farm with web applications proxies in front of it but, somewhere along the line something went wrong. All servers were running Windows 2016 and ADFS was working in the equivalent of v3.0 mode and ADFS was being used for Office 365 authentication and for authentication to a number of hosted services in Azure. The service communications certificate, as is usual, utilises the SSL certificate and that had been replaced with a new certificate on all ADFS and web application proxy servers but any attempt to set this new certificate resulted in an error message implicating the keyspec value.

Diagnosis

The new certificate had been created from the same template that had been used previously. This template had included the correct values for ADFS usage in the [NewRequest] section, that is:

KeySpec = 1

which provides the necessary AT_KEYEXCHANGE attribute needed by an ADFS service communications certificate.

However, when checking the values in the new certificate using the command certutil –v –store my from an elevated command prompt indicated that the certificate had a keyspec of 0 instead of 1. The SSL certificate had been installed by importing the certificate from the certification authority into the Certificates MMC snap-in and then exporting it as a pfx file – with an exportable key – to allow it to be installed on the other servers. The installed certificates can be verified using PowerShell:

First, get the thumbprints for the existing certificates

cd Cert:\LocalMachine\My dir

That will give you a list of the installed certificates. Copy the thumbprint for the new certificate. On the ADFS server, then use:

Set-AdfsSslCertificate -Thumbprint thumbprint

On the web application proxy server, use:

Set-WebApplicationProxySslCertificate -Thumbprint thumbprint

Restart the ADFS services on the ADFS and web application proxy servers just to make sure and, lo and behold, the services restarted OK. So far so good. Note that despite using a new SSL certificate, the service communications certificate was still using the old, still valid, certificate so everything was still working as it should. Permissions on the new certificate and keys were checked and were correct for NT SERVICE\adfssrv.

So, the problem was how to change the keyspec value from 0 to 1 without having to go through the certificate issuance procedure again. That will be dealt with in Part 2