Applies To:

Show Versions Show Versions

Archived Manual Chapter: Using Client Certificate Authentication
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.

One of the primary ways that you can control SSL network traffic is by configuring a client or server SSL profile. This chapter does not go into detail about managing your SSL traffic. However, it does attempt to cover any feature specific to Secure Access Manager that you are required to configure to manage the client side, and ensure that you are set up correctly to use client certificates for validation and verification.
For more detailed information about managing SSL traffic, refer to the Configuration Guide for BIG-IP® Local Traffic Management available on https://support.f5.com.
A profile is a group of settings with values that determine the way that the Secure Access Manager system manages 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 certificate validation and verification task, as well as 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 Secure Access 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 the 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 Secure Access 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 Secure Access 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 on how configure an ssl profile for a server, refer to the Configuration Guide for BIG-IP® Local Traffic Management available on the AskF5SM web site, https://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.
For more detailed information about how to set up server certificates, refer to the Configuration Guide for BIG-IP® Local Traffic Management available on the AskF5SM web site, https://support.f5.com.
When a client makes an HTTPS request, the Secure Access Manager system can perform the client certificate verification task that is normally performed by the target server.
When a client presents a certificate to the Secure Access Manager system, the system uses a client trusted CA file to determine the Certificate Authorities that it can trust. By using this file, the Secure Access Manager attempts to verify a client certificate. When you create an SSL client profile, as described in Configuring client SSL profiles, the Secure Access Manager automatically creates a default client trusted CA file.
For more detailed information about server and client side certificates, refer to the Configuration Guide for BIG-IP® Local Traffic Management on https://support.f5.com.
The Secure Access Manager presents two types of certificate agents for client cert authentication. Depending on your preference, you can select either agent to set up client certification verification to be used within your access policy.
This client certificate result agent checks the result of the client certificate previously authenticated by the clientssl profile. It does not, however, perform an SSL handshake and validate previously authenticated certificates.
We recommend that you use the client certificate result agent in cases where the client certificate authentication is required as part of the initial SSL handshake, and only if it is necessary to validate the client certificate authentication as part of running the access policy.
The following example shows a client certificate result agent being used as part of an access policy. The following actions occur, as shown in Figure 9-1.
The certificate mode Request setting in the clientssl profile prompts the system to send a client certificate request to the user.
Once 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 client certificate authentication process.
The client certificate result agent checks the result of the client certificate authentication that was performed at the beginning, for instance, before the logon page agent.
The default rule that comes with the client cert result 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 webtop ending. Otherwise, the access policy assigns the resource R2 to the user.
To use this agent, set the certification mode in the clientssl profile to Request. Setting this mode verifies a client certificate. 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.
Note: Secure Access Manager does not support the Require option, although it is available on the Configuration utility. Expand Local Traffic, select Profiles, and on the menu bar, click SSL and select Client. Then, click Create, and scroll down to Client Authentication.
This client certificate agent performs an SSL handshake and validates the received certificate. To use this agent, the certification mode in the clientssl profile should be set to Ignored. The system disregards the client certificate request and does not use it in the initial SSL handshake as part of your access policy.
We recommend that you use this agent in cases where both the client certificate authentication and validation need to be performed in the middle of an access policy process.
The following example shows a client certificate agent being used as part of the access policy. The following actions occur, as shown in the Figure 9-2.
When the user connects to the system, the Ignored setting for the certificate mode in the clientssl profile 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 client certificate is installed.
If the user selects Yes, then the client certificate agent (the fourth item in the access policy) runs.
The client certificate agent then re-negotiates the SSL connection by sending a certificate request to the user, which prompts a certificate window to open.
Once the user provides a valid certificate, the client certificate agent starts running the access policy rule which checks the result of the client certificate authentication. The default rule that comes with the client certificate agent checks the value of the session variable session.ssl.cert.valid to determine whether authentication was a success.
Note: The client certificate authentication takes place after the logon page, RADIUS auth, and the decision box agents, and not at the beginning of the initial SSL handshake, as done for the client cert result agent.
If the access policy rule in the client certificate 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 webtop ending. Otherwise, the user is assigned to the resource R2.
The Secure Access Manager system provides a simple way to configure your client SSL profile so that you can include the certificate authentication process in your access policy.
Configuring the clientssl profile
1.
On 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 fields, and click the Import button.
The screen refreshes to show settings specific to the type you selected.
1.
On 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 on the right.
7.
For the Trusted Certificate Authorities settings, select your trusted certificate authority.
8.
In the Client Authentication area, you can select from the four options available,
Your choice depends on the type of agent you want to use in your access policy as part of client certificate validation. However, we recommend that you select either Ignore for client cert agent or Request for client cert result agent
9.
Click Finished.
Your clientssl profile is now created.
Warning: If you configure for a client certificate, the client must have a valid certificate. Otherwise, if you set up and configure a certificate and one does not exist, your browser may stop responding because the client failed to provide a valid certificate. To avoid running into this problem, we highly recommend you use the Decision box agent in your access profile so that the user is given an option to specify whether or not they have a valid certificate.
Once you have created a clientssl profile, you can add a Client Cert Check agent in your access policy. This action requires that the client have a valid certificate on its machine before it is granted authentication. We highly recommended that a Decision Box agent precede the Client Cert Check agent 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 cert validation process and proceeds to the next step in the verification process, as shown in the example in Figure 9-1.
Tip: If you want to authenticate the client with a valid certificate at the beginning of the initial SSL handshake of your access policy, then you should select request from the Client SSL Profile screen when you set up your client SSL profile.
1.
Select an access policy or create a new one. On the navigation pane, expand Access Control, and select Access Profiles.
The Access Profile screen opens.
2.
Click the access policy and select Edit.
The visual policy editor screen opens.
3.
Under Predefined Actions, and in the Authentication settings, select Client Cert.
4.
Click the Add Item button.
A Properties screen opens.
5.
Click Save.
The system adds the Client Cert agent to your access policy.
To use client certificates, you must have a server configured as a certificate authority (CA) that can generate a client root certificate and the client certificates based on the client root certificate. Or, you can purchase the client root certificate and client certificates from an external CA.
Install the client root certificate on the Secure Access Manager.
You can install a client root certificate using the Certificates screen.
Instruct users how to download and install the client certificate on their computers. You can also email the client certificates to users.
Install a certificate revocation list (CRL) that contains a list of client certificates for users who you want to deny access to the Secure Access Manager, for example, the revoked client certificates of users who have left your company.
The Secure Access Manager can then request and validate the computers client certificate against its installed client root certificate as part of the authentication process.
This guide briefly covers the certificate revocation status that the Secure Access Manager supports. For more detailed information on configuration and setup, refer to the Configuration Guide for BIG-IP® Local Traffic Management on https://support.f5.com.
A certificate revocation list (CRL) is a list of revoked 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 client certificate attempts to log on to the Secure Access Manager, the system allows or denies access based on the CRL configured in the sslclient profile.
A CRL is one of three common methods for maintaining valid, certificate-based access to servers in a network. The other methods are Online Certificate Status Protocol (OCSP), and Certificate Revocation List Distribution Point (CRLDP). 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. On the other hand, OCSP checks certificate status in real time. You can read more about OCSP in Understanding OCSP, following.
The CRL can be configured by creating a PEM-formatted file containing a list of revoked certificate and attaching it to the client SSL profile. Make sure the CRL file is kept up-to-date. Otherwise, an error will occur.
1.
On 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.
In the Client Authentication area, in the Certification Revocation List (CRL) box, type a name of your CRL file.
4.
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. The CRL file must be manually installed to the /config/ssl/sslcrl directory since this is not an automatic process.
Note: You should not configure CRL updates if you are using the Secure Access Manager to generate and issue client 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 Secure Access Manager manages CRLs internally.
As mentioned, the Secure Access Manager system supports CRL files only in PEM format. However, we have provided a way to convert non-PEM file format, such as DER, by using a few CLI commands.
2.
Type 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 Secure Access Manager, acts as the client, and issues a status request to an OCSP responder (which can be an external server), and suspends acceptance of that certificate until the responder provides a response.
Note: Do not use Client Certificate OCSP if you are using the Secure Access Manager to generate/issue client 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 Secure Access Manager is managing CRLs internally.
1.
On 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 field, type a URL for your external OCSP responder.
A separate OCSP responder object must be created for each OCSP responder.
6.
Specify a Certificate Authority File.
All other settings are optional.
7.
Click Finished.
1.
On 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.
4.
Type in a name for your OCSP profile server, and select SSL OCSP from the Type list. This screen refreshes to display additional parameters specific to your selection.
5.
Click Finished.
Your SSL OCSP profile is created.
The last step in setting up OCSP is to include the created OCSP profile in the authentication profile settings of the virtual server.
1.
On the navigation pane, expand Local Traffic, and click Virtual Servers.
The General Properties screen opens.
2.
From Configuration, select Advanced from the drop list.
3.
From Authentication Profiles, select the SSL OCSP profile you wish to bind to the virtual server from the Available box.
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 X509v3 attribute CRLDP is of type dirName. In this case, the Secure Access Manager attempts to match the value of the CRLDP attribute to the base DN value.
1.
On 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.
5.
Click Finished.
A CRLDP Server object is created.
When you configure a CRLDP configuration object, you include details about the CRLDP servers which allows you to use the client certificate issuer to extract the CRLDP.
1.
On 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.
Your CRLDP configuration object is created.
1.
On the navigation panel, 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.
7.
Click Finished.
Your CRLDP profile is created.
The last step in setting up CRDLP is to include the CRLDP profile in the authentication profile settings of the virtual server.
1.
On the navigation pane, expand Local Traffic, and click Virtual Servers.
The Virtual Server List screen opens.
2.
From the list of virtual servers, click on 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 drop list.
4.
From the Authentication Profiles field, select the CRLDP profile you wish to bind to the virtual server from the Available box.
6.
Click Update.
The CRLDP Profile is now associated with your virtual server.
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)