Applies To:

Show Versions Show Versions

Manual Chapter: SSL Profiles
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

About SSL profiles

BIG-IP Local Traffic Manager offers several features that you can use to intelligently control your SSL traffic. Some of the SSL traffic-management features are:

  • The ability to authenticate clients and servers to maintain secure connections between a client system and the BIG-IP system, and between the BIG-IP system and a target web server
  • The ability to offload SSL certificate-verification tasks from client and server systems

The primary way that you can control SSL network traffic is by configuring a Client or Server SSL profile:

  • A Client profile is a type of traffic profile that enables Local Traffic Manager to accept and terminate any client requests that are sent by way of a fully SSL-encapsulated protocol. Local Traffic Manager supports SSL for both TCP and UDP protocols.
  • A Server profile is a type of profile that enables Local Traffic Manager to initiate secure connections to a target web server.

Managing SSL traffic requires you to complete these tasks:

  • Install a key/certificate pair on the BIG-IP system for terminating client-side secure connections.
  • Configure a profile, and then associate that profile with a virtual server. You configure a profile using the Configuration utility.
  • Associate the profile with a virtual server.

Client-side and server-side traffic

With Local Traffic Manager, you can enable SSL traffic management for either client-side traffic or server-side traffic.

Client-side traffic refers to connections between a client system and the BIG-IP system. Server-side traffic refers to connections between the BIG-IP system and a target server system:

Managing client-side SSL traffic
When you enable the BIG-IP system to manage client-side SSL traffic, Local Traffic Manager terminates incoming SSL connections by decrypting the client request. Local Traffic Manager then sends the request, in clear text, to a target server. Next, Local Traffic Manager retrieves a clear-text response (such as a web page) and encrypts the request, before sending the web page back to the client. During the process of terminating an SSL connection, Local Traffic Manager can, as an option, perform all of the SSL certificate verification functions normally handled by the target web server.
Managing server-side SSL traffic
When you enable Local Traffic Manager to manage server-side SSL traffic, Local Traffic Manager enhances the security of your network by re-encrypting a decrypted request before sending it on to a target server. In addition to this re-encryption, Local Traffic Manager can, as an option, perform the same verification functions for server certificates that Local Traffic Manager can for client certificates.

Certificate revocation

Local Traffic Manager can check to see if a certificate being presented by a client or server is revoked. A revoked client certificate indicates to the BIG-IP system that the system should fail to authenticate the client.

The BIG-IP system supports two industry-standard methods for checking the revocation status of a certificate. These two methods are:

Certificate revocation lists (CRLs).
CRLs are a method that the BIG-IP system can use to check on whether a certificate being presented to the BIG-IP system is revoked. This CRL support is in the form of a CRL file and a CRL path. The BIG-IP system enables you to configure one CRL file and path for the client-side profile, and one CRL file and path for the server-side profile. You configure the use of CRLs through an SSL profile. For more information, see Client and server authentication.
Online Certificate Status Protocol (OCSP)
Unlike the use of CRLs, OCSP ensures that the revocation status of a certificate is always up-to-date. You configure OCSP through an Authentication profile.

Certificate name

The value of the Certificate setting is the name of the certificate that you installed on the BIG-IP system for the purpose of authenticating client-side or server-side SSL connections. 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.

Key name

You can specify the name of the key that you installed on the BIG-IP system for the purpose of authenticating either client-side or server-side SSL connections. If you have not generated a key request nor installed a key on the BIG-IP system, you can specify the name of an existing key, default.

Pass phrase

You can specify a string that enables access to the SSL certificate/key pair. This feature is optional.

For added security, when you use these settings, Local Traffic Manager automatically encrypts the pass phrase itself. This pass phrase encryption process is invisible to BIG-IP system users, so there is no need to enable it.

Note that the length of an encrypted pass phrase exceeds the length of the unencrypted pass phrase. An example of an encrypted pass phrase is MDEyMzQ1Njc4OWFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6.

Certificate chain

In any client verification process, not only does the BIG-IP system need to authenticate the client, but the client might need to authenticate the BIG-IP system. However, a certificate that the BIG-IP system uses to authenticate itself to a client is sometimes signed by an intermediate CA that is not trusted by that client. In this case, the BIG-IP system might need to use a certificate chain. The profile enables you to specify the name of a specific certificate chain file. Note that the certificate files that make up the chain file must be in PEM format.

