Applies To:

Show Versions Show Versions

Manual Chapter: Introducing On-Demand Certificate Authentication
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

12 
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 On-Demand Certificate is set up properly for validation and authentication.
For more detailed information about managing SSL traffic, refer to the Configuration Guide for BIG-IP®Local Traffic Manager available on https://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 on how configure an SSL profile for a server, refer to the Configuration Guide for BIG-IP® Local Traffic Manager 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 Manager available on the AskF5SM web site, https://support.f5.com.
When a client makes an HTTPS request, the Access Policy Manager system can perform the On-Demand Certificate verification task that is normally performed by the target server.
When a client presents a certificate to the Access Policy Manager system, the system uses a trusted CA file to determine the Certificate Authorities that it can trust. By using this file, the Access Policy Manager attempts to verify a client certificate. When you create an SSL client profile, as described in Configuring client SSL profiles, the Access Policy 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 Manager on https://support.f5.com.
The Access Policy Manager provides two types of certificate agents for On-Demand Certificate authentication. Depending on your preference, you can select either agent to set up On-Demand Certificate authentication verification to be used within your access policy.
This Client Certificate Inspection agent checks the result of the On-Demand Certificate Authentication previously authenticated by the clientssl profile. It does not, however, negotiate an SSL session.
We recommend that you use the Client Certificate Inspection agent in cases where the On-Demand Certificate authentication is required as part of the initial SSL handshake, and only if it is necessary to validate the On-Demand Certificate authentication as part of running the access policy.
The certificate mode Request setting in the clientssl profile prompts the system to send a On-Demand Certificate authentication 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 On-Demand Certificate authentication process.
The Client Certificate Inspection agent checks the result of the On-Demand 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 allow 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 sends a certificate request 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: When the certificate authentication mode is set to Require on the New Client SSL Profile screen, the user must provide a valid client certificate. Otherwise, the connection is not allowed. The recommended option for the client cert result agent is Request.
The On-Demand Certificate agent performs an SSL re-handshake and validates the received certificate. To use this agent, the certification authentication mode in the clientssl handling mode should be set to Ignored on the Client SSL Profile screen. The system disregards the On-Demand 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 On-Demand Certificate authentication and validation need to be performed in the middle of an access policy process.
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 On-Demand Certificate installed.
If the user selects Yes, then the On-Demand Certificate agent runs.
The On-Demand 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 On-Demand Certificate agent starts running the access policy rule which checks the result of the On-Demand 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.
Note: The On-Demand Certificate authentication takes place after the logon page, RADIUS authentication, and the decision box agents, and not at the beginning of the initial SSL handshake, as done for the client certificate result agent.
If the access policy rule in the On-Demand 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 allow ending. Otherwise, the user is denied access.
The Access Policy 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
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.
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 On-Demand Certificate validation. However, we recommend that you select either Ignore for On-Demand Certificate Authentication or Request for client certificate result agent
9.
Click Finished.
Your clientssl profile is now created.
Once you have created a clientssl profile, you can add an On-Demand Certificate Authentication in your access policy. This action requires that the client has a valid certificate on its machine before it runs the On-Demand Certificate Authentication. We highly recommended that a Decision Box agent precede the Client Cert Check 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.
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. In the navigation pane, expand Access Policy, 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 Result agent to your access policy.
Warning: If your access policy is configured with a 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 you use the Decision box agent in your access profile so that the users are given an option to specify whether or not they have a valid certificate.
Instruct users how to download and install the On-Demand Certificate on their computers. You can also email the On-Demand Certificates to users.
The Access Policy Manager can then request and validate the users On-Demand Certificate as part of the access policy.
For more detailed information on configuration and setup, refer to the Configuration Guide for BIG-IP® Local Traffic Manager on https://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 On-Demand Certificate attempts to log on to the Access Policy 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. 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.
3.
In the Client Authentication area, in the Certification Revocation List (CRL) box, type the name of your CRL file, which was previously imported in /config/ssl/ssl.crl/.
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.
Note: You should not configure CRL updates if you are using the Access Policy Manager to generate and issue On-Demand 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 On-Demand Certificate OCSP if you are using the Access Policy Manager to generate/issue On-Demand 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 URLsetting, 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 which allow you to use the On-Demand 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.
4.
From the Available box, for the Authentication Profiles, select the CRLDP profile you want to bind to the virtual server.
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)