ADFS Certificate Maintenance Part 2

The solution

Some research indicated that the process of exporting the certificate to a pfx file and reimporting the file would do the trick but that clearly hadn’t worked in this case. Likewise, using a procedure from an article on the Microsoft website that suggested that using certutil -importpfx also failed as it would appear to be unsupported on Windows 2016.

The Microsoft document that referenced the use of certutil -importpfx did at least give hope that it was possible to change the keyspec value and, with some vague memory of doing something like this before, it was back to basics time which meant using the Windows version of the openssl utility.

The plan was therefore to export the key from the existing pfx file and then export the certificate. These would be recombined into a new PFX file and this would be re-imported into the ADFS and web application proxy servers. If the keyspec value was now 1 – as it to be for use as a service communications certificate – then the new certificate could then be used as a service communications certificate

First, we break apart the orginal PFX file (adfscert.pfx in this example),

openssl pkcs12 -in c:\temp\adfscert.pfx -out c:\temp\newadfscertkey.pem -nocerts openssl pkcs12 -in c:\temp\adfscert.pfx -out c:\temp\newadfscert.crt -nokeys

Then merge them back into a PFX file

openssl pkcs12 -export -in newadfscert.crt -inkey newadfscertkey.pem -out mergedadfscert.pfx

Next, import the merged PFX certificate into the certificate store on the ADFS and web application proxy servers.

1. Use the set-adfssslcertificate PowerShell command as before to update the SSL certificate used by ADFS
2. Use the set-adfssslcertificate PowerShell command as before to update the SSL certificate used by ADFS
3. Restart the ADFS services on the ADFS and web application proxy servers to ensure that the change has applied

Now you will be able to change the service communications certificate. It was unclear why the returned certificate had a keyspec of 0 instead of 1 and the only change from the old certificate was the use of a different certification authority. My guess would be that someone ticked the wrong box when the certificate request as submitted. Nevertheless, the problem was resolved, and the customer could use their ADFS for another 2 years.

ADFS Certificate Maintenance Part 1 A funny thing happened on the way to changing the ADFS service communications certificate

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