Using certificates

This section includes the following information:

• Overview
• Prerequisite tasks
• Importing a local certificate
• Generating a CSR
• Importing a CA
• Creating a CA group
• Importing an Intermediate CA
• Creating an Intermediate CA group
• Using OCSP
• Using CRLs
• Configuring a certificate verification object

Overview

The FortiADC system must be able to process two types of TLS/SSL traffic:

• System administration—Administrators connect to the web UI (HTTPS connections only). When you connect to the web UI, the system presents its own default “Factory” certificate. This certificate is used only for connections to the web UI. It cannot be removed. Do not use this certificate for server load balancing traffic.
• Server load balancing—Clients use SSL or TLS to connect to a virtual server. When you use FortiADC as a proxy for SSL operations normally performed on the backend real servers, you must import the X.509 v3 server certificates and private keys the backend servers would ordinarily use, as well as any certificate authority (CA) or intermediate CA certificates that are used to complete the chain of trust between your clients and your servers.

The FortiADC system supports all of the TLS/SSL administration methods commonly used by HTTPS servers, including:

• Server name indication (SNI)—You can require clients to use the TLS extension to include the server hostname in the TLS client hello message. Then, the FortiADC system can select the appropriate local server certificate to present to the client.
• Local certificate store—A certificate store for the X.509 v3 server certificates and private keys the backend servers would ordinarily use.
• Certificate Authorities (CAs) store—A store for the CA certificates that the backend servers would ordinarily use to verify the CA signature in the client certificate.
• Intermediate CAs store—A store for Intermediate CAs that the backend servers would ordinarily use to complete the chain between the client certificate and the server certificate. HTTPS transactions use intermediate CAs when the server certificate is signed by an intermediate certificate authority (CA) rather than a root CA.
• OCSP—Use Online Certificate Status Protocol (OCSP) to obtain the revocation status of certificates.
• CRL—Use a certificate revocation list (CRL) to obtain the revocation status of certificates.
• Certificate validation policy—You can configure certificate validation policies that use OCSP or CRL. These policies can be associated with load balancing profiles.

Prerequisite tasks

You must download the certificates from your backend servers so that you can import them into the FortiADC system.

This example shows how to download a CA certificate from Microsoft Windows 2003.

To download a CA certificate from Microsoft Windows 2003 Server:

1. Go to https://<ca-server_ipv4>/certsrv/.

where <ca-server_ipv4> is the IP address of your CA server.

2. Log in as Administrator. Other accounts may not have sufficient privileges.

The Microsoft Certificate Services home page appears. Figure  53 is an example of this page.

Figure  53:   Welcome page



3. Click the Download CA certificate, certificate chain, or CRL link to display the Download a CA Certificate, Certificate Chain, or CRL page. Figure  54 is an example of this page.
4. From Encoding Method, select Base64.
5. Click Download CA certificate.

Managing local certificates

This topic provides the following information on using the System > Certificates > Local page:

• Importing a local certificate
• Generating a CSR
• Creating a local certificate group

Importing a local certificate

You can import (upload) the following types of X.509 server certificates and private keys to the FortiADC system:

• Base64-encoded
• PKCS #12 RSA-encrypted

Before you begin:

• You must have Read-Write permission for System settings.
• You must have downloaded the certificate and key files and be able to browse to them so that you can upload them.

To import a local certificate:

1. Go to System > Certificate > Manage Certificates.
2. Click the Local Certificate tab.
3. Click Import to display the configuration editor.
4. Complete the configuration as described in Table 95.
5. Save the configuration.

Generating a CSR

Many commercial certificate authorities (CAs) will provide a website where you can generate your own certificate signing request (CSR). A CSR is an unsigned certificate file that the CA will sign. When the CSR is generated, the associated private key that the appliance will use to sign and/or encrypt connections with clients is also generated.

If your CA does not provide this, or if you have your own private CA such as a Linux server with OpenSSL, you can use FortiADC to generate a CSR and private key. This CSR can then be submitted for verification and signing by the CA.

Before you begin:

• You must have Read-Write permission for System settings.

To generate a certificate request:

1. Go to System > Certificate > Manage Certificates.
2. Click the Local Certificate tab.
3. Click Generate to display the configuration editor.
4. Complete the configuration as described in Table 96.
5. Save the configuration.

