SSL Traffic Management

About OCSP stapling

When you create a Client SSL profile, you can specify OCSP stapling to improve the certification response time. OCSP stapling is when a TLS server (acting as OCSP client) asks the OCSP server for a valid revocation status of its TLS certificate ahead of time and "staples" the signed OCSP response to the TLS handshake. The TLS client sees the stapled OCSP response and verifies the signature, thus validating the TLS server’s certificate and eliminating the round trip at the client for fetching the certificate status. It also helps protect the identity of the client.

By default, OCSP stapling is disabled. You can enable OCSP stapling by selecting an OCSP Stapling profile, when you create a Client SSL profile. There is no default OCSP Stapling profile, so you must create one that specifies the parameters you want to use. For example, the default OCSP stapling profile setting is to use a DNS resolver to fetch the OCSP response, and you must specify the DNS resolver to use. Alternatively, you can choose to use a proxy server to fetch the OCSP response, and then you must specify the proxy server pool. After you create and save an OSCP Stapling profile, it appears in the OCSP Stapling Parameters list on the Client SSL profile screen.

Creating an OCSP stapling profile

Ensure that you configure a proxy server pool or a DNS resolver.

When you create an OCSP stapling profile and assign it to a client SSL profile, you speed up the time it takes for the client to get the certificate revocation status of the BIG-IP system.

On the Main tab, click Local Traffic > Profiles > SSL > OCSP Stapling. The OCSP Stapling list screen opens.
Click Create. The new OCSP Stapling Profile screen opens.
From the General Properties list, select Advanced.
In the Name field, type a unique name for the OCSP stapling profile.

For the Use Proxy Server check box, select one of the following options:

Option	Description
Select	If you want the BIG-IP system to use the Proxy Server Pool. Use when there are one or more servers that can proxy a HTTP request to an external server and fetch the response.
Clear (default)	If you want to use the DNS Resolver. Use when the OCSP responder can be reached on one of BIG-IP interfaces.

In the Proxy Server Pool/DNS Resolver field, select the proxy server pool/DNS resolver used for fetching the OCSP response.
In the Trusted Certificate Authorities field, select the name of the file containing a trusted Certificate Authority (CA) certificate used to sign the responder's certificate.
In the Trusted Responders field, select the name of a certificate to use to verify the response from the OCSP responder.
In the Responder URL field, type the name of a URL that will override the OCSP responder URL obtained from the certificate's AIA extension. This must be a HTTP or HTTPS-based URL.
In the Signer Certificate field, select a certificate corresponding to the key used for signing the OCSP request.
In the Signer Key field, select a key to use to sign an OCSP request.
In the Signer Key Passphrase field, type the passphrase of the key used to sign an OCSP request.
In the Sign Hash field, select the hash algorithm used to sign an OCSP request. The default is SHA256.
Note: This is not the algorithm used in the certificate itself. It is what the OCSP responder will use when validating the request.
In the Timeout field, type a time interval for the BIG-IP system to wait before dropping the connection to the OCSP responder.
In the Clock Skew field, type a value for the maximum tolerable absolute difference between the clocks of the responder and the BIG-IP system.
In the Status Age field, type a value for the maximum allowed lag time in the OCSP response that the BIG-IP system accepts. If you type 0, the validation is skipped. The default value is 86400.
In the Cache Timeout field, select a value that specifies the lifetime of the OCSP response. The default is Indefinite, indicating that the response validity period takes precedence.
In the Cache Error Timeout field, type a value for how long a BIG-IP system will cache an error response.
In the Options field, if necessary, select the Strict Responder Certificate Checking check box for the system to check the responder's certificate for the OCSP signing extension.
Click Finished.

About SSL traffic management

You can manage the way that the BIG-IP system processes SSL application traffic by configuring two types of SSL profiles: A Client SSL profile, a Server SSL profile, or both. These profiles affect the way that the system manages SSL traffic passing through the system.

