TechNote. Contents. Overview. Using a Windows Enterprise Root CA with DPI-SSL. Network Security

(1)

Network Security

Using a Windows Enterprise Root CA with DPI-SSL

TechNote

Overview

Using a Microsoft Windows 2003/2008 Server Root Certificate Authority (CA) can ease the burden of rolling out certificate trust for Deep Packet Inspection of a Secure Socket Layer (DPI-SSL). The purpose of this tech note is to cover some of the common configuration mistakes and to illustrate the correct process for configuring DPI-SSL. Windows domain members automatically inherit the public certificate of their Enterprise Root CA and trust the Windows Server Root CA as a Trusted Root Certificate Authority. This means the Windows Server Root CA certificate is installed in the Windows Root Certificate Store of all domain members. Subsequently, this certificate is then trusted by Internet Explorer. Other browsers and operating systems, e.g. Firefox, use their own root certificate store, and require alternative means of importing the Windows Root CA certificate into the respective certificate store. Managing a Public Key Infrastructure (PKI) and certificate roll out fall outside the scope of this article.

An internal CA is used to sign certificates for various SSL applications that are meant for internal consumption. SonicOS supports importing both public and private certificates, as well as generating CSRs. It is important to understand the difference between a private and public certificate. The private certificate is the only one that has the ability to resign certificates for DPI-SSL.

Demonstated below is a typical deployment for a firewall that uses a custom certificate for HTTPS firewall management. Notice that the public CA certificate is imported into SonicOS as a CA certificate. A new signing request was then generated to create a certificate for HTTPS management. This allows you to replace the self-signed certificate with a certificate that can be trusted.

(2)

TechNote

Note: None of the above certificates can be used for DPI-SSL, because it is essentially a Man-in-the-Middle

(MITM) transparent proxy and it requires the ability to resign other public certificates using a private root certificate. This is only made possible when using a “Private” CA certificate.

Deployment Considerations

Some platforms, e.g. certain versions of Android, and specific applications can pose challenges for adding an additional Root CA trust. Certain applications that leverage SSL may not make calls to the trusted root certificate store on the underlying operating system. If the application does not provide an apparatus for installing additional Root CAs, determine if that application should be excluded from DPI-SSL, or if other steps can be taken. As a recommendation, before DPI-SSL is implemented, a complete audit should be performed to identify all platforms and the steps needed to import a Root CA certificate into the respective system.

(3)

TechNote

Configuration Procedures

Configuring client side DPI-SSL is an easy process. Simply select the correct Private Root CA as the resigning authority and enable the desired security services. In the following screen shots, the DPI-SSL certificate selection drop-down presents the built-in DPI-SSL certificate and other public certificates.

Note: You must not use the Public Windows Root CA certificate for DPI-SSL. Using the public certificate is the

most common mistake in configuring DPI-SSL. If the public certificate is used, every SSL service or HTTPS website will result in certificate error warnings and/or failed communications.

This section details the following configuration procedures:

Importing the Public CA Certificate for Trust ... 3

Importing the Private Root CA Certificate for DPI-SSL ... 5

Adding Additional Rood CAs... 10

Importing Certificates into Alternative Browsers and Operating Systems ... 11

Installing a Root Certificate into a FireFox Browser ... 11

Installing a Certificate into an Apple’s Safar Browser ... 12

Troubleshooting Common Configuration Mistakes ... 15

Importing the Public CA Certificate for Trust

It is necessary to import the Public Root CA certificate into the Certificate Store of SonicOS appliance before the firewall can trust any certificates signed by a Windows CA.

1. Navigate to the Windows Server.

(4)

TechNote

3. Click the Download CA certificate link.

4. Navigate to the SonicWALL Management Interface

5. Click the Import a CA certificate from a PKCS#7 (.p7b), PEM (.pem), or DER (.der or .cer) encoded file checkbox.

6. Click the Browse button, then select the file downloaded in step 3. 7. Click the Import button.

(5)

TechNote

Importing the Private Root CA Certificate for DPI-SSL

It is necessary to export the Private Windows Root CA certificate and subsequently import that certificate into the SonicOS appliance for DPI-SSL resigning.