Trusted client CAs

For client-side SSL processing, you can 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.

SSL ciphers

For each SSL profile, you can specify the ciphers available for SSL connections. When configuring ciphers, you must ensure that the ciphers configured for the SSL profile match those of the client sending a request, or of the server sending a response.

Note: The list of supported ciphers varies depending on whether the transport layer being used is TCP or UDP.

For example, a client might connect to and successfully establish an SSL connection to an SSL profile that is configured to use both client-side and server-side SSL. After the client sends additional data (such as an HTTP request), the SSL profile attempts to establish an SSL connection to a server. However, the SSL profile might be configured to enable only 3DES ciphers for server-side SSL, and the servers might be configured to accept only RC4 ciphers. In this case, the SSL handshake between the SSL profile and the server fails because there are no common ciphers enabled. This results in the client connection being closed. If the client is using a browser, the user is likely to receive an error message indicating that the web page failed to load.

You can specify a string to indicate the available list of SSL ciphers, or you can use the default cipher string, DEFAULT.

Default ciphers for a Client SSL or Server SSL profile

This table lists the ciphers included in the cipher string DEFAULT, for both the Client SSL and Server SSL profiles:

Cipher Bits Protocols
RC4-SHA 128 SSL3, TLS1, TLS1.1, TLS1.2
AES128-SHA 128 SSL3, TLS1, TLS1.1, TLS1.2, DTLS1
AES256-SHA 256 SSL3, TLS1, TLS1.1, TLS1.2, DTLS1
AES128-SHA256 128 TLS1.2
AES256-SHA256 256 TLS1.2
DES-CBC3-SHA 192 SSL3, TLS1, TLS1.1, TLS1.2, DTLS1

Options

OpenSSL supports a set of SSL options and defect workarounds. You can enable these workarounds and options as settings of an individual client-side or server-side SSL profile. The default value for the Options setting is Options List. Retaining the default value enables one option, which is Don’t insert empty fragments.

Important: For security reasons, when you enable the Proxy SSL setting, the BIG-IP system automatically disables the Don’t insert empty fragments option. Disabling this option when Proxy SSL is enabled guards against a particular type of cryptographic attack.

Note that when configuring protocol versions, you must ensure that the protocol versions configured for the BIG-IP system match those of the system’s peer. That is, protocol versions specified in the client-side SSL profile must match those of the client, and protocol versions specified in the server-side SSL profile must match those of the server. Thus, for both client-side and server-side SSL connections, you can specify the protocol versions that you do not want the BIG-IP system to allow.

You can declare up to two of the three protocol versions to be invalid: SSLv2 , SSLv3, and TLSv1. If no protocol versions are specified, Local Traffic Manager allows all SSL protocol versions.

Note: F5 Networks recommends that, at a minimum, you specify protocol version SSLv2 as invalid.

Workarounds and other SSL options

This table lists and describes the possible workarounds and options that you can configure for an SSL profile.

