EdgeSWG (Formerly Known As ProxySG) Explicit SSL-Interception With Self-Signed Certificate
search cancel

EdgeSWG (Formerly Known As ProxySG) Explicit SSL-Interception With Self-Signed Certificate

book

Article ID: 279277

calendar_today

Updated On:

Products

ISG Proxy ProxySG Software - SGOS Advanced Secure Gateway Software - ASG ASG-S200 ASG-S400 ASG-S500

Issue/Introduction

Using self-signed certificate for explicit SSL-Interception on Edge SWG

Resolution

Sample machines hostnames that are resolved by DNS:

Edge SWG: proxysg.yourdomain.local (192.168.1.156)  |  Terminal PC is under same Active Directory

 

 

STEP1

Create a new Keyring. Go to Select Configuration -> SSL -> Keyrings > Add Keyring

Click Create and give it a name in the Keyring Name field example EXAMPLEKEYRING

Select show key pair - Private Key Visibility, which will allow you to move the private key and certificate to another proxy

Set the bit key ring size to default 2048 bit

Click APPLY to save the committed settings and SAVE...> Save Changes. Now, the SSL Key ring has been successfully created.  

The keyring will appear on your list

 

 

STEP2

Retrieve the RSA Keypair if you’d like to use same self-signed certificate on another Edge SWG

Open Proxy CLI and execute

ProxySG> enable

ProxySG# config t

ProxySG(config)# ssl

ProxySG(config-ssl)# view keypair unencrypted EXAMPLEKEYRING

<RSA KEYPAIR DETAILS>

 


Copy & Paste it to Notepad for future purposes

 

STEP3

Edit the newly created key ring. In this example, I will use the key ring called “EXAMPLEKEYRING” that was created above in step 1.

Click create under Certificate  

Fill in the certificate template.  For Common Name (CN), I recommend using something that can easily be identify. In this case, the common name is the host name of Edge SWG appliance.  

NOTE: Common name should reflect the hostname or FQDN of the Edge SWG (documentation) ex. proxysg.yourdomain.local

Complete the form, paying close attention to the Common Name field. This should be a hostname or FQDN that resolves to the Edge SWG appliance from outside of your protected network. This is the first step in ensuring that Internet-based browsers can trust the certificate the appliance presents.

(SAN) SubjectAltName attributes > check the formating , it's worth to add the DNS and IP of the Edge SWG

If there's no SubjectAltName attribute in the certificate the site will still be shown as insecure with ROOTCA installed. It is advised to create a CSR with SAN over the CLI rather than GUI.

 

Click APPLY after you have filled out the certificate template then  SAVE > SAVE... > Save Changes 

This will save all the data to Keyring

 

 

STEP4

Under Configuration > Keyrings list, click on View Certificate EXAMPLEKEYRING

Highlight self-signed certificate and click Edit

Verify the common name (CN)

Validate certificate expiration date – self signed certificate are valid for 2 years

Go to PEM settings and copy the content of CA to a notepad

 

STEP5

Enable SSL detection over HTTP if you haven’t done it previously

Go to Proxy Admin Console > Configuration > Services > Proxy Services

Locate Explicit HTTP and click Edit

Check Detect Protocol

Click OK

Click Apply - to save setting

 

STEP6

Go to Admin Console > Configuration > SSL > CA CERTIFICATES

Click on IMPORT. Put a CA name EXAMPLEKEYRING-SSL (needs to be different than keyring) and import the CA certificate save earlier

Click on OK, SAVE... > Save Changes

Go to Admin Console > Configuration > SSL > CA CERTIFICATES > CA Certificates List > browser-trusted > Select Certificates and enable the EXAMPLEKEYRING-SSL on this list

Click on Select, SAVE... > Save Changes

 

STEP7

Configure policy rules and layers in the Visual Policy Manager (VPM)

Navigate to Visual Policy Manager in the right-top navigation



In the following example, the VPM policy only contains two layers:

 

  • The Web Access Layer Action is set to allow "Any" Source and Destination to access the Internet.

 

The SSL Interception Layer contains one rule, which is set to SSL intercept "Any" Source and Destination.




If not existent please create a SSL-Intercept layer, and add new rule

  • Create the SSL intercept policy. The SSL Interception Layer might look like this at first:


     
  • Under Action, click None, and select Set.
  • Click Add a new object
  • Select Enable SSL Interception.
  • Select Enable HTTPS Interception.
  • Check Issuer Keyring, and select the keyring that you created earlier.


     
  • Click OK.
  • Click Install Policy.

 

Click Install Policy to save SSL policy

 

STEP8

Download self-signed SSL certificate via https://<proxy-sg>:8082/SSL/Download_ca with name EXAMPLEKEYRING to your PC

This Certificate needs to be then installed on all of the PC that will use SSL-Interception under Trusted Root Certification Authorities chain or can be deploy using Microsoft Group Policy.

 

STEP9

Verify HTTPS interception by Edge SWG from the browser

Go to https://www.bluecoat.com

Click on the lock icon (red arrow)

Click View Certificate

Validate the Issued by matches the Edge SWG common name (CN) in the certificate

 

STEP10

Verify HTTPS interception from Active Sessions

Reports -->Sessions--> Active Sessions

Verify that HTTPS Fwd is visible for each server connection

 

 

STEP11 (OPTIONAL)

Import the self-signed certificate to another Edge SWG instance

KB: https://knowledge.broadcom.com/external/article/166133/how-do-i-import-an-ssl-certificate-and-p.html

Additional Information

 

Import the certificate to "Trusted Root Certification Authorities" store on the Client PC, so the self-signed cert will be trusted:
https://www.wipo.int/pct-eservices/en/support/cert_import_backup_edge.html 

NET::ERR_CERT_COMMON_NAME_INVALID / Certificate "Not Secure" common root causes issues on Client PC:

https://kinsta.com/knowledgebase/net-err_cert_common_name_invalid/ 

Powered by Wolken Software