Using Certificates in HTTPS Clusters

In a typical HTTPS scenario described above, the client and server are communicating directly, and the server is doing all the work of encrypting and decrypting packets, and sending the server certificate to the client. If you have many systems servicing requests for the same website, you need to install certificates on each server.

With FortiADC, you do not need to install a server certificate on every server in a Layer 7 HTTPS cluster. Since certificates are associated with host names and not IP addresses, you only need a server certificate for each HTTPS cluster and the certificates are installed only on FortiADC-- not on each server. This reduces maintenance by reducing the number of certificates required for a group of systems serving content for the same host name.

When a client requests a connection to an HTTPS cluster, FortiADC establishes the HTTPS connection with the client, off loading SSL processing from all the servers in the HTTPS cluster. FortiADC communicates with the clients via HTTPS; the traffic between FortiADC and the servers in an HTTPS cluster is HTTP (i.e., unencrypted).

Compared to the typical scenario where each client is establishing direct HTTPS connections with servers, encrypting and decrypting packets, and serving content as well, SSL offloading improves the overall performance of the cluster.

For even better performance, some FortiADC models are equipped with SSL Hardware Acceleration. With hardware acceleration, processing for cipher suites supported by acceleration hardware is done by dedicated hardware, enhancing overall HTTPS throughput.

Note that HTTPS and certificates can also be used on servers in Layer 4 TCP and UDP clusters, but you will need to install a server and client certificate on each server in the cluster (since FortiADC is not doing any HTTPS/SSL processing in Layer 4). In this scenario, no certificates are installed on FortiADC.

If you want to use client certificates with an HTTPS cluster, you’ll need to get a signed client certificate from a CA, or create a self-signed certificate. A client certificate needs to be installed on each client that will access the FortiADC cluster, as well as on FortiADC.

Just as with server certificates, you may need to install a client certificate and a chained root certificate, if you obtain your certificates from a CA without its own Trusted Root CA certificate. Some sites prefer to use self-signed certificates for clients, or set up their own local CA to issue client certificates.

Client certificates can be used in two ways with FortiADC:

1. Install the entire client certificate chain on FortiADC. This requires that every client passes the exact same certificate to FortiADC for validation.
2. Install an intermediate CA certificate as the client certificate on FortiADC. This allows unique certificates to be used on clients and a single client certificate to be uploaded to FortiADC. Following this method requires some certificate processing on the servers behind FortiADC in order to prevent access by clients with revoked certificates. This method, therefore, should be used only under the following conditions:

1. If the site is able to use an intermediate CA, or multiple CAs, which signs all and only certificates authorized for use with the cluster.
   AND

2. If the application running on the servers behind FortiADC is able to perform Certificate Revocation List (CRL) processing by matching the CSN (certificate serial number) to the intermediate CA's CRL, and does so for all requests,
   THEN

3. FortiADC can safely support the use of individual client certificates for different clients, by appropriately setting the verify depth option for the HTTPS cluster and uploading the intermediate CA's certificate to the cluster as the client certificate. If client certificates use different CAs, multiple intermediate CAs can be uploaded to FortiADC in a single file.

This method ensures that only certificates that pass the CRL check on the server can be used to access the cluster. Note that this method also assumes that validating the intermediate certificate only in (b) above is sufficiently secure for the site.

Currently, the following certificate/key file formats are supported:

1. PEM - PEM format certificates/keys are ascii files that usually use a ".pem" extension with the file name. PEM stands for Privacy Enhanced Mail. A PEM-format certificate contains a Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" tokens. Keys encoded using the PEM format would have "-----BEGIN PRIVATE KEY-----" and "-----END PRIVATE KEY-----" tokens. PEM format certificates/keys only are supported using the GUI.
2. PKCS #12 - PKCS #12 format files are binary files, usually with a ".p12’"extension with the file name.

3. PFX - PFX format files are also in PKCS #12 format, however, with additional Microsoft specifics. These files usually have a ".pfx" extension with the file name. PFX files are supported in the GUI, however, not in the CLI.

Currently, PEM-format certificates and keys must be uploaded separately in the CLI using the certfile and keyfile parameters in the certificate context or as shown below in the GUI.

PKCS #12 and PFX format files usually contain both the certificate and the associated key. You can upload this file once as either the certfile or the keyfile in the GUI. The GUI will separate the keyfile and the certfile behind the scenes and store them appropriately. You can also upload the same file as both the certfile and the keyfile.

	If you have uploaded a certificate that doesn't match the cipher suite that is configured for the HTTPS cluster, you will no longer be able to log into the GUI. You will need to supply the correct certificate/key pairing. In the meantime, you can enable HTTP access to the GUI temporarily to enter the proper certificate/key pairing to enable HTTPS access.