SSL Attribute Description
Cipher server preference When the BIG-IP system chooses a cipher, this option uses the server's preferences instead of the client preferences. When this option is not set, the SSL server always follows the client’s preferences. When this option is set, the SSLv3/TLSv1 server chooses by using its own preferences. Due to the different protocol, for SSLv2 the server sends its list of preferences to the client, and the client always chooses the cipher.
Don’t insert empty fragments This option disables a countermeasure against a SSL 3.0/TLS 1.0 protocol vulnerability affecting CBC ciphers. These ciphers cannot be handled by certain broken SSL implementations. This option has no effect for connections using other ciphers. This is the default value for the Options list.
Note: For security reasons, this option is not available when you enable the Proxy SSL setting.
Ephemeral RSA This option uses ephemeral (temporary) RSA keys when doing RSA operations. According to the specifications, this is only done when an RSA key can only be used for signature operations (namely under export ciphers with restricted RSA key length). By setting this option, Local Traffic Manager always uses ephemeral RSA keys. This option breaks compatibility with the SSL/TLS specifications and can lead to interoperability problems with clients, and we therefore do not recommend it. You should use ciphers with EDH (ephemeral Diffie-Hellman) key exchange instead. This option is ignored for server-side SSL.
Microsoft session ID bug This option handles a Microsoft session ID problem.
Netscape CA DN bug workaround This option handles a defect regarding system instability. If the system accepts a Netscape® browser connection, demands a client cert, has a non-self-signed CA that does not have its CA in Netscape, and the browser has a certificate, then the system crashes or hangs.
Netscape challenge bug This option handles the Netscape challenge problem.
Netscape demo cipher change bug workaround This option deliberately manipulates the SSL server session resumption behavior to mimic that of certain Netscape servers (see the Netscape reuse cipher change bug workaround description). We do not recommend this option for normal use and it is ignored for server-side SSL processing.
Netscape reuse cipher change bug workaround This option handles a defect within Netscape-Enterprise/2.01, only appearing when connecting through SSLv2/v3 then reconnecting through SSLv3. In this case, the cipher list changes. First, a connection is established with the RC4-MD5 cipher list. If it is then resumed, the connection switches to using the DES-CBC3-SHA cipher list. However, according to RFC 2246, (section 7.4.1.3, cipher_suite) the cipher list should remain RC4-MD5. As a workaround, you can attempt to connect with a cipher list of DES-CBC-SHA:RC4-MD5 and so on. For some reason, each new connection uses the RC4-MD5 cipher list, but any re-connect ion attempts to use the DES-CBC-SHA cipher list. Thus Netscape, when reconnecting, always uses the first cipher in the cipher list.
No SSLv2 Do not use the SSLv2 protocol.
No SSLv3 Do not use the SSLv3 protocol.
No session resumption on renegotiation When Local Traffic Manager performs renegotiation as an SSL server, this option always starts a new session (that is, session resumption requests are only accepted in the initial handshake). The system ignores this option for server-side SSL processing.
N0 TLSv1 Do not use the TLSv1 protocol.
Microsoft big SSLV3 buffer This option enables a workaround for communicating with older Microsoft® applications that use non-standard SSL record sizes.
Microsoft IE SSLV2 RSA padding This option enables a workaround for communicating with older Microsoft® applications that use non-standard RSA key padding. This option is ignored for server-side SSL.
Passive close Specifies that the SSL filter helps prevent packets from getting into the TCP half-closed state by waiting for a connection shutdown from the server. This is a workaround for HTTP/1.0 and HTTP/0.9 clients that send an HTTP request followed by a FIN, which immediately closes the connection for server-SSL-only proxies. Instead of closing immediately, the proxy waits for the server to close.
PKCS1 check 1 This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect vulnerability to particular SSL server vulnerabilities. We do not recommend this option for normal use. The system ignores this option for client-side SSL processing.
PKCS1 check 2 This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect vulnerability to particular SSL server vulnerabilities. We do not recommend this option for normal use. The system ignores this option for client-side SSL processing.
Single DH use This option creates a new key when using temporary/ephemeral DH parameters. You must use this option if you want to prevent small subgroup attacks, when the DH parameters were not generated using strong primes (for example, when using DSA-parameters). If strong primes were used, it is not strictly necessary to generate a new DH key during each handshake, but we do recommend this. You should enable the Single DH use option whenever temporary/ephemeral DH parameters are used.
SSLEAY 080 client DH bug workaround This option enables a workaround for communicating with older SSLeay-based applications that specify an incorrect Diffie-Hellman public value length. This option is ignored for server-side SSL.
SSL Ref2 reuse cert type bug This option handles the SSL re-use certificate type problem.
TLS D5 bug workaround This option is a workaround for communicating with older TLSv1-enabled applications that specify an incorrect encrypted RSA key length. This option is ignored for server-side SSL.
TLS block padding bug workaround This option enables a workaround for communicating with older TLSv1-enabled applications that use incorrect block padding.
TLS rollback bug workaround This option disables version rollback attack detection. During the client key exchange, the client must send the same information about acceptable SSL/TLS protocol levels as it sends during the first hello. Some clients violate this rule by adapting to the server's answer. For example, the client sends an SSLv2 hello and accepts up to SSLv3.1 (TLSv1), but the server only understands up to SSLv3. In this case, the client must still use the same SSLv3.1 (TLSv1) announcement. Some clients step down to SSLv3 with respect to the server's answer and violate the version rollback protection. This option is ignored for server-side SSL.

Proxy SSL

In a typical setup where the BIG-IP system is positioned between the client and server systems, and SSL termination is configured, the client and server do not communicate directly to authenticate each other.

The Proxy SSL feature gives the client and server the ability to authenticate one another directly, yet still allows the BIG-IP system to inspect and manipulate payload data as needed.