When you configure Client SSL or Server SSL profiles and assign them to a virtual server, the BIG-IP system offloads SSL processing from the destination server. This offloading not only conserves resource on destination servers, but enables the BIG-IP system to customize SSL traffic processing according to your configuration specifications.

About SSL offload

When you want the BIG-IP system to process application traffic over SSL, you can configure the system to perform the SSL handshake that destination servers normally perform. This ability for the BIG-IP system to offload SSL processing from a destination server is an important feature of the BIG-IP system.

The most common way to configure the BIG-IP system is to create a Client SSL profile, which makes it possible for the BIG-IP system to decrypt client requests before sending them on to a server, and encrypt server responses before sending them back to the client.

Within a Client SSL profile specifically, you can specify multiple certificate/key pairs, one per key type. This enables the system to accept all types of cipher suites that a client might support as part of creating a secure connection. The system then decrypts the client data, manipulates any headers or payload according to the way that you configured the Client SSL profile, and by default, sends the request in clear text to the target server for processing.

For those sites that require enhanced security on their internal network, you can configure a Server SSL profile. With a Server SSL profile, the BIG-IP system re-encrypts the request before sending it to the destination server. When the server returns an encrypted response, the BIG-IP system decrypts and then re-encrypts the response, before sending the response back to the client.

Creating a custom Client SSL profile

You create a custom Client SSL profile when you want the BIG-IP system to terminate client-side SSL traffic for the purpose of decrypting client-side ingress traffic and encrypting client-side egress traffic. By terminating client-side SSL traffic, the BIG-IP system offloads these decryption/encryption functions from the destination server. When you perform this task, you can specify multiple certificate key chains, one for each key type (RSA, DSA, and ECDSA). This allows the BIG-IP system to negotiate secure client connections using different cipher suites based on the client's preference.

Important: At a minimum, you must specify a certificate key chain that includes an RSA key pair. Specifying certificate key chains for DSA and ECDSA key pairs is optional, although highly recommended.

Important: If you create multiple Client SSL profiles and assign them to the same virtual server, then for each of the following profile settings, you must configure the same value in each profile. For example, if the Frequency setting in one profile is set to once, then the Frequency setting in all other Client SSL profiles for that virtual server must be set to once.

Ciphers
Client Certificate
Frequency
Certificate Chain Traversal Depth
Certificate Revocation List (CRL)
Trusted Certificate Authorities
Advertised Certificate Authorities

On the Main tab, click Local Traffic > Profiles > SSL > Client. The Client profile list screen opens.
Click Create. The New Client SSL Profile screen opens.
In the Name field, type a unique name for the profile.
From the Parent Profile list, select clientssl.
Select the Custom check box. The settings become available for change.
Using the Certificate Key Chain setting, specify one or more certificate key chains:
1. From the Certificate list, select a certificate name. This is the name of a certificate that you installed on the BIG-IP system. If you have not generated a certificate request nor installed a certificate on the BIG-IP system, you can specify the name of an existing certificate, default.
2. From the Key list, select the name of the key associated with the certificate specified in the previous step. This is the name of a key that you installed on the BIG-IP system. If you have not installed a key on the BIG-IP system, you can specify the name of an existing key, default.
3. From the Chain list, select the chain that you want to include in the certificate key chain. A certificate chain can contain either a series of public key certificates in Privacy Enhanced Mail (PEM) format or a series of one or more PEM files. A certificate chain can contain certificates for Intermediate certificate Authorities (CAs).
  Note: The default self-signed certificate and the default CA bundle certificate are not appropriate for use as a certificate chain.
4. For the Passphrase field, type a string that enables access to SSL certificate/key pairs that are stored on the BIG-IP system with password protection. This setting is optional. For added security, the BIG-IP system automatically encrypts the pass phrase itself. This pass phrase encryption process is invisible to BIG-IP system administrative users.
5. From the OCSP Stapling Parameters list, select an OCSP stapling profile. This setting is optional. To enable OCSP stapling, you must create an OCSP Stapling profile, which you can then select from this list.
6. Click Add and repeat the process for all certificate key chains that you want to specify.
  Sample configuration with three key types specified
  The result is that all specified key chains appear in the box.
