Manual Chapter : Using Certificate Authentication in APM

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 11.4.1, 11.4.0
Manual Chapter
One of the primary ways that you can control SSL network traffic is by configuring a client or server SSL profile. This chapter provides information on any features specific to Access Policy Manager® that you are required to configure to manage the client side, and ensure that your SSL certificate is set up properly for validation and authentication.
For more detailed information about managing SSL traffic, refer to available BIG-IP® Local Traffic Manager: Concepts available on the AskF5TM web site at http://support.f5.com.
A profile is a group of settings with values that determine the way that the Access Policy Manager system handles application-specific network traffic. One type of traffic that a profile can manage is SSL traffic. The most basic functions of an SSL profile are to offload the certificate validation and verification tasks, as well as data encryption and decryption, from your targeted web servers. The two types of SSL profiles are:
Client Profiles
Client Profiles allow the BIG-IP® system to handle authentication and encryption tasks for any SSL connection coming into a Access Policy Manager system from a client system. You implement this type of profile by using the default clientssl profile, or by creating a custom profile based on the default clientssl profile. For more information on how to set up an SSL profile for a client, refer to Configuring client SSL profiles.
Server Profiles.
Server Profiles allow the BIG-IP® system to handle encryption tasks for any SSL connection being sent from a Access Policy Manager to a target server. An SSL server profile is able to act as client by presenting certificate credentials to a server when authentication of the Access Policy Manager system is required. You implement this type of profile by using the default serverssl profile, or by creating a custom profile based on the default serverssl profile.
For more information about configuring server SSL profiles, refer to the BIG-IP® Local Traffic Manager: Concepts guide available on the AskF5TM web site at http://support.f5.com.
The SSL (Secure Sockets Layer) protocol uses the certificate to establish a secure connection. A valid SSL server certificate, also known as a security certificate, is necessary for establishing secure HTTPS connections. An SSL server certificate identifies your server to any connecting client browser. The certificate contains information identifying the server, and the organization it was issued to, as well as an expiration date. Most browsers that support SSL connections have internal lists of Certificate Authorities (CAs), and automatically accept certificates issued by these organizations. If there is an error, some browsers display security warnings; other browsers, notably those found on wireless devices such as PDAs or smart phones, might refuse a connection.
When a client presents a certificate to the BIG-IP® system, the system uses a trusted CA file to determine the Certificate Authorities that it can trust. By using this file, the BIG-IP system attempts to verify a client certificate. When you create an SSL client profile, as described in Configuring client SSL profiles, the BIG-IP system automatically creates a default client trusted CA file.
For more detailed information about server and client side certificates, refer to BIG-IP® Local Traffic Manager: Concepts guide available on the AskF5TM web site at http://support.f5.com.
This Client certificate inspection agent checks the result of the SSL handshake request that occurs at the start of the session. It does not, however, negotiate an SSL session.
F5 Networks recommends that you use the Client certificate inspection agent in cases where certificate authentication is required as part of the initial SSL handshake, and only if it is necessary to validate certificate authentication as part of running the access policy.
The Client Certificate setting, request, in the clientssl profile, prompts the system to send a certificate authentication request to the user.
After the user provides a valid certificate, the access policy is started by the system, and the system provides the logon page (the first item in the access policy). Note that the opening of the logon page agent is not affected by the result of the certificate authentication process.
The Client certificate inspection agent checks the result of the certificate authentication that was performed at the beginning of the session before the logon page agent.
The default rule that comes with the client certification inspection agent checks the value of the session variable session.ssl.cert.valid to determine the success or failure of the authentication process. Upon successful authentication, the access policy assigns the resource R1 to the user and reaches the allow ending. Otherwise, the access policy assigns the resource R2 to the user.
To use this agent, set the Client Certificate setting in the clientssl profile to request; with this setting, a certificate request is sent to the client. In this case, the SSL profile always grants access, regardless of the status or absence of the certificate. Granting access is not dependent on whether a certificate is present, nor does connection terminate if a certificate is not received.
Note: For Client Certificate, request is the recommended setting. Alternatively, you can use the require setting; however, if you do, the user must provide a valid client certificate. Otherwise, the connection is not allowed
The On-Demand certificate authentication agent performs an SSL re-handshake and validates the received certificate. To use this agent, select ignore for the Client Certificate setting in the clientssl profile on the New Client SSL Profile screen. The system disregards the certificate request and does not use it in the initial SSL handshake.
We recommend that you use this agent in cases where both certificate authentication and validation need to be performed in the middle of an access policy process.
When the user connects to the system, with the Client Certificate setting in the clientssl profile set to ignore, the system does not prompt a request to the user for a certificate, but instead the access policy process starts by providing the Logon page to the user.
Upon successful authentication, the access policy runs the decision box action called Client Cert Installed or Not, which prompts the user to indicate whether he has a certificate installed.
If the user selects Yes, then the On-Demand certificate authentication agent runs.
The On-Demand certificate agent re-negotiates the SSL connection by sending a certificate request to the user, which prompts a certificate window to open.
After the user provides a valid certificate, the On-Demand certificate authentication agent checks the result of the certificate authentication. The default rule that comes with the On-Demand certificate authentication agent checks the value of the session variable session.ssl.cert.valid to determine whether authentication was a success.
If the access policy rule in the On-Demand certificate authentication agent detects that the validation was a success, then the access policy assigns the resource R1 to the user, and takes the user to the allow ending. Otherwise, the user is denied access.
When you add the On-Demand certificate authentication agent to an access policy, you can configure the Auth Mode property for it. There are two possible values:
request: The system requests a valid certificate from the client, but the connection does not terminate if the client does not provide a valid certificate. Instead, this action takes the fallback route in the access policy. This is the default option.
require: The system requires that a client provides a valid certificate. If the client does not provide a valid certificate, the connection terminates and the client browser stops responding.
Figure 9.1 shows an example of an access policy that displays the On-Demand Cert Auth agent with the two authentication modes. The iPhone or iPod User check is created using the Client Type check, and determines whether the client is using an iPhone or iPod, or the browser. If the user agent string (shown in Figure 9.2) indicates that the client is an iPhone or iPod user, then the On-Demand Cert Auth- Require authentication mode is executed. Otherwise, On-Demand Cert Auth Request is executed.
After you create a clientssl profile with Client Certificate set to ignore, you can add an On-Demand certificate authentication agent to your access policy. This action requires that the client has a valid certificate on its machine before it runs the certificate authentication. F5 Networks highly recommends that a Decision Box agent precede the On-Demand certificate authentication agent in the visual policy editor so that the user has the option of indicating whether he has a valid certificate. If a valid certificate is not available, and indicated as such in the Decision Box agent, the system bypasses the client certificate validation process and proceeds to the next step in the verification process.
Note: If you want to authenticate the client with a valid certificate at the beginning of the initial SSL handshake of your access policy, do not use the On-Demand Cert Auth agent.
2.
On the navigation pane, expand Access Policy, and select Access Profiles.
The Access Profile screen opens.
3.
Click the access policy and select Edit.
The visual policy editor screen opens.
4.
Under Predefined Actions, and in the Authentication settings, select On-Demand Cert Auth.
5.
Click Add Item.
A Properties screen opens.
6.
From the Auth Mode option, select either Request or Required. The default is Request.
Select Required. Note that to pass a certificate check using Safari, you will be asked to select the certificate multiple times. This is expected behavior.
7.
Click Save.
The system adds the On-Demand Certificate authentication agent to your access policy.
Note: If your access policy is configured with an On-Demand certificate authentication action, the user's browser must have a valid certificate. Otherwise, your browser may stop responding because the client failed to provide a valid certificate. To avoid running into this problem, we highly recommend that you use the Decision box agent in your access policy so that the users are given an option to specify whether or not they have a valid certificate.
The BIG-IP® system provides a simple way to configure your client SSL profile so that you can include the cerClient certificate intificate authentication process in your access policy.
Configuring the clientssl profile
The first task in configuring a client SSL profile is to import a certificate and the corresponding key (issued by your organization CA).
1.
In the navigation pane, expand Local Traffic and click SSL Certificates.
The SSL Cert screen opens.
2.
Click the Import button.
The SSL Certificate/Key Source screen opens.
3.
Select an Import Type from the list, type the required parameters into the boxes, and click the Import button.
The screen refreshes to show settings specific to the type you selected.
1.
In the navigation pane, expand Local Traffic and click Profiles.
The HTTP Profiles screen opens.
2.
From the SSL menu, choose Client.
The Client SSL Profiles screen opens.
3.
At the upper right, click Create.
A New Client SSL Profile screen opens.
4.
In the Name box, type a name for your clientssl profile.
5.
In Configuration, select Advanced from the list.
6.
Check the Custom box.
7.
For the Trusted Certificate Authorities setting, select your trusted certificate authority.
8.
For the Ciphers setting, type in a NATIVE cipher to support the On-Demand certificate authentication check. The list of supported NATIVE ciphers includes the following:
9.
In the Client Authentication area, check the Custom box. Your choice for the Client Certificate setting depends on the type of agent you want to use in your access policy. To use:
Client certificate inspection agent:

For iPod or iPhone clients, select require.

For all other clients, we recommend that you select request.
10.
Click Finished.
Your clientssl profile is now created.
Instruct users how to download and install the certificate on their computers. You can also email the certificate to users.
For more detailed information, refer to BIG-IP® Local Traffic Manager: Concepts available on the AskF5TM web site at http://support.f5.com.
A certificate revocation list (CRL) is a list of revoked (invalid) certificates. The CRL describes the reason for the revoked status of the certificate, and provides the certificates issue date and originator. The list also notes its next update.
When a user with a revoked SSL certificate attempts to log on to the Access Policy Manager, the system allows or denies access based on the CRL configured in the profile.
A CRL is one of three common methods for maintaining valid, certificate-based access to servers in a network. CRLDP is an industry-standard protocol designed to manage SSL certificates revocation on a network or system. The main limitation of CRL is that the current state of the CRL requires frequent updates. Whereas, OCSP checks certificate status in real time. You can read more about OCSP in Understanding OCSP, following.
The CRL is a PEM-formatted file containing a list of revoked certificate attached to the client SSL profile. Make sure the CRL file is kept up-to-date. You must manually install the CRL file to the /config/ssl/ssl.crl directory since this is not an automatic process.
1.
In the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens.
2.
From the SSL menu, choose Client.
The Client SSL Profiles screen opens.
4.
In the Client Authentication area, select the Custom checkbox to enable editing.
5.
From the Certification Revocation List (CRL) box, select the name of the CRL file that you previously imported into /config/ssl/ssl.crl/ on the BIG-IP system.
6.
Click Update.
Your CRL file is now attached to the client SSL profile.
Note that if you have multiple CRL files, you cannot aggregate them into one master file. You must point to the individual file (in PEM format) if you want to retrieve CRL information.
Note: You should not configure CRL updates if you are using the BIG-IP system to generate and issue SSL certificates to users (using either a self-signed client root CA certificate, or a client root CA certificate from a trusted CA). In this case the Access Policy Manager manages CRLs internally.
The Access Policy Manager system supports CRL files only in PEM format. However, you can convert non-PEM file format, such as DER, by using a few CLI commands.
2.
Run the command crl -inform DEM -outform PEM -in CRL.crl -out CRL.PEM.
You have successfully converted your input CRL file, CRL.crl in DER format to output CRL file, CRLpem in PEM format.
The Online Certificate Status Protocol (OCSP) enables applications to determine the revocation status of a certificate. OCSP provides more timely revocation information than is possible using CRLs, and may also be used to obtain additional status information. An OCSP client, in this case the Access Policy Manager, acts as the client, and issues a status request to an OCSP responder, and suspends acceptance of that certificate until the responder provides a response.
Note: Do not use OCSP if you are using the BIG-IP system to generate/issue SSL certificates to users (using either a self-signed client root CA certificate, or a client root CA certificate issued by a trusted CA). In this case, the Access Policy Manager is managing CRLs internally.
1.
In the navigation pane, expand Local Traffic, and click Profiles.
The HTTP Profiles screen opens.
2.
3.
At the upper right, click Create.
A General Properties screen opens.
4.
Type in a name for your OCSP profile. The name should not contain capital letters (which generates an error).
This screen refreshes to display additional parameters specific to your selection.
5.
In the URL setting, type the URL for your external OCSP responder.
A separate OCSP responder object must be created for each OCSP server.
6.
Specify a Certificate Authority File.
7.
Click Finished.
1.
In the navigation pane, expand Local Traffic, and click Profiles.
The HTTP Profiles screen opens.
2.
From the Authentication menu, choose Profiles.
The Authentication Profiles screen opens.
3.
At the upper right, click Create.
The New Authentication Profile screen opens.
5.
Click Finished.
This creates the SSL OCSP profile.
The last step in setting up OCSP is to include the created OCSP profile in the authentication profile settings of the virtual server.
1.
In the navigation pane, expand Local Traffic, and click Virtual Servers.
The General Properties screen opens.
2.
From the Configuration list, select Advanced.
3.
For Authentication Profiles settings, from the Available box, select the SSL OCSP profile you want to bind to the virtual server.
5.
Click Update.
CRLDP stands for Certificate Revocation List Distribution Point. CRLDP checks the revocation status of an SSL certificate as part of authenticating that certificate. CRL distribution points are used to distribute certificate revocation information across a network. A distribution point is a URI or directory name specified in an SSL certificate that identifies how the server obtains CRL information. In addition, distribution points can be used in conjunction with CRLs to configure certificate authorization using any number of LDAP servers.
When you set up a CRLDP server object, you include details such as the CRLDP server IP address, a port for the CRLDP authentication traffic, and the LDAP base DN for certificates that specify the CRL distribution point in directory name format. The base DN is used when the value of the X.509 v3 attribute CRLDP is of type dirName. In this case, the Access Policy Manager attempts to match the value of the CRLDP attribute to the base DN value.
1.
In the navigation pane, expand Local Traffic, and click Profiles.
The HTTP Profiles screen opens.
2.
3.
At the upper right, click Create.
The General Properties screen opens.
4.
Fill in all the details for this screen
Refer to the online help for specific details on each settings.
5.
Click Finished.
This creates a CRLDP Server object.
When you configure a CRLDP configuration object, you include details about the CRLDP servers that allow you to use the certificate issuer to extract the CRLDP.
1.
In the navigation pane, expand Local Traffic, and click Profiles.
The HTTP Profiles screen opens.
1.
From the Authentication menu, choose Configurations.
The Authentication Configurations screen opens.
2.
At the upper right, click Create.
The General Properties screen opens.
3.
In the Name box, type in a name for your CRLDP configuration object.
4.
From the Type list, select CRDLP.
Additional configuration parameters appear.
5.
Specify your CRLDP server and click Finished.
This creates the CRLDP configuration object.
1.
In the navigation pane, expand Local Traffic, and click Profiles.
The HTTP Profiles screen opens
2.
From the Authentication menu, choose Profiles.
The Authentication Profiles screen opens.
4.
In the Name box, type in a name for your CRLDP profile.
5.
From the Type list, select CRLDP.
Additional configuration parameters become available.
6.
Enable all the custom check boxes and configure all settings.
Refer to the online help for specific details on each settings.
7.
Click Finished.
This creates the CRLDP profile.
The last step in setting up CRDLP is to include the CRLDP profile in the authentication profile settings of the virtual server.
1.
In the navigation pane, expand Local Traffic, and click Virtual Servers.
The Virtual Server List screen opens.
2.
From the list of virtual servers, click the name of the server you want to bind the CRDLP profile.
The Properties screen opens.
3.
From the Configuration setting, select Advanced.
From the Available box, for the Authentication Profiles, select the CRLDP profile you want to bind to the virtual server.
5.
Click Update.
The CRLDP Profile is now associated with your virtual server.