"ssl host name mismatch" SSL error accessing secure sites
Article ID: 276943
Updated On:
Products
Issue/Introduction
Users accessing internet services via Cloud SWG using Proxy forward access method.
Edge Proxy setup to forward all HTTP/HTTPS traffic on TCP 8080, 8443 and 8084 as per the documentation.
Edge Proxy setup to forward client IP address, username and groups within custom X-* headers as per the documentation.
Certificate validation is enabled on both Edge and Cloud Proxy servers in SSL access layer.
SSL interception enabled on Cloud Proxy.
When users access any secure Web site and the traffic is sent into Cloud SWG over TCP 8080, the following error is reported:
"ssl host name mismatch"
Environment
Cloud SWG.
Proxy Forwarding.
Certificate validation revocation checks performed on both Edge and Cloud Proxy servers.
UPE configured Cloud SWG tenant.
Cause
OCSP validation on the Edge Proxy generating a NON explicit request into Cloud Proxy that is setup to handle explicit requests.
Resolution
DIsable certificate validation checking on either the Edge Proxy or the Cloud Proxy, and do not do OCSP validation on both platforms.
If this is a security concern, a more granular solution where we only disable server cert validation for http service type in a ssl access layer policy can be pushed out.
Additional Information
When SSL interception is enabled on the CLoud Proxy, the emulated certificate sent to the downstream host (Edge Proxy) has no revocation information in the certificate, but the root certificates do.
When OCSP validation is performed on the Edge Proxy, it must validate all certificates in the chain including the intermediate/root certificates. Seeing a reference (AIA attribute from intermediate certificate in our case) to an an OCSP server, the Edge proxy generates the OCSP request to the defined OCSP host and expects to receive a successful response. These OCSP validation requests are typically over HTTP and hence go to TCP 8443 on Cloud Proxy.
In our case, the successful OCSP response did not come back over TCP 8443, resulting in the SSL error reported.
Looking at the request in more detail, we see that this HTTP request is not explicit in nature but transparent - an explicit request would include the username and path in the POST request as shown below:
Feedback