If you want to use a cipher suite other than DEFAULT:
1. From the Configuration list, select Advanced.
2. For the Ciphers setting, type the name of a cipher. You can specify a particular string to indicate the ciphers that you want the BIG-IP system to use for SSL negotiation, or you can specify ciphers that you do not want the system to use. Examples of cipher values that you can specify are ECDHE and DEFAULT:!ECDHE.
Configure all other profile settings as needed.
Click Finished.

After performing this task, you can see the custom Client SSL profile in the list of Client SSL profiles on the system.

You must also assign the profile to a virtual server.

Creating a custom Server SSL profile

With a Server SSL profile, the BIG-IP system can perform decryption and encryption for server-side SSL traffic.

On the Main tab, click Local Traffic > Profiles > SSL > Server. The SSL Server profile list screen opens.
Click Create. The New Server SSL Profile screen opens.
In the Name field, type a unique name for the profile.
Select serverssl in the Parent Profile list.
From the Configuration list, select Advanced.
Select the Custom check box. The settings become available for change.
From the Certificate list, select the name of an SSL certificate on the BIG-IP system.
From the Key list, select the name of an SSL key on the BIG-IP system.
In the Pass Phrase field, select a pass phrase that enables access to the certificate/key pair on the BIG-IP system.
From the Chain list, select the name of an SSL chain on the BIG-IP system.
If you want to use a cipher suite other than DEFAULT:
1. From the Configuration list, select Advanced.
2. For the Ciphers setting, type the name of a cipher. You can specify a particular string to indicate the ciphers that you want the BIG-IP system to use for SSL negotiation, or you can specify ciphers that you do not want the system to use. Examples of cipher values that you can specify are ECDHE and DEFAULT:!ECDHE.
Select the Custom check box for Server Authentication.
Modify the settings, as required.
Click Finished.

To use this profile, you must assign it to a virtual server.

Assigning SSL profiles to a virtual server

The final task in the process of implementing SSL profiles is to assign the SSL profile to a virtual server. If the relevant virtual server does not yet exist, you can assign the SSL profile (or profiles) to the virtual server when you create it.

On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
Click the name of a virtual server.
From the Configuration list, select Advanced.
For the SSL Profile (Client) setting, from the Available list, select the name of the Client SSL profile you previously created, and using the Move button, move the name to the Selected list.
For the SSL Profile (Server) setting, from the Available list, select the name of the Server SSL profile you previously created, and using the Move button, move the name to the Selected list.
Click Update to save the changes.

After you perform this task, you must assign the profile to a virtual server.

Cipher support on the BIG-IP system

The BIG-IP system supports a large set of cipher suites that offer various combinations of encryption algorithms and authentication mechanisms, including RSA (Rivest Shamir Adleman), DSA (Digital Signature Algorithm), and ECDSA (Elliptic Curve Digital signature Algorithm).

Within an SSL profile, you can specify either a particular string to indicate the cipher suites that you want the BIG-IP system to use or not use for SSL negotiation. If you do not specify a cipher string, the BIG-IP system uses the default cipher string, DEFAULT. Examples of cipher values that you can specify are: ECDHE, or DEFAULT:!ECDHE. The ECDHE and DEFAULT:!ECDHE values instruct the BIG-IP system to either negotiate with elliptic curve Diffie-Hellman Ephemeral (DHE) cipher suites, or negate the use of those cipher suites.

It is important to note that if you are assigning both a Client SSL and a Server SSL profile to the virtual server, the connections on each side of the BIG-IP system must use common ciphers. Otherwise, the handshake between the virtual server and the server fails and the connection closes.

