Setting up SSL certificates from Self Service Portal

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 the identity of the remote web services, and appropriately encrypt the entire communication preventing any third party from eavesdropping.

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 a Trusted Root CA signs the server certificate.

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 upon during the SSL handshake and the server certificate. Thus, the communication is opaque and cannot be inspected or modified by a third party.

A proxy server terminates connections to inspect and/or modify the communication between a client and server.

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 a 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 with 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 has a distinct serial number.

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 a 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

The Self-Service Portal for managing your SafeSquid deployments, facilitates easy creation of Trusted Root CA Certificates.

Generate SafeSquid Certificate

Using Self-Signed Certificate

Note: When you see the "Generate" button it means that SafeSquid's SSL certificate has not been generated yet.

Note: The passphrase entered in step #3 is non-recoverable. Remember to save the passphrase if in case you want to reuse the same certificate with a different activation key.

selecting general self signed and wntering passphrase for self signed certificate and clicking on generate

Using Enterprise CA Certificate

With a Passphrase

Generating SafeSquid certificate using an enterprise CA certificate which has a passphrase.

clicking on regenerate, uploading the enterprise CA cert and selecting have passphrase option

entering the passphrase and clicking on validate private key

selecting retain password and clicking on upload

Without a Passphrase

clicking on regenerate, uploading the enterprise CA cert and selecting does not have passphrase option

Note: The passphrase entered in step #6 is non-recoverable. Remember to save the passphrase if in case you want to reuse the same certificate with a different activation key.