If you need to create a new keyring and issue a new certificate for your ProxySG appliance, please follow the instructions provided in KB5357. For a deployment guide that uses self-signed certificates instead certificates issued by a Microsoft PKI server, please check this guide found in the SSLV First Steps WebGuide.

There are several ways in which the SSLV can be deployed connected to a ProxySG while intercepting SSL traffic with certificates issued from a Microsoft PKI server. Please note that there is no order in which the ProxySG and the SSLV should be deployed. This means that traffic can be processed first by the SSLV or the ProxySG interchangeably. However, some configuration changes will be necessary in both devices if reversing the devices' placement is required.

This article will focus on a deployment where the closest device to the client is the SSLV, as depicted in the following picture:

The two configuration types are the following:

Option 1 - Using 1 Subordinate Certificate on the ProxySG and using the same certificate in the SSLV.

Option 2 - Using 2 Subordinate Certificates - One for the ProxySG and a different one for the SSLV.

In the following section, I will provide instructions on how to configure both options on the ProxySG and the SSLV.

This article was written with the use of the following hardware and software:

• ProxySG SG300 with SGOS 6.6.4.2
• SSLV SV800 with firmware version 3.9.4.1-94
• Windows 2008 Enterprise Server R2 SP1 Enterprise PKI

Option 1:

This option must be used when we need to perform SSL Interception in both devices and we have to use the same subordinate certificate in both devices. We will need to import the certificate that the ProxySG uses for SSL Interception (including its private key), and use it to resign certificates on the SSLV appliance. The client's browser will see that the common name of this certificate is the ProxySG and the issuer is the Microsoft PKI server, even though the connection is being decrypted twice: once by the SSLV and another by the ProxySG.

These are the steps required for this option:

1. Log in to the ProxySG CLI, in enable mode.
2. Enter the following CLI command to show the private key of a keyring named default (substitute the name of your
own keyring that contains the certificate issued by your Microsoft PKI server):
show ssl keypair ssl-interception-cert-name
3. Copy the output of this command, starting with -----BEGIN RSA PRIVATE KEY----- all the way through ---
--END RSA PRIVATE KEY-----.
4. Paste the text into a text editor such as Notepad or Notepad++
5. Enter the following CLI command to show the certificate of the same keyring:
show ssl certificate ssl-interception-cert-name
6. Copy the displayed text, starting with -----BEGIN CERTIFICATE----- all the way through -----END
CERTIFICATE-----.
7. Paste the text into a text editor in a separate file from the private key.

1. Log in to the SSL Visibility Appliance.
2. Select PKI > Resigning Certificate Authorities.
3. In the Local Resigning Certificate Authorities panel, click Add (Plus symbol button). The Add Local Resigning Certificate Authority
window displays.
4. Click the Paste Text tab.
5. In the Certificate Data box, paste the certificate text that you copied from the ProxySG (in the previous step).
6. In the Key Data box, paste the private key text you copied from the ProxySG.
7. If applicable, select the Encrypted checkbox and enter the Password.
8. Click Add. If the operation was successful, you will see a message that says "Certificate(s) added". Click OK.
9. The Summary section in the Local Resigning Certificate Authorities panel should now contain the certificate we imported. If we check the details of that certificate, we should be able to see the issuer, which in this case is the Microsoft PKI server.
10. Click Apply .

1. Select PKI > External Certificate Authorities.
2. In the External Certificate Authorities Lists panel, select all-external-certificate-authorites. The lower panel
displays all the certificates in this list. Now we need to add the root CA which in this case it is the Microsoft PKI server certificate.
3. In the lower panel, click Add .
4. Click the Paste Text tab.
5. In the Certificate Data box, paste the certificate text obtained from your Microsoft PKI server (it can also be obtained from the ProxySG in the CA Certificates section).
6. If applicable, select the Encrypted checkbox and enter the Password.
7. Click Add. If the operation was successful, you will see a message that says "Certificate(s) added". Click OK.
8. The Summary section in the Local Resigning Certificate Authorities panel should now contain the certificate we imported. If we check the details of that certificate, we should be able to see the common name and issuer , which in this case both should be the Microsoft PKI server.

1. Configure your network segment/s according to your deployment.
2. Create ruleset that contains a Rule that performs Decryption(Resign Certificate). under your desired conditions using the certificate from the ProxySG in RSA Resigning CA.
For more information on these steps, please refer to the SSLV First Steps WebGuide

The SSL Session log should show Decrypt (Resign Certificate) action for the re-signed sessions that the SSLV and  ProxySG have intercepted

1. To see a list of recent SSL sessions, select Monitor > SSL Session Log.
2. For each session, look in the Action column. Make sure that the action is Decrypt (Resign Certificate) for traffic that
both devices are decrypting.
3. If everything is correct, the Certificate Status column should say Valid, and the Status column should display Success.
 

Option 2:

This option can be used when we can to issue a new subordinate certificate for our SSLV appliance. If this is the case, we will use this certificate SSLV Resigning. However, the ProxySG will use its own subordinate certificate to perform SSL Interception. The client's browser will see that the common name of this certificate is the SSLV and the issuer is the Microsoft PKI server. The connection is being decrypted twice, just like in Option 1, once by the SSLV and once by the ProxySG.

Please refer to KB 000024597 to issue and install the Subordinate certificate on your SSLV. Once done, we should test access to sites that we want to decrypt, and then look at the SSL Session Logs, verifying that the Action is Decrypt (Resign Certificate), Certificate Status says Valid and Status displays Success.

In this scenario, the certificate from the SSLV will only be visible in the interface that the client is facing. The interface that faces the ProxySG should be seeing the certificate arriving from the ProxySG. This demonstrates that the ProxySG is also performing SSL Interception on this request. This can also be verified by going to your ProxySG Managamente Console>Statistics>Sessions>Active Sessions and seeing that the desired session is being processed by the HTTPS Fwd Protocol.