The list of supported ciphers that you can specify varies depending on whether the transport layer being used is TCP or UDP.

Note: The following are not included in the DEFAULT cipher suite:

The DHE cipher suites
Elliptic curve ciphers with DSA

Viewing the list of supported ciphers

Before using this command, confirm that your user account grants you access to the advanced shell.

You perform this task when you want to display the full set of ciphers that the BIG-IP system supports.

Access the advanced shell on the BIG-IP system.
At the system prompt, type this command: tmm --clientciphers all The BIG-IP system displays the list of all supported ciphers.

Support for multiple key types

For client-side traffic specifically, you can configure a Client SSL profile to specify multiple certificate key chains on the BIG-IP system, one for each key type: RSA, DSA, and ECDSA. By configuring a Client SSL profile with different digital certificates and keys, the system can accept all types of cipher suites that clients might request as part of creating a secure connection. The system supports OCSP stapling for all certificate and key types.

Important: To ensure successful negotiation, the BIG-IP system requires you to specify an RSA-based certificate key chain at a minimum, to accommodate any RSA-based ciphers that the client presents. However, F5 Networks highly recommends that you also specify DSA and ECDSA certificate key chains.

About the DEFAULT cipher suite

The BIG-IP system supports a large suite of ciphers. Some of these ciphers are included in a default cipher suite named DEFAULT. The DEFAULT cipher suite appears as the default value in the Ciphers setting of the Client SSL and Server SSL profiles.

If you want the BIG-IP to accept ciphers that are not included in the DEFAULT cipher suite, or you want the system to reject ciphers that are included in the DEFAULT cipher suite, you can configure an SSL profile accordingly.

Viewing the list of DEFAULT ciphers

Before using this command, confirm that your user account grants you access to the advanced shell.

You perform this task when you want to display the entire list of ciphers included in the DEFAULT cipher set.

Access the advanced shell on the BIG-IP system.
At the system prompt, type this command: tmm --clientciphers DEFAULT The BIG-IP system displays a list of the ciphers included in the DEFAULT cipher set.

RSA ciphers in the DEFAULT cipher suite

This table lists the RSA ciphers in the DEFAULT cipher suite that include AES, DES, and RC4 ciphers.

Table 1. RSA ciphers in the DEFAULT cipher suite
Suite	Bits	Protocol	Cipher	MAC	Key Type
AES256-SHA256	256	TLS1.2	AES	SHA256	RSA
AES256-SHA	256	TLS1	AES	SHA	RSA
AES256-SHA	256	TLS1.1	AES	SHA	RSA
AES256-SHA	256	TLS1.2	AES	SHA	RSA
AES256-SHA	256	DTLS1	AES	SHA	RSA
AES128-SHA256	128	TLS1.2	AES	SHA256	RSA
AES128-SHA	128	TLS1	AES	SHA	RSA
AES128-SHA	128	TLS1.1	AES	SHA	RSA
AES128-SHA	128	TLS1.2	AES	SHA	RSA
AES128-SHA	128	DTLS1	AES	SHA	RSA
DES-CBC3-SHA	192	TLS1	DES	SHA	RSA
DES-CBC3-SHA	192	TLS1.1	DES	SHA	RSA
DES-CBC3-SHA	192	TLS1.2	DES	SHA	RSA
DES-CBC3-SHA	192	DTLS1	DES	SHA	RSA
RC4-SHA	128	TLS1	RC4	SHA	RSA
RC4-SHA	128	TLS1.1	RC4	SHA	RSA
RC4-SHA	128	TLS1.2	RC4	SHA	RSA

ECDHE ciphers in the DEFAULT cipher suite

This table lists all ECDHE ciphers in the DEFAULT cipher suite. In the DEFAULT cipher suite, Elliptic Curve (EC) ciphers are the only ciphers that include DHE as the key exchange method.

