jump to navigation

Barracuda WAF and intermediate certificates October 4, 2010

Posted by jamesisaac in Uncategorized.
Tags: ,

We purchased a Barracuda Web Application Firewall in order to protect our web servers from layer 7 attacks (SQL injection attacks, cross-site-scripting, etc.). The WAF works just like a network firewall in that you define an inside server (the “real” server), an outside ip address that it will respond to (the “virtual ip”), and the WAF then receives all traffic to that public ip, inspects it, and passes it along to the inside server.

The head-scratching question that I had during my research was this: if the inside server is presenting an SSL service, how does the WAF inspect the traffic? The answer is pretty straightforward: you move the certificate from the server to the WAF. It then unpacks the encrypted packets, inspects them, and forwards them to the server. You can specify whether you want to forward the traffic encrypted, in which case the WAF re-encrypts the packet and sends it to the server, or unencrypted (on port 80). Doing this reduces the load on the server since it doesn’t have to decrypt and encrypt the packets, but it does expose the traffic to your internal network in an unencrypted state.

Straightforward, I said, right? Well, yes. Except for the parts which aren’t straightforward, which is nearly everything in this case.

The Barracuda WAF accepts certificates in .PEM format, which our third-party CA doesn’t provide. There’s some documentation on how to get the certificate from your server, but it’s none too clear. In our case, we are using IIS, so I went to the IIS Admin applet and exported the certificate. It exports in a .pfx format, which can’t be read directly by the Barracuda WAF. You need to use OpenSSL to change the format of the key from .pkx to .pem, and also to extract a non-encrypted key-only version as the two go together. This isn’t listed in the documentation, by the way, only some serious Google-mojo turned up the interesting documents. Here’s Scott Lowe’s documentation on how to do it; you should end up with a .pem file containing the cert itself and then a .key file containing the key.

Now upload the certificate into the Barracuda, create the https service, and away we go, right? No. Because earlier this year Thawte (as well as most other CA’s) changed from having a single root certificate to using a chain of intermediary certificates. This improves security so I guess it’s a good thing. But it does make installing the certificate more difficult. The Barracuda WAF includes a browse-box selector for intermediate certificates, so I went to Thawte’s root certificate page and downloaded the relevant certs and included them. No dice. The client browser claims that the certificate is untrusted because the entire chain isn’t listed.

By the way, here’s a really good site to test your certificates after they are installed on your server; it provided some helpful error messages in my troubleshooting.

Finally, after more Google-mojo, I stumbled upon the answer: a certificate bundle. Unlike Matt’s problem which he detailed on the Standalone Sysadmin (great blog, by the way), I actually had the reverse problem – the individual intermediate certs didn’t work, and only the bundle saved me. Where to find it? Back to Thawte’s knowledgebase, and I downloaded the bundle listed for Apache. Then back to the Barracuda WAF, upload, and… yes! Verified!

It seems to me that this whole process should be much, much easier to deal with, but right now there are too many standards and formats and methods. Hopefully this will help anyone else with a Barracuda Web Application Firewall who is stymied, like I was, and is looking for some assistance.