Configure SSL interception with Microsoft PKI for Explicit proxy on Edge SWG

Products

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

Issue/Introduction

Performing SSL Interception using a Microsoft PKI infrastructure in an explicit proxy environment.

Environment

Edge SWG: 7.3.x, 7.4.x

Resolution

Sample machines hostnames that are resolved by DNS:

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

STEP 1

Select Configuration > SSL > Keyrings. Create a new keyring (Add Keyring) for the Edge SWG ex. proxysg.yourdomain.local or test . Select Show Keypair based on your security policy. Click OK and Apply to save your changes.

STEP 2

Edit the keyring created above.

STEP 3

Click Create under Certificate Signing Request at the bottom.

STEP 4

Complete the Certificate Signing Request (CSR) form using the parameters matching the screenshot below. Click Apply to save the changes.

Review the following field guide to ensure the configuration aligns with your deployment:

Common Name (CN):

It is the primary identity label of a certificate. Because its function changes completely based on your deployment architecture, configure it using one of the two scenarios below:

When creating a Subordinate CA for outbound SSL Interception, the proxy acts as an issuing authority (a certificate printing press) rather than a direct website destination.

What to type: A descriptive, human-readable corporate label (e.g., Corporate-EdgeSWG-SSL-Interception or Forward-Proxy-SubCA).
Why it matters: Client browsers completely ignore routing or URL-matching checks on the Common Name of an intermediate/issuing CA. However, this name is highly visible to your users. If an employee inspects the browser padlock on an intercepted website or encounters a corporate policy block page, this exact string will be displayed as the "Issuer." Using a clear, professional label validates the connection and prevents unnecessary helpdesk tickets.

Note: For Reverse Proxy / Secure Explicit / Management, the CN must match the exact FQDN or Load Balancer VIP used to access the appliance, and it must be duplicated into the SAN field to prevent browser security blocks.

Basic Constraints:

It is a critical extension that defines a certificate’s role. It tells devices and web browsers whether the certificate belongs to an Authority (CA)—which is legally allowed to sign and issue other certificates—or an End-Entity (like a specific web server), which cannot issue certificates.

Based on the EdgeSWG interface options, apply these settings for an outbound SSL Interception SubCA:

Certificate Authority: MUST BE CHECKED. This injects the CA:True attribute, giving the proxy the authority to act as a printing press to dynamically generate and sign emulated website certificates (like www.google.com) on the fly.
Critical: RECOMMENDED (Policy-Dependent). Checking this forces client browsers to strictly evaluate and enforce the certificate's CA status. Marking this extension as critical is a standard industry best practice for all intermediate CAs.
Path Length: SET TO 0. This security guardrail restricts the proxy so it can only sign final end-entity websites. It strictly forbids the creation of any lower-level Subordinate CAs beneath the proxy.

Subject Alternative Name (SAN):

A SAN is a certificate extension used to list additional hostnames or IP addresses secured by a single certificate. Modern browsers rely entirely on the SAN field—instead of the Common Name—to validate website destinations.

Is a SAN Required for this SubCA?
- For Outbound SSL Interception: NO. A SAN is completely optional on your Subordinate CA. The proxy acts as an issuing authority, not a website. When a user browses the web, the EdgeSWG automatically generates and applies the correct SANs to the spoofed website certificates on the fly.
- When is a SAN mandatory? You only need a SAN if you reuse this certificate for Transparent Proxy Authentication or direct Secure Explicit (port 8443) connections. In those scenarios, browsers treat the proxy as a direct website destination and will block the connection if a matching SAN is missing.

Alternative Procedure: CSR Creation via CLI:

If you prefer to use the Command Line Interface (CLI), the process follows the same logic. Follow these steps to create the keyring and generate the CSR:

Step 1: Create the Keyring
Execute the following commands to create a 2048-bit keyring:

Proxy> enable
Proxy# config t 
Proxy (config)# ssl
Proxy (config-ssl)# create keyring  no-show <keyring-name> 2048

Step 2: Generate the Signing Request (CSR)
Execute the following command and fill out the interactive prompt using the parameters from your planning worksheet:

Proxy (config-ssl)# create signing-request <keyring-name>


  Country code []: US
  State or province []: 
  Locality or city []: 
  Organization name []: 
  Organization unit []: 
  Common name []: proxysg.yourdomain.local
  Email address []:
  Challenge  []:
  Company name []: 
  Digest type (sha1, sha224, sha256, sha384 or sha512) [sha256]: sha256
  Subject alternative name []: IP:xx.xx.xx.xx,DNS:proxysg.yourdomain.local,DNS:proxysg1
  Key usage []:
  Extended key usage []:
  Basic constraints []:

* REQUIRED

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

Step 3: View the CSR
Once the interactive setup is finished, run the following command to display the generated base64-encoded text. This will be also propagated after a while into the GUI view as well.

