One of our customers reported being unable to login to their CRM instance today, simply getting an error from ADFS. We took a look and checked a couple of other relying party trusts published on the ADFS to which we got the same error. So after looking at the event logs there were a number of stack traces detailing the errors:


 

More interestingly we found:


 

This one mentioned the certificate revocation check setting: “CheckChainExcludeRoot” and mentioned using some powershell to see what ours was set to, so we hopped on it:

Add-PSSnapin Microsoft.ADFS.PowerShell (Import-Module ADFS – if using Win2k12 R2)  

Get-ADFSRelyingPartTrust | Where {$_.Name –eq <name>}

This one showed that we were indeed set to “CheckChainExcludeRoot” so to test if it was this causing the issue we ran:

Set-ADFSRelyingPartyTrust -TargetName <name> -EncryptionCertificateRevocationCheck None 

That did the trick, so we knew why it was breaking – but what was blocking it? Seems that our firewall had been set to allow *.globalsign.com (ours was a globalsign cert) but after checking the details on the certificate which had recently been renewed it seems they have moved to use a CRL url of gloablsign.net – after adding the *.globalsign.net exception to our firewall all started working again and we set the EncryptionCertificateRevovcationCheck setting back to “CheckChainExcludeRoot”.

Hope it helps!

About the author