Bugs
0
Planned
Chris21 agent rejecting server certificate even when set to None: "remote certificate is invalid according to the validation procedure"
Adrian Corston 2 years ago
in UNIFYBroker/Frontier ichris/chris21
•
updated by Matthew Davis (Technical Product Manager) 2 years ago •
8
My customer is seeing this error, even though Handle Certificate Errors is set to "None":
Here's the config:
Port 80 without SSL works fine, with an otherwise identical configuration.
In case it's relevant, the connection to Chris21 is via a UNIFYConnect PortBridge tunnel on a non-standard IIS port number (444). It's not possible to use port 443 due to restrictions on the customer side.
Customer support service by UserEcho
Hi Adrian,
Based on my investigation, I can't see why setting the "Handle Certificate Errors" to None would still be running certificate validation, unless there are multiple agents configured against the same URL with conflicting certificate settings.
I suspect it may have something to do with TLS connectivity settings, as we've seen the same error reported previously when endpoints are using TLS 1.2. Do you happen to know what version of TLS the customer is hosting their Chris21 instance on?
Only one agent is configured. I will find out what TLS/SSL schannel protocols are supported (it's a very old server, running 2008 R2 :-( ).
Fantastic, thanks. The version of .NET that UNIFYBroker 5.x targets only has default support for earlier versions of SSL/TLS. There's ways to get newer versions running (like 1.2) if necessary.
Otherwise we may have to explore replicating outside of the UNIFYConnect environment (should be easy with PortBridge) to try and see if there is indeed something going on with the certificate validation.
Customer says:
We have client and server configured for SSL 2.0, TLSv1.1&1.2
More info:
SSL 2.0
TLS1.1
TLS1.2
Hi Adrian,
I was able to replicate the scenario locally with a (non-functional) version of Chris21 running over port bridge.
I found an edge scenario where the URL that the overridden certificate validation procedures are applied to, did not align to the URL for the outgoing call.
I've prepared (attached) a patch for this issue for reference. Let me know the UNIFYConnect environment this should apply to and I'll get lined up to deploy.
Unify.Framework.Communicator.Certificate.dll
Patch has been successful and connections are now working with now certificate validation error. Thank you!
However please note that I am now see another problem which may or may not be related to the patch. Please see https://voice.unifysolutions.net/en/communities/6/topics/4344-chris21-api-delays-and-timeouts for details. Probably not related, but I thought I should mention it just in case.
Patch is available above for 5.3 implementations.
Leaving ticket open to track fix against 6.0 release