Table 2. ECDHE ciphers in the DEFAULT cipher suite
Suite	Bits	Protocol	Cipher	MAC	Key Type
ECDHE-RSA-AES256-SHA384	256	TLS1.2	AES	SHA384	ECDHE_RSA
ECDHE-RSA-AES256-CBC-SHA	256	TLS1	AES	SHA	ECDHE_RSA
ECDHE-RSA-AES256-CBC-SHA	256	TLS1.1	AES	SHA	ECDHE_RSA
ECDHE-RSA-AES256-CBC-SHA	256	TLS1.2	AES	SHA	ECDHE_RSA
ECDHE-RSA-AES128-SHA256	128	TLS1.2	AES	SHA56	ECDHE_RSA
ECDHE-RSA-AES128-CBC-SHA	128	TLS1	AES	SHA	ECDHE_RSA
ECDHE-RSA-AES128-CBC-SHA	128	TLS1.1	AES	SHA	ECDHE_RSA
ECDHE-RSA-AES128-CBC-SHA	128	TLS1.2	AES	SHA	ECDHE_RSA
ECDHE-RSA-DES-CBC3-SHA	192	TLS1	DES	SHA	ECDHE_RSA
ECDHE-RSA-DES-CBC3-SHA	192	TLS1.1	DES	SHA	ECDHE_RSA
ECDHE-RSA-DES-CBC3-SHA	192	TLS1.2	DES	SHA	ECDHE_RSA

About Diffie-Hellman Ephemeral key exchange

The BIG-IP system supports the Diffie-Hellman Ephemeral key exchange method, as well as other Diffie-Hellman variations. A Diffie–Hellman key exchange method is an alternative to RSA key exchange and allows the client and the BIG-IP system to establish a shared secret session key to use for communication.

Supported Diffie-Hellman variations

The BIG-IP system supports all three Diffie-Hellman key exchange methods. They are:

Diffie-Hellman Ephemeral (DHE): Diffie-Hellman Ephemeral uses temporary public keys. The authenticity of a temporary key can be verified by checking the digital signature included in the key exchange messages. The key exchange messages are signed using either the RSA or DSA algorithms, depending on the cipher being used. For example, DHE-RSA uses RSA to sign the key exchange messages. DHE includes Perfect Forward Secrecy (PFS), which means that a compromise of the system's long-term signing key does not affect the privacy of past sessions. Like FIPS, DHE prevents private key disclosure.
Diffie-Hellman (DH): Diffie-Hellman embeds the system's public parameter in the certificate, and the CA then signs the certificate. That is, the certificate contains the Diffie-Hellman public-key parameters, and those parameters never change.
Anonymous Diffie-Hellman (ADH): Anonymous Diffie-Hellman uses DH, but without authentication. The keys used in the exchange are not authenticated, resulting in keys being susceptible to security attacks.

About Perfect-Forward-Privacy

The Diffie-Hellman Ephemeral (DHE) key exchange method provides Perfect Forward Privacy (PFP). With standard Diffie-Hellman, multiple key exchanges all use the same session key, which can compromise security. By contrast, DHE uses PFP, which generates a disposable key per session and thereby ensures that the same session key is never used twice. No key remains to be disclosed, and if the private key of the server is discovered, past communication remains secure.

About DHE cipher support

Because Diffie-Hellman key exchange methods do not include authentication, use of Diffie-Hellman Ephemeral (DHE) requires that it be paired with an authentication mechanism. The DHE ciphers that the BIG-IP system supports are:

DHE-RSA-* (Diffie-Hellman Ephemeral-RSA)
DHE-DSS-* (Diffie-Hellman Ephemeral-DSS)
ECDHE-RSA-* (Elliptic Curve Diffie-Hellman Ephemeral-RSA)
ECDHE-ECDSA-* (Elliptic Curve Diffie-Hellman Ephemeral-DSA)

Note: For DHE, the DEFAULT cipher suite includes Elliptic Curve cipher suites only. DHE ciphers for RSA and DSS encryption are not included.

