When the ProxySG intercepts an SSL session, it creates two SSL tunnels: one between the client and ProxySG and another between the ProxySG and the remote server. Since the ProxySG is the endpoint for the client SSL session, it needs to present an SSL certificate to the client that the client will accept AND that the ProxySG can use to decode the traffic so it can inspect the data. In order to accomplish this, the ProxySG acts as a Certificate Authority and uses a subordinate CA certificate to be the "issuer" for the remote server's SSL certificate. For example, if the client is trying to connect to https://www.example.com, the ProxySG will present the client with a certificate that states the ProxySG has issued the certificate to www.example.com. If the client browser does not trust the ProxySG to be an issuer of certificates, or if the ProxySG's certificate doesn't have the right attributes that denote it as an issuer, the browser will show an error to the end user indicating an SSL handshake issue. Some browsers, such as Firefox, are very security-conscious, and will return an error to the user if any part of this transaction is not configured exactly right on the ProxySG.
Please note that a public Root CA such as VeriSign will not provide you with a subordinate certificate, they will only provide you with a server certificate, which cannot be used to issue other certificates. The reason for this is that with a subordinate CA certificate, you could use that to issue SSL certificates for any site you wanted to, and since VeriSign gave you the certificate, they would be stating that they trusted you to issue SSL certificates to anybody you wanted to. They would
not do this, simply because of the possibility that you could issue SSL certificates to "bad" websites and VeriSign would be seen as trusting those sites, even though they have no knowledge of that site. Another possibility exists where you could use that certificate to intercept SSL for any user anywhere; since almost every web browser in the world trusts VeriSign, you could intercept all users' traffic and have access to all of their previously encrypted data. Instead, you can use a local CA program to act as a Root Certificate Authority, and use that to generate a subordinate certificate, such as with Microsoft PKI server (for more information see: 000008716 ). As long as your clients trust that local root, you could install any subordinate certificate generated by that root and use it in the keyring for SSL interception on the ProxySG. If your clients do not trust that root CA, they will get errors when browsing which indicate that the SSL certificate is signed by an "untrusted issuer."
A self-signed certificate on the ProxySG can also be used for SSL interception without the need to retrieve a certificate from a root CA, but would need to be installed in the browser as a Trusted Root Certification Authority. Here is a third-party link for more information on how to deploy the certificate into Internet Explorer browsers by group policy: http://unixwiz.net/techtips/deploy-webcert-gp.html
NOTE: This Knowledge Base article applies ONLY to a forward SSL proxy, referred to by the ProxySG as SSL Interception. A reverse SSL proxy, which is an "HTTPS Reverse Proxy" service configured on the ProxySG, uses a standard server certificate, which IS something you can purchase from a public Certificate Authority such as VeriSign or GoDaddy. For information about configuring an HTTPS Reverse Proxy, please see the following Tech Brief .