We use cookies on our website to ensure we provide you with the best experience on our website. By using our website, you agree to the use of cookies for analytics and personalized content.This website uses cookies. More Information
It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda NextGen Firewall X

Secure Web Proxy problem with 'Client Certificate' based authentication

  • Type: Knowledgebase
  • Date changed: 5 months ago
Solution #00005265 
 
Scope:
This solution replies to:
- NG Firewall firmware versions 4.2.x, 5.0.x, 5.2.x
- netfence firmware versions 4.2.x

 
Symptoms:

If a webserver is configured to use client certificates as authentication procedure, the ssl handshake from the secure web proxy to the webserver fails and therefore a connection can not be established.


 

Solution:

The secure web proxy breaks open the initial request from the client and the ssl handshake request to the webserver. This means that the handshake request to and the reply from the webserver is not going to be tunneld. After that, the proxy sends a re-negotiate request to the server in order to initiate a new ssl handshake which should have the affect that all traffic arriving from the client gets tunneld through the proxy.

Unfortunately some webservers like special versions of apache can not deal with a 're-negotiate' request.This leads to a never ending ssl handshake procedure and a connection to the server won't be established.

 

Configure these affected web sites in the SSL Exceptions Tunnellist configuration entity on the secure web proxy. The first ssl handshake is not broken open but gets tunneld in the first place to the webserver.

 

 

Note:
A virus scan is not possible with entries configured in the tunnellist.

 

 

Link to This Page:
https://campus.barracuda.com/solution/50160000000IKawAAG