ADFS CRL Check Issues

2017-12-01T11:26:45+00:00 March 23rd, 2015|Azure|

Recently on a customer we had issue come in, where there ADFS had completely broken and no authentication requests via ADFS were working at all.

When speaking to the customer they had advised that they had made no changes to ADFS at all and were confused why all of a sudden the issue occurred. We checked out the event viewer on the ADFS server, under the ADFS Log (Under Applications and Services) and found it was bombarded with the same event, Event ID “364” please see below.

 

Exception details:

Microsoft.IdentityServer.AuthenticationFailedException: MSIS3014: The encryption certificate of the relying party trust ‘https://test.test.com/’ identified by thumbprint ‘1AB2C3D4E5F6’ is not valid. It might indicate that the certificate has been revoked, has expired, or that the certificate chain is not trusted

 

We also spotted the below error (Event ID 317):

An error occurred during an attempt to build the certificate chain for the relying party trust ‘https://test.test.com/’ certificate identified by thumbprint ‘1AB2C3D4E5F6’. Possible causes are that the certificate has been revoked, the certificate chain could not be verified as specified by the relying party trust’s encryption certificate revocation settings or certificate is not within its validity period.

 

You can use Windows PowerShell commands for AD FS to configure the revocation settings for the relying party encryption certificate.

Relying party trust’s encryption certificate revocation settings: CheckChainExcludeRoot

The following errors occurred while building the certificate chain:

The revocation function was unable to check revocation for the certificate.

 

The revocation function was unable to check revocation because the revocation server was offline.

 

 

User Action:

Ensure that the relying party trust’s encryption certificate is valid and has not been revoked.

Ensure that AD FS can access the certificate revocation list if the revocation setting does not specify “none” or a “cache only” setting.

Verify your proxy server setting. For more information about how to verify your proxy server setting, see the AD FS Troubleshooting Guide

From the events it looked like that the certificate CRL check was failing, so we took a look at the proxy settings on the machine (command is “Netsh Winhttp Show Proxy“)

We then asked the customer to confirm if the proxy was correct and that the ADFS machine was able to access the CRL’s externally. This is when it clicked for the customer, it turns out that they had a firewall migration and that the Proxy specified no longer existed, so we just had to run “Netsh winhttp reset proxy” to get rid of the proxy and as soon as we restarted the ADFS service everything kicked back into life J