]> BizTalk HTTPS SSL errors 🌐:aligrant.com

BizTalk HTTPS SSL errors

Alastair Grant | Wed 13 Jun 2012

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.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.