To enable this feature, you must select this option for both the Client SSL and Server SSL profiles.

ModSSL options for use with iRules

You can enable or disable ModSSL method emulation. You enable ModSSL method emulation when the OpenSSL methods are inadequate. When you enable this, you can then write an iRule, using the HTTP::header insert_modssl_fields command, which inserts some of the ModSSL options as headers into HTTP requests. The options that you can insert into an HTTP request are listed in this table.

Header Type Header Name and Format Description
Certificate status SSLClientCertStatus: [status] The status of the client certificate. The value of [status] can be NoClientCert, OK, or Error. If status is NoClientCert, only this header is inserted into the request. If status is Error, the error is followed by a numeric error code.
Certificate version SSLClientCertVersion: [version] The version of the certificate.
Certificate serial number SSLClientCertSerialNumber: [serial] The serial number of the certificate.
Signature algorithm of the certificate SSLClientCertSignatureAlgorithm: [alg] The signature algorithm of the certificate.
Issuer of the certificate SSLClientCertIssuer: [issuer] The issuer of the certificate.
Certificate validity dates SSLClientCertNotValidBefore: [before] SSLClientCertNotValidAfter: [after] The validity dates for the certificate. The certificate is not valid before or after the dates represented by [before] and [after], respectively.
Certificate subject SSLClientCertSubject: [subject] The subject of the certificate.
Public key of the subject SSLClientCertSubjectPublicKey: [key] The type of public key type. The allowed types are RSA ([size] bit), DSA, or Unknown public key.
The certificate itself SSLClientCert: [cert] The actual client certificate.
MD5 hash of the certificate SSLClientCertHash: [hash] The MD5 hash of the client certificate.

SSL session cache

You can configure timeout and size values for the SSL session cache. Because each profile maintains a separate SSL session cache, you can configure the values on a per-profile basis.

SSL session cache size

You can specify the maximum size of the SSL session cache. The default value for the size of the SSL session cache is 262144 entries. A value of 0 disallows session caching.

SSL session cache timeout

You can specify the number of usable lifetime seconds of negotiated SSL session IDs. The default timeout value for the SSL session cache is 3600 seconds. If you specify a timeout value, valid values are integers greater than or equal to 1.

Clients attempting to resume an SSL session with an expired session ID are forced to negotiate a new session.

Warning: If the timeout value for the client-side SSL session cache is set to zero, the SSL session IDs negotiated with that profile’s clients remain in the session cache until the cache is filled and the purging of entries begins. Setting a value of zero can introduce a significant security risk if valuable resources are available to a client that is reusing those session IDs. It is therefore common practice to set the SSL session cache timeout to a length of time no greater than 24 hours, and for significantly shorter periods.

To specify an SSL session cache timeout, locate the Cache Timeout setting, and retain the default value or, from the list, select Specify or Indefinite. If you select Specify, type a value. Selecting Indefinite prevents SSL session cache entries from expiring.

Alert timeout value

You can specify the duration in seconds that Local Traffic Manager waits while trying to close an SSL connection, before the connection is reset. The default timeout value for this setting is 10 seconds.

Handshake timeout value

You can specify the amount of time in seconds that Local Traffic Manager spends attempting to perform an SSL handshake. The default timeout value for this setting is 10 seconds.

Renegotiation of SSL sessions

Long-lived connections are susceptible to man-in-the-middle attacks. To prevent such attacks, you can force Local Traffic Manager to renegotiate SSL sessions, based on either time period or application size. You can also force Local Traffic Manager to terminate an SSL session after receiving a specified number of records.

Sessions based on a time period

You can specify the number of seconds from the initial connect time that the system renegotiates an SSL session. The options are a number you specify, indefinite, and default. The default is indefinite, meaning that you do not want the system to renegotiate SSL sessions. Each time the session renegotiation is successful, essentially a new connection is started. Therefore, the system attempts to renegotiate the session again in the specified amount of time following the successful session renegotiation. For example, setting the renegotiate period to 3600 seconds triggers session renegotiation at least once an hour.

Sessions based on application data size

You can force Local Traffic Manager to renegotiate an SSL session after the specified number of megabytes of application data have been transmitted over the secure channel. The default value for this setting is Indefinite.

Maximum record delay

You can force Local Traffic Manager to terminate an SSL session after receiving the specified maximum number of SSL records. If Local Traffic Manager receives more than the maximum number of SSL records, it closes the connection. The default value for this setting, in seconds, is 10.

