Windows 2008 Enterprise Server R2 SP1 Enterprise PKI was used to generate a certificate.
The high level steps to configuring a transparent ProxySG or Advanced Secure Gateway (ASG) to successfully authenticate users using a HTTPS based virtual URL are:
Ensure that the ProxySG or ASG has the time and date set up correctly.
Create the keyring on the ProxySG or ASG
Create a certificate on the Microsoft PKI server
Import the certificate to the ProxySG or ASG
Create a new Service and Listener to intercept the redirected authentication requests.
Configure the authentication realm to use the virtual URL
Add policy to enable authentication
Verify that users are being authenticated
Step 1 Ensure that the ProxySG or ASG has time and date set up correctly.
The recommendation is to set up the ProxySG to get its time from a reputable and reliable time source.
To review your NTP settings on the ProxySG, please log in to the Management Console (https://
:8082/) and select
Note: any discrepancies between the date and time in certificates created by the ProxySG and the actual time can cause unexpected behavior, as such it is important that the time on the ProxySG be set up correctly before proceeding.
Step 2 Create the keyring on the ProxySG or ASG
Select Configuration > SSL > Keyrings. Click on Create to create a new keyring for the ProxySG.
Give the keyring a meaningful name, in this example we will use Authentication-KR.
Select Show Keypair.
Set the size as required, the default is 2048 bits.
Click OK and Apply to save your changes.
Now select the keyring just created and click Edit
Click Create under Certificate Signing Request at the bottom.
Fill in appropriate information into the request.
Note: When filling out this CSR it is important to make sure that the
Common Name matches the DNS name of the ProxySG, otherwise the web browser will return a warning that it does not trust the certificate.
Click OK, then Close, then Apply.
Edit the Keyring. At the bottom you will now see a certificate signing request (CSR). Copy this text to the clipboard. Click Close.
Save the CSR that you copied to the clipboard to a text file and give it a meaningful name such as authentication.csr.
Step 3 Create a certificate on the Microsoft PKI server
Login to your Microsoft Active Directory Certificate Services server, the default url is http://
Click Request a certificate
Click on Advance certificate request
Paste the CSR into the Base-64-encoded certificate request *CMC or PKCS#10 or PKCS#7) dialog box.
Select Web Server in Certificate Template then click on Submit
Note: If you do not select the Web Server template you may find that some browsers will not accept the emulated certificate from the ProxySG and the user will get an untrusted warning exception.
Select Base 64 encoded then click on Download certificate
Note: when you download the certificate, make sure to rename it to something meaningful, in this example it is
If you've already imported your root servers CA you can skip steps 8 through 11
Click Home in the top right corner of the page.
Click Download a CA certificate, certificate chain, or CRL
Select the appropriate CA Certificate from the list at the top, select Base 64 as the encoding method and click Download CA certificate.
Again make sure to rename the CA certificate to something meaningful in this example it is madlab CA certificate.csr
Step 4 Import the certificate to the ProxySG or ASG
In the Management Console on the ProxySG, select Configuration > SSL > Keyrings. Select the Authentication-KR created earlier and click Edit.
Click Import, under Certificate.
Open the authentication.cer file in a text editor and copy the contents to the clipboard, then paste in the Import Certificate dialog box. Click OK then Close and then Apply to save your changes.
Note:if you happen to import the contents of the wrong certificate into this dialog box, when you click
apply, you will get an error message similar to
"The private key in the certificate "Authentication-KR" does not match the one in the keyring"
Add the Root CA, (if it hasn't already been added) madlab Root CA (certificate.cer), and the ProxySG CA certificate (authentication.cer) to the list of CA certificates in the ProxySG. In the Management Console, go to the CA Certificates tab, select Configuration > SSL > CA Certificates
Click Import. Name the CA certificate and paste in the contents of the authentication.cer file and click OK and then Apply
Note: the ProxySG will order the CA Certificates in alphabetical order, however lower case names are appended to the end of the list making them easier to find
Repeat this procedure to import the Root CA
You should now have two new CA certificates in the list
Next we will add the Root CA, and ProxySG authentication certificates as browser trusted CAs. Select CA Certificate Lists tab at the top.
Then select browser-trusted and click Edit.
Select the newly added Root CA certificate and ProxySG authentication certificate on the left and click Add to move it to the right column. Click OK and then Apply.
Step 5 Create a new Service and Listener to intercept the redirected authentication requests
Select Configuration > Services > Proxy Services > Standard > New Service.
Give the new service a meaningful name, in this example MadlabAuthentication
Under Proxy Settings, change the Proxy to HTTPS Reverse Proxy
For Keyring select the Authentication-KR created earlier
Under Listeners click on New
Change the Destination to ALL and change the port to 4443 (or any other port of your choosing as long as it doesn't conflict with a preexisting port)
Click on OK then OK again and Apply
(Optional) If you use a TCP-tunnel service on port 443 in transparent mode instead of the SSL service, enable protocol detection on the TCP-tunnel service. (Configuration > Services > Proxy Services)
Step 6 Configure the authentication realm to use the virtual URL
Assuming that the Authentication Realm on the ProxySG or ASG exists, add the virtual URL
Click on Configuration > Authentication > IWA > IWA General
In Virtual URL enter https://
Note: that the protocol is
HTTPS and the port number is
4443 (or the port you assigned the listener created above).
Also note that the proxy name must match the name used in the Common Name field of the authentication certificate created above and this name must be resolvable by the client, in our example we are using https://es-bar-sg1:4443
In Visual Policy Manger create a new Authentication Layer
Click on Policy > Add Web Authentication Layer
Give the Layer a meaningful Name then click OK
In the Action column right click None and select Set
Click on New, give the object a meaningful name, make sure the correct realm is selected then select an appropriate redirect mode, either Origin IP Redirect or Origin Cookie Redirect, finally click OK till the dialog box closes and apply the policy.
Step 8 Verify that users are being authenticated
To confirm that users are logging in correctly from the management console go to Statistics > Authentication select the appropriate realm or leave it blank and then click on either “Display by user” or “Display by IP” and you should see the users that have authenticated.
Imported Document ID: 000027763
Subscribing will provide email updates when this Article is updated. Login is required.