The system creates a private and public key pair. The generated request includes the public key of the FortiADC appliance and information such as the IP address, domain name, or email address. The FortiADC appliance private key remains confidential on the FortiADC appliance. The Status column of the new CSR entry is Pending.

6. Select the row that corresponds to the certificate request.
7. Click Download.

Standard dialogs appear with buttons to save the file at a location you select. Your web browser downloads the certificate request (.csr) file.

8. Upload the certificate request to your CA.

After you submit the request to a CA, the CA will verify the information in the certificate, give it a serial number, an expiration date, and sign it with the public key of the CA.

9. If you are not using a commercial CA whose root certificate is already installed by default on web browsers, download your CA’s root certificate, then install it on all computers that will be connecting to your appliance. (If you do not install these, those computers might not trust your new certificate.)
10. When you receive the signed certificate from the CA, you can import the certificate into the FortiADC system.

Creating a local certificate group

Create local groups to facilitate the configuration of profiles that are associated with a virtual server.

Include in the local certificate group all of the server certificates and intermediate CAs for the pool of backend servers to be associated with a single virtual server.

Before you begin:

• You must have Read-Write permission for System settings.
• You must have already added the certificates to the local certificate store and Intermediate CA certificate store.

To create a local certificate group:

1. Go to System > Certificate > Manage Certificates.

The configuration page displays the Local Certificate Group tab.

2. Click Add to display the configuration editor.
3. Complete the configuration as described in Table 97.
4. Save the configuration.

Importing a CA

The certificate authority (CA) store is used to authenticate the certificates of other devices. When the FortiADC system is presented a certificate, it examines the CA’s signature, comparing it with the copy of the CA’s certificate that you have imported into the CA store. If the public keys match key, the client or other device’s certificate is considered legitimate.

In web browsers, the CA store includes trusted root CAs that can be used to establish trust with servers that have certificates signed by the issuing CAs. In an SSL forward proxy deployment, FortiADC acts as a proxy for the client, so you might want to import client browser CAs, create a CA group, and create a certficate verification policy to verify server certificates against this group. You can examine the CA store in common web browsers to come up with a good list of CAs to download and then import. The following list has links for some common web browsers:

• Apple iOS: https://support.apple.com/en-us/HT204132
• Google Chrome and Mozilla Firefox: https://wiki.mozilla.org/CA:IncludedCAs
• Microsoft Internet Explorer: https://technet.microsoft.com/en-us/library/dn265983.aspx

You must do one of the following:

• Import the certificates of the signing CA and all intermediary CAs to FortiADC’s store of CA certificates.
• In all personal certificates, include the full signing chain up to a CA that FortiADC knows in order to prove that the clients’ certificates should be trusted.
• If the signing CA is not known, that CA’s own certificate must likewise be signed by one or more other intermediary CAs, until both the FortiADC appliance and the client or device can demonstrate a signing chain that ultimately leads to a mutually trusted (shared “root”) CA that they have in common. Like a direct signature by a known CA, this proves that the certificate can be trusted.

Before you begin:

• You must have Read-Write permission for System settings.
• You must know the URL of an SCEP server or have downloaded the certificate and key files and be able to browse to them so that you can upload them.

To import a CA:

1. Go to System > Certificate > Manage Certificates.
2. Click the CA tab.
3. Click Import to display the configuration editor.
4. Complete the configuration as described in Table 98.
5. Click Import.

Creating a CA group

Create CA groups to facilitate the configuration of the certificate validator that is associated with a virtual server.

Include in the CA group all of the CAs for the pool of backend servers to be associated with a single virtual server.

Before you begin:

• You must have Read-Write permission for System settings.
• You must have already added the CAs to the CA certificate store.

To create a CA group:

1. Go to System > Certificate > Manage Certificates.
2. Click the CA Group tab.
3. Click Add to display the configuration editor.
4. Complete the configuration as described in Table 99.
5. Save the configuration.

Importing an Intermediate CA

The Intermediate CA store is for the Intermediate CA certificates that the backend servers would ordinarily use to complete the chain between the client certificate and the server certificate. HTTPS transactions use intermediate CAs when the server certificate is signed by an intermediate certificate authority (CA) rather than a root CA.

