Because Active Directory Federation Services (AD FS) rely heavily on certificates, you’ll want the most straightforward certificates as the Service Communications Certificate throughout your Active Directory Federation Services (AD FS) implementation.
Notice however, that I’m not recommending to use the strongest certificates for your Active Directory Federation Services (AD FS) implementation… That’s right, you won’t hear me recommending to use certificates with 16384bits keylength and SHA-512 as the hashing algorithm.
Today, however, is on another property for the certificate used as the Service Communications Certificate in Active Directory Federation Services (AD FS) on Windows Server 2012 R2: the Private Key generation process.
Cryptographic New Generation
The reason for this blogpost today is that Active Directory Federation Services (AD FS), even its newest incarnation on Windows Server 2012 R2, does not support certificates with Cryptographic Next Generation (CNG) private keys. You will have to use certificates with key pairs generated by legacy Cryptographic Service Providers (CSPs).
Attempting to use a certificate with a Cryptographic Next Generation (CNG) private key as the Service Communications Certificate in Active Directory Federation Services (AD FS), results in an error message reading:
The certificate with the specified thumbprint <thumbprint> has a Cryptographic Next Generation (CNG) private key. The certificates with the CNG private key are not supported. Use a certificate based on a key pair generated by a legacy Cryptographic Service Provider.
So, how did we get here?
When you created the Certificate Request (CSR) in the Certificates for the Local Machine Microsoft Management Console Snap-in (certlm.msc), you choose All tasks > Advanced Operations > Create Custom Request instead of the All tasks > Request New Certificate menu option.
Then, instead of choosing the Active Directory Enrollment Policy you selected Proceed without enrollment policy option on the Select Certificate Enrollment Policy page. Of course, when the Certification Authority (CA) you want to issue the certificate is not your Enterprise Root or Enterprise subordinate Certification Authority, this is the right choice to make.
Then, on the Custom request you accepted the default value (No template) CNG key. The dropdown list for Template: however, alternatively offers the (No template) Legacy key option.
Concluding
When requesting a certificate for the Service Communications Certificate throughout your Active Directory Federation Services (AD FS) implementation, opt for a certificate with a legacy key pair.
Make sure you select the Legacy key template on domain-joined devices; it is not the default option.
Further reading
How to Determine if a Certificate is Using a CAPI1 or CNG key
ADFS Configuration Wizard Fails with Error “The certificates with the CNG private key are not supported”
Cryptography Next Generation
CNG Features
I know this post is two years old now, but I recently ran into this situation and am looking for the right way to handle this moving forward.
We have on-premise MS CRM while using ADFS for authentication. We use a wildcard certificate that can be used on both servers.
I recently bought a new certificate as the old one was expiring. I went with a less expensive provider (GeoTrust). Anyway, when I installed the certificate and got this error message. To get it to work, I had to have someone change the certificate somehow using openssl.
I don't want to have to go through this again, so is your post saying the only thing I have to do when I generate the CSR is to choose the "(No template) Legacy Key" option? If so, will the cert be generated correctly from the provider?
Thanks!
Hi Mike,
I do not have sufficient details to provide a clear yes/no.
However, it sure sounds like it.
Hi
My query is below.
There is one application integrated with ADFS, sometimes not getting updated whenever the ADFS metadata changed.
Every time we need to provide the ADFS new metadata and application side needs to install new metadata.
When will the ADFS metadata change? (Everyday or Any lifecycle there).
What is the solution to resolve this application issue with ADFS metadata?
Please clarify my doubts.
Hi Sibi,
The AD FS Metadata changes every time you make a change that changes the configuration of the AD FS Farm to the outside world. Examples of these changes are you change the available claim types and (one of) the three certificates in use by AD FS. Changes in claim types typically won't break existing applications, but changing certificates would. When certificates are automatically rolled over (like the case with the token-signing and token-decryption certificates, by default) the federation metadata changes 14 days in advance of the date you see as the expiration date for the certificate(s) in the AD FS management console (or using the Get-ADFSProperties Windows PowerShell Cmdlet).
Most applications and cloud services support automatic metadata monitoring. However, most don't. Applications you configure manually in AD FS, by default, don't.
To avoid problems, add AD FS relying party trusts ("applications") using the federation metadata location of the cloud provider or the application. Another good idea is to use a webpage monitoring solution like Versionista to alert you of changes in the federation metadata file of your AD FS implementation.