The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Overview

HTTPS-aware applications such as Internet Browsers, implement SSL/TLS protocols to prevent inadvertent communication with a malafide web service.
The SSL / TLS protocols enable applications to verify identity of the remote web services, and appropriately encrypt the entire communication preventing any third-party to eavesdrop.
In response to the SSL Handshake initiated by the client application, the remote web service submits identification using a Digital Server (SSL/TLS) Certificate.
The client application maintains stores of CA certificates representing various Trusted Root Certification Authority.
Unless explicitly trusted, the client application checks if the server certificate is signed by a Trusted Root CA.
The Trusted Root CA binds the server certificate to a set of FQDNs, and ensures each signed certificate bears a unique serial number.
Post verification the client proceeds with normal HTTP Protocol, but the communication is encrypted based on the parameters agreed during the SSL handshake, and the server certificate.The communication is thus opaque and cannot be inspected or modified by a third-party.

To inspect inspect and / modify the communication between a client and server, a proxy server terminates connections.
For handling HTTPS traffic it must additionally perform SSL Termination.
This requires the proxy server to provide an SSL Certificate for the web service requested by the client.
For seamless user experience, this SSL certificate must be signed by a Trusted Root CA.
Enterprises therefore ensure a Trusted Root CA is installed in the Trusted Root CA Store of the sanctioned web applications, such as Internet Browsers.
The proxy server is provided this Trusted Root CA, along with the associated Private Key.
The proxy server then produces the required SSL certificates for any web service and signs it using the provided Certificate-Key pair.
Enterprises that require multiple instances of proxy services to handle large traffic volumes, or geographic spread.
The deployment must also guarantee each certificate thus created by proxy servers have a distinct serial number.

The Self-Service Portal for managing your SafeSquid deployments, facilitates easy creation of Trusted Root CA Certificates.
You would be required to then share the CA certificate with your enterprise users, or push it via Group Policies, if you have a Microsoft Domain Network.
You may also import an SSL CA Certificate, provided by your existing Enterprise CA Infrastructure.
In such case you would not be required to push a Trusted Root CA Certificate.
All SafeSquid instances deployed by you that share the same Product Activation Key, shall automatically download the Trusted Root CA certificate.
Each SafeSquid instance shall then produce a sub-CA certificate-key pair, to sign the SSL Certificates for requested web services.
This mechanism ensures each SSL certificate bears a unique serial number, and signature, but only one Trusted Root CA Certificate is to be shared across client applications.
All Certificate-Key pairs are passphrase protected to prevent misuse.

Access the Self Service Portal

You can access the Self Service Portal from https://key.safesquid.com

Login to your SafeSquid Self Service Portal https://key.safesquid.com account to generate SSL certificate as generation of certificate cannot be done via SafeSquid's web interface http://safesquid.cfg/