Before you begin:

• You must have Read-Write permission for System settings.
• You must know the URL of an SCEP server or have downloaded the certificate and key files and be able to browse to them so that you can upload them.

To import an intermediate CA:

1. Go to System > Certificate > Manage Certificates.
2. Click the Intermediate CA tab.
3. Click Import to display the configuration editor.
4. Complete the configuration as described in Table 100.
5. Click Import.

Creating an Intermediate CA group

You select an Intermediate CA group configuration object in the profile configuration for a virtual server, so you should configure in the group all the Intermediate CAs that would be needed by the backend servers that belong to a single virtual server.

Before you begin:

• You must have Read-Write permission for System settings.
• You must have already added the Intermediate CAs to the Intermediate CA certificate store.

To create an Intermediate CA group:

1. Go to System > Certificate > Manage Certificates.
2. Click the Intermediate CA Group tab.
3. Click Add to display the configuration editor.
4. Complete the configuration as described in Table 101.
5. Save the configuration.

Using OCSP

You can import a certificate that is maintained in a remote location using Online Certificate Status Protocol (OCSP). OCSP enables you to validate or revoke certificates by query, rather than by importing certificate revocation list (CRL) files. Since distributing and installing CRL files can be a considerable burden in large organizations, and because delay between the release and install of the CRL represents a vulnerability window, this can often be preferable.

To use OCSP queries, you must first install the certificates of trusted OCSP servers.

Before you begin:

• You must have Read-Write permission for System settings.
• You must know the URL of an OCSP server or have downloaded the certificate and key files and be able to browse to them so that you can upload them.

To add a remote certificate:

1. Go to System > Certificate > Manage Certificates.
2. Click the Remote tab.
3. Click Import to display the configuration editor.
4. Complete the configuration as described in Table 102.
5. Save the configuration.

Using CRLs

A certificate revocation lists (CRL) is a file that contains a list of revoked certificates, their serial numbers, and their revocation dates. The file also contains the name of the issuer of the CRL, the effective date, and the next update date. By default, the shortest validity period of a CRL is one hour.

Some potential reasons for certificates to be revoked include:

• A CA server was hacked and its certificates are no longer trustworthy.
• A single certificate was compromised and is no longer trustworthy.
• A certificates has expired and is not supposed to be used past its lifetime.

You can upload a CRL file or specify a URL for the CRL file.

Online certificate status protocol (OCSP) is an alternative to CRL. OCSP is useful when you do not want to deploy CRL files, for example, or want to avoid the public exposure of your PKI structure even if it is only invalid certificates.

Before you begin:

• You must have Read-Write permission for System settings.
• You must know the URL of a CRL server or have downloaded the CRL file and be able to browse to it so that you can upload it.

To create a CRL:

1. Go to System > Certificate > Manage Certificates.
2. Click the CRL tab.
3. Click Import to display the configuration editor.
4. Complete the configuration as described in Table 103.
5. Save the configuration.

Configuring a certificate verification object

To be valid, a client certificate must meet the following criteria:

• Must not be expired or not yet valid
• Must not be revoked by either certificate revocation list (CRL) or, if enabled, online certificate status protocol (OCSP)
• Must be signed by a certificate authority (CA) whose certificate you have imported into the FortiADC appliance
• Must contain a CA field whose value matches a CA’s certificate
• Must contain an Issuer field whose value matches the Subject field in a CA’s certificate

Certificate verification rules specify the CA certificates to use when validating client certificates, and they specify a CRL and/or OCSP server, if any, to use for certificate revocation checking.

You select a certificate verification configuration object in the profile configuration for a virtual server. If the client presents an invalid certificate during the authentication phase of a SSL/TLS session initiation, the FortiADC system will not allow the connection.

Before you begin:

• You must have Read-Write permission for System settings.
• You must have already created a CA group and OCSP or CRL configuration.

Ater you have configured a certificate verification object, you can include it in a virtual server profile or a real server SSL profile, and it will be used to validate certificates presented to FortiADC.

To configure a certificate verification object:

1. Go to System > Certificate > Verify.

The configuration page displays the Verify tab.

2. Click Add to display the configuration editor.
3. Complete the configuration as described in Table 104.
4. Save the configuration.