Watchguard HTTPs DPI mini howto with internal CA and certificate deployment with Active Directory
a mini-how to for an https dpi with corporate internal ca and watchguard xtm devices and how to deploy the certificate using active directory for internet explorer users.
The biggest pain about DPI over HTTPS traffic is the end-user experience. Whenever a user tries to access a site using Internet Explorer they will get an error about invalid certificate. Here Internet Explorer and Group Policies comes handy to the Sysadmin.
This short howto wants to be an easy handbook for building a custom SSL certificate for the Organization, importing it into the Watchguard firewall and deploying the certificate using Group Policies to avoid users getting the error message and, instead, seeing a valid certificate in Internet Explorer.
To achieve this goal I've been using:
- OpenSSL in a Linux Box
- Watchguard Firebox Manager
- Group Policy Management Console
Creating the SSL Certificate
The XTM box uses a built-in private key to re-sign SSL traffic to be sent to the clients. If not present, the device creates a new one at the following reboot, signed by the device itself. So, I'll create my own CA certificate with a Private Key (used to sign the traffic). Therefore I will run on the Linux Box:
[root@rhdev ~]# openssl genrsa -des3 -out myorg-ca.key 2048
Generating RSA private key, 2048 bit long modulus
..+++
...................+++
e is 65537 (0x10001)
Enter pass phrase for myorg-ca.key:
Verifying - Enter pass phrase for myorg-ca.key:
Once the Private Key is ready (you should store your passkey somewhere safe) you can build the certificate itself.
[root@rhdev ~]# openssl req -new -x509 -days 3650 -key myorg-ca.key -out myca-cert.cer
Enter pass phrase for myorg-ca.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:IT
State or Province Name (full name) []:MI
Locality Name (eg, city) [Default City]:Milan
Organization Name (eg, company) [Default Company Ltd]:En3pYlabs
Organizational Unit Name (eg, section) []:Security Dept.
Common Name (eg, your name or your server's hostname) []:En3pY CA
Email Address []:
With versions 11.5.1 and 11.5.2 of the FSM I found out a little bug about certificate import process, the correct one (as in it is the one that works without issues) was:
- Copy the content of the two files created above into a single text file on your windows box, select all and copy it into the clipboard
- Open Firebox System Manager of your XTM
- Click on View >> Certificates
- Click on the "Import Certificate / CRL" button at the bottom of the window. A new dialog box appears.
- Choose "Proxy Authority (for deep packet inspection)"
- Click on the "Paste" button: it has to ask you for the Private Key passphrase (if it doesn't, make sure the private key is in your clipboard)
- Click on the "Import Certificate" button
You should see your certificate in the list and marked as "Proxy Authority" certificate. Now I would suggest a reboot of the device, to make sure the certificate is correctly kept in the Certificate store on your Device. If it doesn't appear, just redo the above.
Now, if you create an HTTPS proxy policy you should be able to navigate on the Net but always with a certificate error. If you open the certificate properties it should be your CA signing the SSL traffic.
Deploying the certificate
Now it's time to deploy your certificate in Active Directory. Open any domain controller in your forest, domain, or site, or any server with an equivalent snap-in. On small organizations I tend to deploy the certificate using the Default Domain Policy, so you should open for editing this Group Policy. Navigate through Computer Settings, Windows Settings, Security Settings, Publick Key Policies and finally Trusted Root Certification Authorities.
Right click on the right pane and choose "Import" and navigate to get your "myca-cert.cer" file. You do not really need the Private Key in here. (You should also be sure the file has Windows end of line termination and not Unix). Once imported you should see your certificate (trusted) in your right pane.
The best thing at this point is rebooting the PC to be sure the Group Policy is correctly applied. Once done, in the Certificates Snap-In you should see your own CA within the Trusted Root CAs, and when navigating on the Net you should have no more certificates errors while opening SSL websites.
Got a PFX CA and can't import it?
You may have a certificate set created and compressed in one PFX file. Unlike some people I met name it "another Microsoft crap" the PFX file format is a well known standard. You can easily export your private key and certificate from it using OpenSSL. Say you have yourcertificate.pfx file, you will use the following:
- openssl pkcs12 -nokeys -in yourcertificate.pfx -out yourcacert.crt
- openssl pkcs12 -nocerts -in yourcertificate.pfx -out yourcakey.pem
The first command will export your certificate in DER format, while the second will build the private key file. Copy all into one text file and Paste it (with above mentioned procedure) in your Watchguard device to make it correctly work.
Disclaimer
Working with HTTPS DPI may lead to Privacy issues in your country. You should be aware about working with DPI and surf control of your users before enabling these functions. Follow best practices for Certificates Management to keep your information secure and confidential. This entry is a proof concept for a quick deployment of Certificates within a Watchguard protected environment and Active Directory. Other browsers than Internet Explorer will need to be manually allowed to transparently allow the certificate validation (or other scripts not mentioned here).
Also please note that using HTTPS DPI will stop some applications from working. For further reference please take a look to more my blogs about HTTPS DPI for further information.
23/03/2012 00:00:00