Unable to log in to SSL Visibility WebUI after upgrading to version 3.11.1.1

book

Article ID: 169288

calendar_today

Updated On:

Products

SSL Visibility Appliance Software

Issue/Introduction

After upgrading the SSLV to version 3.11.1.1 some customers may find that they are unable to establish a connection to the WebUI if using a Fully Qualified Domain Name (FQDN), but when using the appliance's IP address the connection works.

There could also be issues encountered when connecting to the SSLV using the IP when the destination address has been natted.


 

Cause

This change in behavior was introduced with bug fix "SSLV-2695 - Addresses a potential DNS rebinding vulnerability".

When logging into the SSL Visibility WebUI using the appliance's FQDN, it is now a requirement that the hostname or IP configured on the appliance match the HTTP host header sent from the client. The SSLV now verifies if the host header matches the hostname, or if there is no hostname that the IP address matches what is configured on the appliance.

Example:
If you are trying to connect to https://sslv-appliance.internal.lab but the hostname configured on the SSLV is sslv-appliance there will be a mismatch and the connection will fail.
If you are trying to connect to https://4.3.2.1 but the destination IP has been natted to 1.2.3.4, which is configured on the appliance, there will be a mismatch and the connection will fail. 


The following message could be displayed in the browser.

Firefox: "Secure Connection Failed"
Internet Explorer: "This page can't be displayed"
Chrome: "ERR_EMPTY_RESPONSE"


 

Resolution

To resolve this issue log into the SSL Visibility WebUI using the appliance IP address, for example, https://1.2.3.4. Click on the hostname in the upper right hand side of the WebUI and select "Management Network".

User-added image  
Modify the Hostname to match the FQDN. Once completed, Apply the changes and reboot the SSL Visibility appliance.

User-added image

If the destination IP has been natted this will not work. The only solution at this point would be to remove the NAT or connect to the SSLV locally and configure a FQDN.
 

Attachments