Proxy (config-ssl)# view signing-request <keyring-name>

STEP 5

Edit the created Keyring. At the bottom will now be a certificate signing request (CSR). Copy this text to the clipboard. Click Close.

Ex.

-----BEGIN CERTIFICATE REQUEST-----

[...]

LBlY3B15/Vv3qtjsGSsmn9oWvkrEbL1c/f29LBcB0F6XqpnavUrIlLt79inLHZFx

3QRKTPDs2JLJYfzJaBY7m6oRYVZ1NleFcK1oMyFVGLCVkw4=

-----END CERTIFICATE REQUEST-----

STEP 6

Save this text in a file and give it a name such as proxysg.csr. Click Close.

Complete the following steps using Internet Explorer:

STEP 7

In Internet Explorer, open the URL of the Microsoft Certificate Authority server. Generally, the default URL is http://<Microsoft Certificate Authority server>/certsrv (in our ex. dc.yourdomain.local/certsrv)

STEP 8

Click Request a certificate.

STEP 9

Click advanced certificate request.

STEP 10

Select Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request using a base-64-encoded PKCS #7 file.

STEP 11

(Optional) You may be prompted to install "Microsoft Certificate Enrollment Control ActiveX". Click Accept and continue.

STEP 12

In the Saved Request field, copy the CSR created above on the ProxySG. Select Subordinate Certificate Authority for the Certificate Template. Click Submit.

STEP 13

Depending on the configuration of the CA, you may be issued a certificate immediately, or it may need to be approved by an admin. Once approved, select Base 64 encoded and Download certificate.

Save the certificate for the proxy

Ex.

-----BEGIN CERTIFICATE-----

[...]

-----END CERTIFICATE-----

STEP 14

Click Home in the top right corner of the page to get back to Home of Certificate Authority Server

STEP 15

Click Download a CA certificate, certificate chain, or CRL (your domain ROOT_CA)

STEP 16

Select the appropriate CA Certificate from the list at the top, select Base 64 as the encoding method and click Download CA certificate.

Complete the following steps on the Edge SWG:

STEP 17

In the Admin Console on the Edge SWG, select Configuration > SSL > Keyrings. Select the keyring created above and click Edit.

STEP 18

Click Import, under Certificate.

STEP 19

Paste in the base 64 certificate text generated Web Server certificate from CSR earlier and click Close and then Apply to save your changes.

STEP 20

Next, it will be necessary to add the organization Root CA and the Edge SWG generated certificate from CSR to the list of CA certificates on the Edge SWG. In the Admin Console, go to the CA Certificates tab.(Select Configuration > SSL > CA Certificates)

STEP 21

Click Import. Name the generated certificate from keyring and paste in the base 64 version of the Edge SWG's subordinate CA certificate and click OK and then Apply.

NOTE: You can be notified that CA already exists, then you can skip.

STEP 22

Click import. Create name the organization Root CA Certificate and paste in the Base 64 version downloaded above and click OK.

STEP 23

Next we will add the Root CA, intermediate CA (if applicable), and proxy certificate as a browser trusted CA. Select CA Certificate Lists tab at the top.

STEP 24

Select browser-trusted and click Edit.

STEP 25

Select the newly added Root CA, intermediate CA (if applicable), and proxy certificate on the left and click Add to move it to the right column. Click OK and then Apply.

Note: If the proxy is configured to have a different CCL than the default one of "<All CA Certificates>" (found under WebUI > Configuration > Proxy Settings > SSL Proxy), also add the certificate signed by the PKI for the proxy to the selected CCL. This ensures that the proxy will provide the new certificate, along with the emulated certificates to the clients.

STEP 26

Configure the Edge SWG appliance to perform SSL interception. Confirm that the HTTP service on the Edge SWG appliance is properly configured

In the Edge SWG Admin Console, navigate to Configuration > Services > Proxy Services > Proxy Services tab

In this example, the Edge SWG appliance is set to use the default Explicit HTTP service. It is also configured to intercept HTTP traffic on ports 80 and 8080, with the Detect Protocol enabled (this must be enabled for SSL interception to work).

STEP 27

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.

STEP 28

Check the certificate in a browser

You can now run a test using a computer that is a member of the domain of which the Microsoft Certificate Server is also a member.

To do this, check the certificate that ProxySG is providing to the browser. The Common Name (CN) should match what you used when creating the CSR.

If the Certificate shows untrusted on your PC/browser it means that you need to install the organization Root CA, not added certificate to Browser/Trusted directory on Edge SWG or Edge SWG certificate (optional) on the client PC. Make sure the URL cert is trusted in browser or there will be an issue presented with certification signed by your root Certificate Authority (ex. NET::ERR_CERT_COMMON_NAME_INVALID)

IMPORTANT: Make sure that the authoritative certs are also put in the store “Trusted Root Certification” Authorities on the machine and the browser trust your CA

Additional Information

KB articles: