I arrived to work this morning to find a stack of errors in BizTalk. They were from a HTTP Send Port.
Could not establish trust relationship for the SSL/TLS secure channel.
I immediately suspected that the certificate of the remote server had expired, so fired up IE to check the status - to my horror it was valid. Although suspiciously only by a day, so it had clearly been updated and something was now causing problems.
I figured that it was likely that BizTalk was doing some crazy caching, so restarted the related host instances. Indeed I found this blog on BizTalk caching SSL certs.
Annoyingly my issue persisted. I figured it might be an issue with Enterprise Single Sign On so restarted that - no joy, I even resorted to rebooting one of the application servers in my group, but it was still experiencing the same issue.
I needed more information on the SSL error as it all appeared valid to me. I found this post on Using System.Net trace to troubleshoot SSL problem. I added in the system.diagnostics markup to the BTSNTSvc64.exe.config file and restarted the relevant host. This helpfully presented me with this detail:
System.Net Information: 0 : [8800] SecureChannel#58698824 - Remote certificate has errors:
System.Net Information: 0 : [8800] SecureChannel#58698824 - Unknown error.
System.Net Information: 0 : [8800] SecureChannel#58698824 - Remote certificate was verified as invalid by the user.
It certainly seemed to be a certificate validation error, although to me everything looked valid. So I launched IE under the service account for BizTalk and went to the same URL. I was presented with an error:
Revocation information for the security certificate for this site is not available. Do you want to proceed?
And when viewing the certificate:
The certificate cannot be verified up to a trusted certification authority
I figured this would probably something to do with the root certificates not being updated correctly - strangely though only applying to the BizTalk service account and not my logon. True enough, the following error was in the Event Log:
A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.
Now I knew my clock was correct, but I couldn't figure out why the remote file would have an incorrect timestamp. I finally stumbled on the related Microsoft KB article, which pointed me towards a cache!
Damn caches!
Running a command prompt as the BizTalk service account I executed this command:
certutil -urlcache * delete
which resolved the issue and the error disappeared.