AD FS Error on Startup indicating no access to Private Keys (Event ID 133)

As part of my “summer project”, a new lab environment for testing and learning, I came across a rather hard to figure out kind of issue. It turns out that AD FS in Windows Server 2012 doesn’t function properly with CNG Certificates (Cryptography Next Generation). I won’t go into details about certificates and cryptography in this post, but I think this might be worth sharing.

The Setup

I was configuring a newly installed Active Directory Federation Services (AD FS). Everything was running fine, the environment was functional. I already had a fully functional Active Directory Certificate Services (AD CS) Enterprise type installation deployed and thought I’d replace those self-signed certificates (token signing and token decrypting) with proper ones from my own internal CA. I had customized a Web Server Template and already used it successfully with other services in my lab environment. AD FS can use the same server certificate to secure communications and to sign and decrypt tokens.

I enrolled for one, installed it, gave the proper permissions to its’ private keys, but…

The Issues

…once I did this, the problems started and AD FS won’t start. Event Logs showed errors with Event ID 133 like the one below.

Log Name: AD FS/Admin
Source: AD FS
Date: 10.7.2013 23:06:20
Event ID: 133
Task Category: None
Level: Error
Keywords: AD FS
During processing of the Federation Service configuration, the element 'signingToken' was found to have invalid data. The private key for the certificate that was configured could not be accessed. The following are the values of the certificate:
Element: signingToken
Thumbprint: xxx
storeName: My
storeLocation: 0
Federation Service identity: xxx\xxx

The Federation Service will not be able to start until this configuration element is corrected.

This condition can occur when the certificate is found in the specified store but there is a problem accessing the certificate's private key. Common causes for this condition include the following:
(1) The certificate was installed from a source that did not include the private key, such as a .cer or .p7b file.
(2) The certificate's private key was imported (for example, from a .pfx file) into a store that is different from the store specified above.
(3) The certificate was generated as part of a certificate request that did not specify the "Machine Key" option.
(4) The Federation Service identity 'xxx\xxxxxx' has not been granted read access to the certificate's private key.

User Action
If the certificate was imported from a source with no private key, choose a certificate that does have a private key, or import the certificate again from a source that includes the private key (for example, a .pfx file).

If the certificate was imported in a user context, verify that the store specified above matches the store the certificate was imported into.

If the certificate was generated by a certificate request that did not specify the "Machine Key" option and the key is marked as exportable, export the certificate with a private key from the user store to a .pfx file and import it again directly into the store specified in the configuration file. If the key is not marked as exportable, request a new certificate using the "Machine Key" option.

If the Federation Service identity has not been granted read access to the certificate's private key, correct this condition using the Certificates snap-in.

As the error message says, it seems that the AD FS service account doesn’t have access to the certificates private key. In my case, it most certainly did. After some research and following to this TechNet Article I checked all those issues concering Event ID 133 (also mentioned in the event itself), but with no luck.

The “Solution” or Cause of the Issue

After checking that everything was setup correctly and eliminating those possible reasons I turned to the certificate itself, what’s wrong with it. I enrolled for a new certificate only this time using the default Web Server Template that comes in the box with AD CS. And boom, this time it worked, no errors or even warnings this time.

Time to start narrowing the differences in my custom certificate template. One by one it came down to the Cryptography Provider Category. I had chosen the new Key Storage Provider, which provides those all new CNG Certificates. CNG Certificates can use for example ECC (elliptic curve cryptography) and some “old” services and applications (like AD FS in this case :)) can’t use them. CNG Certificates have been around for almost 6 years now as they first came available in the Vista generation (Windows Vista & Windows Server 2008). See screenshots below for the details.

The “Legacy” one that works

adfs cert default

The all new that doesn’t work

adfs cert crypto not working

Once I issued the certificate using “Legacy Cryptographic Service Provider“, AD FS started to function properly. Someone who knows cryptography in more detail can probably explain better why this is so.

Summing it up

AD FS in Windows Server 2012 doesn’t know how to handle CNG Certificates, so don’t use them. If you are issuing your certificates yourself with an internal CA, do not use “Microsoft Software Key Storage Provider”, use “Legacy Cryptographic Service Provider” instead. In production environments however, these certificates should probably be requested from a public CA, but anyways, this stuff still applies.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please, do the math and help fight spam * Time limit is exhausted. Please reload the CAPTCHA.