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 Web Security Gateway

SSL Inspection and Certifications on the Barracuda Web Filter.

  • Type: Knowledgebase
  • Date changed: 4 years ago
Solution #00007070 

Scope:
All Barracuda Web Filters, all firmware versions.

Answer:

When the Barracuda Web Filter intercepts an SSL session, it creates two SSL tunnels: one between the client and Barracuda Web Filter and another between the Barracuda Web Filter and the remote server. Since the Barracuda Web Filter is the endpoint for the client SSL session, it needs to present an SSL certificate to the client that the client will accept AND that the Barracuda Web Filter can use to decode the traffic so it can inspect the data. In order to accomplish this, the Barracuda Web Filter will act as a Certificate Authority and creates a signed server certificate for that domain.”
For example, if the client is trying to connect to https://www.example.com, the Barracuda Web Filter will present the client with a certificate that states the Barracuda Web Filter has issued the certificate to www.example.com. If the client browser does not trust the Barracuda Web Filter to be an issuer of certificates, or if the Barracuda Web Filter's certificate doesn't have the right attributes that denote it as an issuer, the browser will show an error to the end user indicating an SSL handshake issue. Some browsers, such as Chrome, are very security-conscious, and will return an error to the user if any part of this transaction is not performed exactly right and will sever the connection, where FireFox provides the ability to let the user override this behavior and manually accept the certificate.
 
Please note that a public Root CA such as VeriSign will not provide you with a subordinate certificate, they will only provide you with a server certificate, which cannot be used to issue other certificates. The reason for this is that with a subordinate CA certificate, you could use that to issue SSL certificates for any site you wanted to, and since VeriSign gave you the certificate, they would be stating that they trusted you to issue SSL certificates to anybody you wanted to. They would not do this, simply because of the possibility that you could issue SSL certificates to "bad" websites and VeriSign would be seen as trusting those sites, even though they have no knowledge of that site. Another possibility exists where you could use that certificate to intercept SSL for any user anywhere; since almost every web browser in the world trusts VeriSign, you could intercept all users' traffic and have access to all of their previously encrypted data. Instead, you can use a local CA program to act as a Root Certificate Authority, and use that to generate a subordinate certificate, such as with Microsoft PKI server. As long as your clients trust that local root, you could install any subordinate certificate generated by that root and use it for SSL interception on the Barracuda Web Filter. If your clients do not trust that root CA, they will get errors when browsing which indicate that the SSL certificate is signed by an "untrusted issuer."
 
A self-signed certificate on the Barracuda Web Filter can also be used for SSL interception without the need to retrieve a certificate from a root CA, but would need to be installed in the browser as a Trusted Root Certification Authority.
 
Link To This Page:
https://campus.barracuda.com/solution/50160000000uHekAAE