Secure renegotiation

The Secure Renegotiation setting specifies the method of secure renegotiation for SSL connections. The default value for the Client SSL profile is Require; the default value for the Server SSL profile is Require Strict. If your configuration does not require secure SSL renegotiation, set this value to Request. The possible values for this setting are:

Request
Specifies that the system requests secure renegotiation of SSL connections.
Require
Specifies that the system requires secure renegotiation of SSL connections. In this mode, the system permits initial SSL handshakes from clients, but terminates renegotiations from unpatched clients.
Require Strict
Specifies that the system requires strict secure renegotiation of SSL connections. In this mode, the system refuses new SSL connections to unsecure servers and terminates existing SSL connections to unsecure servers.

Server name

The Server Name setting in an SSL profile specifies the name of the specific domain from which the client requests a certificate. This setting supports a feature known as TLS Server Name Indication (TLS SNI), used when a single virtual IP server needs to host multiple domains.

For example, suppose that the BIG-IP system needs to host the two domains domain1.com and domain2.com, on the same HTTPS virtual server. Each domain has its own server certificate to use, such as domain1.crt and domain2.crt, and each has different security requirements.

To ensure that the BIG-IP system presents the correct certificate to the browser, you enable SNI, which sends the name of a domain as part of the TLS negotiation. This, in turn, enables the BIG-IP system to select this domain rather than waiting to read the domain name in the request header.

To enable SNI, you configure the Server Name and other TLS-related settings on an SSL profile, and then assign the profile to a virtual server.

Note that the wildcard character (*) is supported within any domain name that you specify.

Default SSL Profile for SNI

When you enable the Default SSL Profile for SNI setting on an SSL profile, you are specifying that this is the default SSL profile to use when the client provides either no SNI extension, or provides a non-matching SNI extension.

When assigning multiple SSL profiles to a single virtual server, you can enable this setting on one Client SSL profile only and one Server SSL profile only.

Require Peer SNI Support

If you enable the Require Peer SNI Support setting on an SSL profile, the domain name of the peer must match the domain name that you specify in the Default SSL Profile for SNI field.

Unclean SSL shutdowns

In an unclean shutdown, underlying TCP connections are closed without exchanging the required SSL shutdown alerts. However, you can disable unclean shutdowns and thus force the SSL profile to perform a clean shutdown of all SSL connections by configuring this setting.

This feature is especially useful with respect to the Internet Explorer browser. Different versions of the browser, and even different builds within the same version of the browser, handle shutdown alerts differently. Some versions or builds require shutdown alerts from the server, while others do not, and the SSL profile cannot always detect this requirement or lack of it. In the case where the browser expects a shutdown alert but the SSL profile has not exchanged one (the default setting), the browser displays an error message.

By default, this setting is enabled, which means that Local Traffic Manager performs unclean shutdowns of all SSL connections.

Strict Resume

You can configure Local Traffic Manager to discontinue an SSL session after an unclean shutdown. By default, this setting is disabled, which causes Local Traffic Manager (LTM) to resume SSL sessions after an unclean shutdown. If you enable this setting, LTM does not resume SSL sessions after an unclean shutdown.

Acceptance of non-SSL connections

You can configure Local Traffic Manager to accept connections that are not SSL connections. In this case, connections pass through the BIG-IP system in clear-text format. By default, this setting is disabled.

Certificate presentation

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

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.
Require
Require a client to present a valid and trusted certificate before granting access.
Ignore
Ignore a certificate (or lack of one) and therefore never authenticate the client. The ignore setting is the default setting, and when used, causes any per-session authentication setting to be ignored.
Auto
Ignore a client certificate until an authentication module requests one. In this case, Local Traffic Manager initiates a mid-session SSL handshake, as though the option were set to Request. We recommend this setting only for those connections for which the presentation of a client certificate is not required.
Warning: If you are using the LDAP-based client authorization feature, use of the Request or Ignore options 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.

Per-session 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.

Trusted client CA advertisement

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 server 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 profile trusts. The client certificate CA file solves this problem by allowing the profile 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 Client Certificate CA option to match the actual Client Trusted CAs file. 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 with the Advertised Certificate Authorities setting. This minimizes the number of certificates that must be exchanged during a Client SSL handshake.

Authentication depth

You can 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.

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

Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)