Viewing a list of supported DHE ciphers

Before using this command, confirm that your user account grants you access to the advanced shell.

You perform this task when you want to display a specific set of ciphers that the BIG-IP system supports.

Access the advanced shell on the BIG-IP system.
At the system prompt, type the command tmm --clientciphers ciphers.
1. For example, to see a list of DHE+DES ciphers, type tmm --clientciphers DHE:DHE_DSS The BIG-IP system displays the list of all DHE+DES ciphers that the BIG-IP system supports:
  Supported DHE+DES ciphers on the BIG-IP system
2. To see a list of ECDHE ciphers, type tmm --clientciphers ECDHE:ECDHE_ECDSA. The BIG-IP system displays the list of all ECDHE ciphers that the BIG-IP system supports:
  Supported ECDHE ciphers on the BIG-IP system

Specifying the use of Diffie-Hellman ciphers

Use this task to modify an existing Client SSL profile to enable support for Diffie-Hellman key exchange.

On the Main tab, click Local Traffic > Profiles > SSL > Client or Local Traffic > Profiles > SSL > Server. The Client SSL or Server SSL profile list screen opens.
In the Name column, click the name of the profile you want to modify.
Select the Custom check box. The settings become available for change.
To specify DHE ciphers:
1. From the Configuration list, select Advanced.
2. In the Ciphers field, type DHE:DHE_DSS.
Click Update.

After you perform this task and assign the profile to a virtual server, the BIG-IP uses the DHE key exchange method to establish secure communication with the relevant client or server.

Viewing DHE key exchange statistics

You can use the Traffic Management Shell (tmsh) to view statistics about the use of Diffie-Hellman ciphers in SSL negotiation.

Access the system prompt on the BIG-IP system.
From the BIG-IP system prompt, type tmsh show ltm profile client-ssl profile_name. An example of a name for a profile that specifies DHE ciphers is my_dhe_profile.

After you type this command, the BIG-IP system displays output such as the following. In this example, the profile statistics show that Diffie-Hellman Ephemeral (DHE) with RSA certificates has been used once:

Sample profile statistics for key exchange method

About Elliptic Curve encryption

The BIG-IP system supports Elliptic Curve Cryptography (ECC). Because Elliptic Curve key sizes are significantly smaller than those of other key types, ECC is ideally suited for smaller, mobile devices for which key storage is an issue. On the BIG-IP system, ECC works with the SSL offload feature.

About Elliptic Curve cipher support

The BIG-IP system supports multiple ciphers that use Elliptic Curve Cryptography (ECC) encryption with Diffie-Hellman key exchange. On the BIG-IP system, EC is used with DHE to establish the shared secret; however, the subsequent bulk encryption of data cannot be done with any ECC-based algorithm and must be done using conventional crypto algorithms such as AES and 3DES. For example, a typical Elliptic Curve cipher is: ECDHE-RSA-AES128-CBC-SHA.

The specific ECC ciphers that the BIG-IP system supports are:

ECDHE-RSA-*
ECDHE-ECDSA-*
ECDH-ECDSA-*

Because ECC with Diffie-Hellman does not include a mechanism for digitally signing handshake messages, the RSA or DSA algorithms are used to digitally sign the handshake messages to thwart Man-in-the-Middle attacks. For example, an ECDHE-ECDSA-* cipher suite uses the ECC DSA certificate specified in the Client SSL profile to digitally sign the handshake messages.

Note: Although the BIG-IP system supports both the prime256v1 and secp384r1 curve names, only prime256v1 can be associated with an SSL profile. Also note that Elliptic Curve ciphers with DSA are not included in the DEFAULT cipher suite.

Specifying the use of Elliptic Curve ciphers

Use this task to modify an existing Client SSL profile to enable support for Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