Note: Use the following Microsoft technet article for specific guidance: http://technet.microsoft.com/en-us/library/cc754329.aspx

1. Open an MMC to export certificates for the local computer. 2. Click the Yes, export the private key checkbox.

(6)

TechNote

4. Select the private key certificate as a “.pfx” file. 5. Click the Next button.

(7)

TechNote

6. Select the desired certificate.

(8)

TechNote

7. In the SonicOS Management Interface, import the PFX file as a local end-user certifcate.

(9)

TechNote

8. For client side DPI-SSL, select Root CA Private Cert from the Certificate drop-down list.

9. Test DPI-SSL by navigating to an HTTPS website. The web site should load without any certificate warning messages.

10. Click on the certificate field in the browser to display details on the certificate. The root certificate is the Windows Root CA.

(10)

TechNote

Adding Additional Root CAs

It may be necessary to add additional external 3rd party Root CAs for certificate trust to be established with DPI-SSL. The SonicOS Certificate store is essentially the trusted Root Certificate store for DPI-DPI-SSL. In other words, if a CA certificate is not in the SonicOS Certificate store, DPI-SSL does not resign certificates (there by adding trust) for entities that are not trusted. SSL inspection still occurs, but the website in question would appear as if it had a self-signed certificate.

For example, as of SonicOS 5.8.1, the StartCom CA is not installed by default. If a user behind DPI-SSL navigates to an HTTPS website using a StartCom signed certificate, it would appear as if the site was using a self-signed certificate.

1. Download and import the StartCom CA, then restart the SonicOS.

Browser certificate warnings will no longer display for sites using the StartCom CA.

Public CA certificates can be found in many places: vendor websites, web browser certificate stores, and certificate stores on an operating system.

(11)

TechNote

Importing Certificates into Alternative Browsers and Operating Systems

For non-Windows based machines and browsers other than Internet Explorer, other techniques are required to import the Windows Root CA public certificate into their respective trusted certificate authority store. PKI and certificate management can be a complex matter. The following are a few examples of how to import Root Certificates into different browsers:

Note: Most browsers support manual certificate imports.

Installing a Root Certificate into a FireFox Browser 1. Open the FireFox browser.

2. Navigate to the Options > Advanced tab. 3. Click the View Certificates button. 4. Click the Import button.

(12)

TechNote

5. Make the certificated trusted as follows:

6. Click the OK button.

Note: For a more automated deployment, refer to the following example on using Group Policy to push

certificates to FireFox: http://serverfault.com/questions/77232/installing-a-ca-certificate-on-multiple-windows-machines-ie-firefox

Installing a Certificate into a Safari Browser 1. Open Keychain Access (/Applications/Utilities/).

(13)

TechNote

2. Select System from the list of Keychains.

(14)

TechNote

4. Click the menu drop-down list, then select Certificate.

5. Click the Destination Keychain drop-down list, then select System. 6. Click the Open button.

The authentication pop-up window displays:

(15)

TechNote

8. Click the Always Trust button.

You are prompted to authenticate one more time. The certificate will be trusted after the second authentication.

Troubleshooting Common Configuration Mistakes

When configuring certificates for DPI-SSL, a common mistake is selecting the public HTTPS administration certificate for DPI-SSL.

Note: This is an example of a invalid configuration and should not be performed on your appliance. It is only

intended to show you what NOT to do.

(16)

TechNote

(17)

TechNote

The proper use of this Public Signed certificate is for HTTPS firewall management or SSL-VPN. To use this certificate for HTTPS firewall administration, perform the steps below:

1. Navigate to the System > Administration page.

2. Select the correct signed certificate in the Certificate Selection drop-down list. 3. Restart the firewall.

(18)

TechNote

When a CSR is configured with appropriate CNs, subject alternate names, etc., the signed Public certificate used for HTTPS firewall management is displayed:

The browser trusts the certificate and is verified by the Root CA that was used to sign the certificate. You can also use a signed certificate with SSL-VPN:

1. Navigate to the SSL-VPN > Server Settings page.

2. Select the correct signed Public certificate from the Certificate Selection drop-down list.

_____________________ Last updated: 3/21/2012