ADFS CNG Certificates

For those of you that deal with Active Directory Federation Services regularly, you’re probably aware that ADFS does not now and has not ever supported Cryptography Next Generation (CNG) certificates. ADFS 3.0 is EXCEPTIONALLY sensitive about this, and won’t even install if any of the certificate you are using are using CNG keys, and you’ll end up with the following lovely error:

Install-AdfsFarm : The certificate with the specified thumbprint <REDACTED>; has a Cryptography
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.
At line:1 char:1
+ Install-AdfsFarm `
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-AdfsFarm], DisplayableArgumentException
+ FullyQualifiedErrorId : PrerequisiteTest,Microsoft.IdentityServer.Deployment.Commands.InstallFarmCommand

I’ve yet to find a satisfactory reason for why ADFS doesn’t support CNG. this seems to be a totally arbitrary limitation. CNG is a drop-in replacement for the CryptoAPI libraries, assuming you ignore the Suite B Algorithms, two of which are known to be insecure, and the other two that are not in wide usage yet. UPDATE: Turns out this issue is actually to do with the Cryptographic Storage Providers in use to store the private part, not the cryptographic algorithms in use.

In enterprise CAs, where you see this most commonly, it’s actually to do with upgrading a certificate template to version 3 without specifying the legacy CSP, so the template is upgraded to the CNG KSP. 

In public certificates, it’s just a function of how later versions of windows create requests and import certificates, and the Firefox trick below holds. More details at the bottom.

Fortunately, there is an easy fix for this:

1. Export the key pair to a PFX file
2. Remove the original certificate from the computer’s certificate store.
3. Go get Firefox, and install it.
4. Import the problem certificate into firefox as a Personal Certificate (here’s a good example from UT Austin)
5. Export that certificate from firefox as a P12 file (example from Comodo)
6. Import the modified cert back into the Computer’s Certificate Store (example of both backup and restore from Digicert). The modified certificate should then work as expected.

The technical reason behind this is that Firefox, like Mozilla before it, uses it’s own certificate management system, not Microsoft’s certificate store. It’s implementation is compatible with the standards, but does not preserve the Microsoft specific properties signifying a CNG certificate. When the exported certificate is re-imported, as long as it matches the older CryptoAPI limitations, it’s imported as a CryptoAPI certificate, and works correctly with ADFS.

Bearing that in mind; If you actually did generate an AES or SHA2 certificate, then this process won’t help you. Your certificate actually won’t support CryptoAPI, and you’ll need to wait for Microsoft to fix ADFS for CNG. UPDATE: see below.

I ran into this fix on Thomas Torggler’s blogpost on this problem with TMG and Lync certs, where Lync supports the cert, but TMG complains. His fix holds for ADFS certificates that are generated with a CNG key, but I had such a tough time finding it that I felt obligated to repost this solution with relevant search terms.

Also, turns out Lync has this issue too, as Richard Brynteson discovered when he got “The Buffer Supplied To a Function Was Too Small.” when trying to import certs for a front end pool.

Further, I’ve run into this issue on SCCM as well. Turns out SCCM doesn’t support CNG providers either. Ondrej Sevecek covers some of the issues you’ll see if either the client or distribution point certificates are in the unsupported providers. 

Finally, Suite-b algorithms are creeping into common usage, but Microsoft still hasn’t addressed these incompatibilities. However, the “Microsoft Enhanced RSA and AES Cryptographic Provider” is a legacy CryptoAPI provider that supports modern cryptographic functions like SHA512 and AES256, but not the elliptical curve algorithms. seems like the status quo is going to be an ongoing issue for a while yet to come.