On the Main tab, click Local Traffic > Profiles > SSL > Client or Local Traffic > Profiles > SSL > Server. The Client SSL or Server SSL profile list screen opens.
In the Name column, click the name of the profile you want to modify.
Select the Custom check box. The settings become available for change.
To specify ECDHE ciphers:
1. From the Configuration list, select Advanced.
2. In the Ciphers field, type ECDHE.
Click Update.

After you perform this task and assign the profile to a virtual server, the BIG-IP system uses the ECDHE key exchange method to establish secure communication with the relevant client or server.

Viewing ECDH key exchange statistics

You can use the Traffic Management Shell (tmsh) to view statistics about the use of Elliptic Curve Diffie-Hellman ciphers in SSL negotiation.

Access the system prompt on the BIG-IP system.
From the BIG-IP system prompt, type tmsh show ltm profile client-ssl profile_name | grep ECDH. An example of a name for a profile that specifies DHE ciphers is my_ecdh_profile.

After you type this command, the BIG-IP system displays output such as the following. In this example, the profile statistics show that ECDH with RSA certificates has been used six times:

Sample profile statistics for key exchange method

Client and server certificate authentication

There are several settings that you can configure on an SSL profile to manage client-side SSL authentication.

Requirement for a client certificate

You can cause Local Traffic Manager to handle authentication of clients or servers in certain ways. For client-side processing, the possible behaviors are:

Ignore: Ignore a certificate (or lack of one) and therefore never authenticate the client. The Ignore option is the default, and when used, causes any per-session authentication setting to be ignored.
Require: Require a client to present a valid and trusted certificate before granting access.
Request: Request and verify a client certificate. In this case, the SSL profile always grants access regardless of the status or absence of the certificate.

Warning: If you are using the LDAP-based client authorization feature, use of the Request or Ignore values can sometimes cause a connection to terminate.

Tip: The Request value works well with the header insertion feature. Configuring the SSL profile to insert client certificate information into an HTTP client request, and to authenticate clients based on the Request option, enables the BIG-IP system or a server to then perform actions such as redirecting the request to another server, sending different content back to the client, or performing client certificate or session ID persistence.

For server-side processing, the possible behaviors are:

Require: Require a server to present a valid and trusted certificate before granting access.
Ignore: Ignore a certificate (or lack of one) and therefore never authenticate the server. The Ignore value is the default setting, and when used, causes any per-session authentication setting to be ignored.

Frequency of authentication

You can configure an SSL profile to require authentication either once per SSL session (once), or once upon each subsequent re-use of an SSL session (always). The default setting for this option is once.

Whether you set this value to once or always depends on your application. A well-designed web application should need to verify a certificate only once per session. F5 recommends for performance reasons that you use the default setting (once) whenever possible.

You can modify the SSL profile to require authentication not only once per session, but also upon each subsequent re-use of an SSL session.

Certificate chain traversal depth

You can use the Certificate Chain Traversal Depth setting of an SSL profile to configure the maximum number of certificates that can be traversed in the certificate chain. The default value is 9. If a longer chain is provided, and the client has not been authenticated within this number of traversals, client or server certificate verification fails. If the authentication depth value is set to zero, then only the client or server certificate, and one of the chain files, are examined.

Trusted certificate authorities

For client-side and server-side SSL processing, you can use the Trusted Certificate Authorities setting on an SSL profile to configure an SSL profile to verify certificates presented by a client or a server. You can specify a client trusted CAs file name, which the BIG-IP system then uses to verify client or server certificates. If you do not configure a trusted CAs file, the system uses a default file.

The trusted CAs file that you specify for certificate verification contains one or more certificates, in Privacy Enhanced Mail (PEM) format. Built manually, this file contains a list of the client or server certificates that the SSL profile will trust. If you do not specify a trusted CAs file, or the specified trusted CAs file is not accessible to the BIG-IP system, the system uses the default file name.

Advertised certificate authorities

For client-side profiles only, if you intend to configure the SSL profile to require or request client certificates for authentication, you will want the profile to send to clients a list of CAs that the BIG-IP system is likely to trust.

This list, known as the Client Certificate CA file, is different from the client Trusted CAs file. This is because, in some cases, you might have a client that does not possess a valid client certificate, in which case you might not want to reveal the actual list of CAs that the BIG-IP system trusts. The client certificate CA file solves this problem by allowing the BIG-IP system to advertise a list of CAs that is different from the actual client trusted CAs file configured as part of certificate verification.

Although the contents of the Client Certificate CA file can differ from that of the Client Trusted CAs file, it is best, for compatibility reasons, to set the Advertised Certificate Authorities setting to match the Trusted Certificate Authorities setting. This is because modern browsers might not permit SSL session negotiation to proceed if the peer that requests the client certificate does not provide a list of trusted CAs.

Note: The maximum size of native SSL handshake messages that Local Traffic Manager allows is 14304 bytes. Consequently, if the SSL handshake is negotiating a native cipher and the total length of all messages in the handshake exceeds this byte threshold, the handshake can fail. Although typical use does not cause message length to exceed this threshold, we recommend that when configuring a Client SSL profile to request or require client certificates, you avoid specifying large numbers of certificates through the Advertised Certificate Authorities setting. This minimizes the number of certificates that must be exchanged during a Client SSL handshake.

Name-based authentication

For server-side profiles only, Local Traffic Manager supports name-based authentication, which guards against man-in-the-middle attacks. When you configure the Authenticate Name setting for a server-side profile, Local Traffic Manager checks the name against the Common Name (CN) listed in the certificate that the target server presents to the BIG-IP system. If the name attribute that you specify does not match the CN in the server certificate, Local Traffic Manager closes the connection. An example of a CN is www.f5.com.

Certificate revocation

The Certificate Revocation List (CRL) setting of an SSL profile allows Local Traffic Manager to use CRLs to check revocation status of a certificate prior to authenticating a client or server.

Important: CRL files can become outdated, and might need to be updated as often as every day, or as seldom as every 30 days. If your CRL file is out-of-date, Local Traffic Manager rejects all certificates, both valid and invalid. For this reason, it is important to keep your CRL files up-to-date at all times. You can do this by accessing the CRL in the /config/ssl/ssl.crl directory and then using the openssl crl command. For more information, see http://www.openssl.org/docs/.

As an alternative to using CRLs, you can use the Online Certificate Status Protocol (OCSP) feature, which ensures up-to-date information on certificate revocation status.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IP AAM

BIG-IP APM

BIG-IP GTM

BIG-IP Analytics

BIG-IP Link Controller

BIG-IP LTM

BIG-IP PEM

BIG-IP AFM

BIG-IP ASM

About OCSP stapling

Creating an OCSP stapling profile

About SSL traffic management

About SSL offload

Creating a custom Client SSL profile

Creating a custom Server SSL profile

Assigning SSL profiles to a virtual server

Cipher support on the BIG-IP system

Viewing the list of supported ciphers

Support for multiple key types

About the DEFAULT cipher suite

Viewing the list of DEFAULT ciphers

RSA ciphers in the DEFAULT cipher suite

ECDHE ciphers in the DEFAULT cipher suite

About Diffie-Hellman Ephemeral key exchange

Supported Diffie-Hellman variations

About Perfect-Forward-Privacy

About DHE cipher support

Viewing a list of supported DHE ciphers

Specifying the use of Diffie-Hellman ciphers

Viewing DHE key exchange statistics

About Elliptic Curve encryption

About Elliptic Curve cipher support

Specifying the use of Elliptic Curve ciphers

Viewing ECDH key exchange statistics

Client and server certificate authentication

Requirement for a client certificate

Frequency of authentication

Certificate chain traversal depth

Trusted certificate authorities

Advertised certificate authorities

Name-based authentication

Certificate revocation

Have a Question?

Follow Us

About F5

Education

F5 Sites

Support Tasks