Manual Chapter : CRLDP Authentication

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 17.1.0
Manual Chapter

CRLDP Authentication

About CRLDP configuration

Access Policy Manager supports retrieving Certificate Revocation Lists (CRLs) from network locations (distribution points). A Certificate Revocation List Distribution Point (CRLDP) AAA server defines how to access a CRL file from a distribution point. A distribution point is either an LDAP Uniform Resource Identifier (URI), a directory path that identifies the location where the CRLs are published, or a fully qualified HTTP URL.
If you are adding CRLDP items to an existing access policy, you do not need to create another access profile.

About AAA high availability

Using AAA high availability with Access Policy Manager (APM), you can configure multiple authentication servers to process requests, so that if one authentication server goes down or loses connectivity, the others can resume authentication requests, and new sessions can be established, as usual.
Although new authentications fail if the BIG-IP system loses connectivity to the server, existing sessions are unaffected provided that they do not attempt to re-authenticate.
APM supports the following AAA servers for high availability: RADIUS, Active Directory, LDAP, CRLDP, and TACACS+. APM supports high availability by providing the option to create a pool of server connections when you configure the supported type of AAA server.
If you use AAA with pools, such as RADIUS pools or Active Directory pools, APM assigns each pool member with a different number for the pool member's priority group value. APM must define each pool member with a different priority group because AAA load balancing is not used. The priority group number increases automatically with each created pool member. Alternative AAA pool configurations can be defined manually using the full flexibility of Local Traffic Manager (LTM) if high availability is desired.

Example access policy for CRLDP authentication

This is an example of an access policy with all the associated elements needed to retrieve CRLs using CRLDP. Notice that you must add either the Client Cert Inspection agent or On-Demand Cert Auth agent before the CRLDP object in your access policy. One of those agents is required in order to receive the X.509 certificate from the user. This is also important because both agents store the user information, as well as the issuer certificates, in the session variables. This allows the CRDLP Auth agent to check the revocation status of the user's certificate.
How CRLDP works
How CRLDP works

CRLDP session variables

When the CRLDP Auth access policy item runs, it populates session variables which are then available for use in access policy rules. The table lists the session variables for the CRLDP access policy item and for the certificate item used in the access policy.

Session variables for CRLDP

Session Variable
Description
session.ssl.cert.whole
Provides the client certificate received from the user in PEM format.
session.ssl.cert.certissuer
Provides the issuer certificate of the client certificate in PEM format.
session.crldp.last.result
Sets the result of the CRLDP authentication. The available values are:
  • 0: Failed
  • 1: Passed
session.crldp.last.status
Sets the status of the authentication to Failed.

CRLDP authentication troubleshooting tips

You might run into problems with CRLDP authentication in some instances. Follow these tips to try to resolve any issues you might encounter.

CRLDP auth and query troubleshooting

Possible error messages
Possible explanations and corrective actions
No AAA server associated with the agent
Make sure that a valid CRLDP responder configuration is assigned to the CRLDP agent in the access policy.
User/Issuer certificate not found for the session
The user/issuer certificate session variables are missing. Make sure that either the Client Cert Inspection agent or On-Demand Cert Auth agent is configured in the access policy (or use a variable assignment agent to create them).
Failure to connect to CRLDP server
Make sure that the CRLDP server is up and running and reachable from the BIG-IP system.
No LDAP URL found in the DP list
Indicates that no valid CRL DP is configured on the LDAP server. Make sure that the LDAP server used in the CRLDP server configuration has valid CRL DPs configured.
CRLDP response - Cert with serial number 'x' has been revoked
Indicates that the status of the user certificate is revoked.

Configure an AAA server for CRLDP

Create a CRLDP AAA configuration to specify how to access certificate revocation lists (CRLs).
  1. On the Main tab, click
    Access
    Authentication
    CRLDP
    .
    The CRLDP Servers list screen opens.
  2. Click
    Create
    .
    The New Server properties screen opens.
  3. In the
    Name
    field, type a unique name for the authentication server.
  4. For the
    Server Connection
    setting, select one of these options:
    • Select
      Use Pool
      to set up high availability for the AAA server.
      If you select
      Use Pool
      , the
      Timeout
      value does not apply.
    • Select
      Direct
      to set up the AAA server for standalone functionality.
    • Select
      No Server
      to use a fully qualified HTTP URL as the CRL location.
      The BIG-IP system uses the URI from the user's certificate.
    When you select
    No Server
    , the screen updates to omit the fields that are not necessary, such as
    Server Addresses
    ,
    Server Port
    , and so on.
  5. If you selected
    Use Pool
    , type a name in the
    Server Pool Name
    field.
    You create a pool of servers on this screen.
  6. Provide the addresses required for your server connection:
    • If you selected
      Direct
      , type an IP address in the
      Server Address
      field.
    • If you selected
      Use Pool
      , for each pool member you want to add, type an IP address in the
      Server Addresses
      field and click
      Add
      .
      When you configure a pool, you have the option to type the server address in route domain format:
      IPAddress
      %
      RouteDomain
      .
  7. If you selected
    Use Pool
    , you have the option to select a
    Server Pool Monitor
    to track the health of the server pool.
  8. If you specified
    Use Pool
    or
    Direct
    for the server connection, the
    Base DN
    field displays; type a CRLDP base distinguished name into it.
    This setting applies for certificates that specify the CRL distribution point in directory name (dirName) format. Access Policy Manager uses the Base DN when the value of the X509v3 attribute,
    crlDistributionPoints
    , is of type
    dirName
    . In this case, Access Policy Manager tries to match the value of the crlDistributionPoints attribute to the Base DN value. An example of a Base DN value is
    cn=lxxx,dc=f5,dc=com
    .
    If the client certificate includes the distribution point extension in LDAP URI format, the IP address, Base DN, and Reverse DN settings configured on the agent are ignored; they are specific to directory-based CRLDP. All other settings are applicable to both LDAP URI and directory-based CRL DPs.
  9. When the
    Use Pool
    or
    Direct
    server connection is selected, the
    Reverse DN
    option displays. This option specifies in which order the system should attempt to match the Base DN value to the value of the X509v3 attribute crlDistributionPoints. Available options are
    Enabled
    and
    Disabled
    . When the enabled option is selected, the system matches the base DN from left to right, or from the beginning of the DN string, to accommodate dirName strings in certificates such as
    c=us,st=wa,l=sea,ou=f5,cn=xxx
  10. In the
    Cache Timeout
    field, type the number of seconds a CRL is cached. Default value is 86400 seconds. When it is used, the entry is deleted from the CRL cache after 24 hours.
  11. In the
    Max Cache Size
    field, type the number of the CRLDP cache entries. This option specifies the configurable setting for CRLDP agent to check and limit the maximum entries of the CRLDP cache. If the number of cache entries reaches the configured cache size limit, a cache entry that is least recently used (LRU) is removed and a new entry is populated into the cache. Set the cache size value between 0 to 10,000 entries. The maximum number of entries allowed is 10,000 entries which is a default value set for the Cache size option.
  12. Select the
    Use Issuer
    checkbox. When selected that the system extracts the CRL distribution point from the certificate of the client certificate issuer. Default is cleared.
  13. Select the
    Allow Null CRL
    checkbox. When selected that a null CRL from the CRLDP server is considered a successful authentication. Default is cleared.
  14. Select the
    Verify Signature
    checkbox. When selected that the signature on the received CRL is verified. Default is selected.
  15. In the
    Connection Timeout
    field, type the number of seconds of inactivity the system allows before the connection times out. Default value is
    15
    seconds. The connection timeout value does not apply if you select the
    Use Pool
    option.
  16. In the
    Update Interval
    field, type the validity (in seconds) of the CRL file. To force the retrieval of a CRL file before the current CRL becomes obsolete, set this value to less than the CRL expiration time. If the value is zero (default), the CRLDP action uses the expiration time specified by the CA's CRL publishing parameters (the Next update parameter).
  17. Click
    Finished
    .
    The new server displays on the list.
An CRLDP AAA server is available for use in a CRLDP Auth agent in an access policy.

Create an access profile

You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Access Profiles (Per-Session Policies)
    .
    The Access Profiles (Per-Session Policies) screen displays.
  2. Click
    Create
    .
    The New Profile screen displays.
  3. In the
    Name
    field, type a unique name for the access profile.
  4. From the
    Profile Type
    list, select one these options:
    • ALL
      : Select to support LTM-APM and SSL-VPN access types.
    • LTM-APM
      : Select for a web access management configuration.
    • OAuth-Resource Server
      : For configuring APM to act as an OAuth resource server that provides an OAuth authorization layer into an API gateway.
    • RDG-RAP
      : Select to validate connections to hosts behind APM when APM acts as a gateway for RDP clients.
    • SSL-VPN
      : Select to configure network access, portal access, or application access. (Most access policy items are available for this type.)
    • SSO
      : Select to configure matching virtual servers for Single Sign-On (SSO).
      No access policy is associated with this type of access profile
    • SWG - Transparent
      : Select to configure access using Secure Web Gateway transparent forward proxy.
    • SWG - Explicit
      : Select to configure access using Secure Web Gateway explicit forward proxy.
    • System Authentication
      : Select to configure administrator access to the BIG-IP system (when using APM as a pluggable authentication module).
    • Identity Service
      : Used internally to provide identity service for a supported integration. Only APM creates this type of profile.
      You can edit Identity Service profile properties.
    Depending on licensing, you might not see all of these profile types.
    Additional settings display.
  5. From the
    Profile Scope
    list, select one these options to define user scope:
    • Profile
      : Access to resources behind the profile.
    • Virtual Server
      : Access to resources behind the virtual server.
    • Global
      : Access to resources behind any access profile with global scope.
    • Named
      : Access for SSL Orchestrator users to resources behind any access profile with global scope.
    • Public
      : Access to resources that are behind the same access profile when the Named scope has configured the session and is checked based on the value and string configured in the Named scope field.
  6. For the
    Customization Type
    , use the default value
    Modern
    .
  7. In the Language Settings area, add and remove accepted languages, and set the default language.
    If any browser language does not match with the accepted languages list, the browser uses the default language.
  8. Click
    Finished
    .
The access profile displays in the Access Profiles List. Default-log-setting is assigned to the access profile.

Verify log settings for the access profile

Confirm that the correct log settings are selected for the access profile to ensure that events are logged as you intend.
Log settings are configured in the
Access
Overview
Event Log
Settings
area of the product. They enable and disable logging for access system and URL request filtering events. Log settings also specify log publishers that send log messages to specified destinations.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Access Profiles (Per-Session Policies)
    .
    The Access Profiles (Per-Session Policies) screen displays.
  2. Click the name of the access profile that you want to edit.
    The properties screen opens.
  3. On the menu bar, click
    Logs
    .
    The access profile log settings display.
  4. Move log settings between the
    Available
    and
    Selected
    lists.
    You can assign up to three log settings that enable access system logging to an access profile. You can assign additional log settings to an access profile provided that they enable logging for URl request logging only.
    Logging is disabled when the
    Selected
    list is empty.
  5. Click
    Update
    .
An access profile is in effect when it is assigned to a virtual server.

Configure an access policy that uses CRLDP authentication

You add CRLDP authentication to an access policy when you want to verify certificate revocation status before granting a user access.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Access Profiles (Per-Session Policies)
    .
    The Access Profiles (Per-Session Policies) screen displays.
  2. In the Per-Session Policy column, click the
    Edit
    link for the access profile you want to configure.
    The visual policy editor opens the access policy in a separate screen.
  3. Click the
    (+)
    icon anywhere in the access policy to add a new item.
    Only an applicable subset of access policy items is available for selection in the visual policy editor for any access profile type.
    A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
  4. From the Authentication tab, select either
    Client Cert Inspection
    or
    On-Demand Cert Auth
    , and click
    Add item
    .
    Client Cert Inspection checks the result of an SSL handshake request that occurs at the start of an SSL session. On Demand Cert Auth performs an SSL re-handshake and checks the result. The CRLDP and OCSP Auth actions require certificate information made available by one of these policy items.
  5. Click
    Save.
    The popup screen closes.
  6. Click the
    (+)
    icon anywhere in the access policy to add a new item.
    Only an applicable subset of access policy items is available for selection in the visual policy editor for any access profile type.
    A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
  7. On the Authentication tab, select
    CRLDP Auth
    , then click
    Add item
    .
    A properties popup screen opens.
  8. From the
    CRLDP Server
    list, select a server.
  9. Click
    Save
    .
    The popup screen closes.
  10. To grant access at the end of any branch, change the ending from
    Deny
    to
    Allow
    :
    1. Click
      Deny
      .
      The default branch ending is
      Deny
      .
      A popup screen opens.
    2. Select
      Allow
      and click
      Save
      .
      The popup screen closes. The
      Allow
      ending displays on the branch.
  11. Click
    Apply Access Policy
    to save your configuration.
The access policy is complete.
To apply this access policy to network traffic, add the access profile to a virtual server.
To ensure that logging is configured to meet your requirements, verify the log settings for the access profile.

Configure a client SSL profile for CRLDP

You need a client SSL profile to use CRLDP authentication from an access policy.
  1. On the Main tab, click
    Local Traffic
    Profiles
    SSL
    Client
    .
    The Client SSL profile list screen opens.
  2. Click
    Create
    .
    The New Client SSL Profile screen opens.
  3. In the
    Name
    field, type a unique name for the profile.
  4. From the
    Parent Profile
    list, select
    clientssl
    .
  5. If the access policy uses On-Demand certificate authentication, perform these substeps:
    1. From the
      Configuration
      list, select
      Advanced
      .
      Additional settings display.
    2. Select the
      Custom
      check box for
      Configuration
      .
      The settings become available.
    3. In the
      Ciphers
      field, type the name of a NATIVE cipher.
      The list of supported NATIVE ciphers includes these:
      • RC4-MD5
      • RC4-SHA
      • AES128-SHA
      • AES256-SHA
      • DES-CBC3-SHA
      • DES-CBC-SHA
      • EXP1024-RC4-MD5
      • EXP1024-RC4-SHA
      • EXP1024-DES-CBC-SHA
      • EXP-RC4-MD5
      • EXP-DES-CBC-SHA
      • NULL-MD5
      • NULL-SHA
  6. From the
    Client Certificate
    list, select the option that is applicable to the item you selected when you edited the policy.
    • Select
      request
      if the Client Cert Inspection agent is used in the policy.
    • Select
      ignore
      if the On-Demand Cert Auth agent is used.
  7. From the
    Trusted Certificate Authorities
    list, select the Certificate Authority that issues the user certificates.
  8. From the
    Advertised Certificate Authorities
    list, select the Certificate Authority that issues the user certificates.
  9. Click
    Finished
    .
A new client SSL profile is available.
CRLDP authentication does not verify a certificate revocation list if one is selected in the client SSL profile. CRLDP authentication verifies the certificate revocation list (CRL) at a distribution point defined in the CRLDP AAA server.

Add client-side SSL and access profiles to a virtual server

You associate the client SSL and access profiles with the virtual server so that the BIG-IP system handles client-side SSL traffic as specified, and so that Access Policy Managercan apply the access profile to incoming traffic.
  1. On the Main tab, click
    Local Traffic
    Virtual Servers
    .
    The Virtual Server List screen opens.
  2. Click the name of the virtual server you want to modify.
  3. For the
    SSL Profile (Client)
    setting, from the
    Available
    list, select the name of the Client SSL profile you previously created and move the name to the
    Selected
    list.
  4. In the Access Policy area, from the
    Access Profile
    list, select the access profile that you configured earlier.
  5. Click
    Update
    to save the changes.
The access policy and client-side SSL profiles are now associated with the virtual server.

Test AAA high availability for supported authentication servers

To effectively test that high availability works for your authentication servers, you should have two servers that are accessible, where you can remove one of them from the network.
High availability is supported for these authentication server types only: RADIUS, Active Directory, LDAP, CRLDP, and TACACS+.
If you configured a supported authentication server type to use a pool of connection servers, you can test the configuration using these steps.
  1. Begin a
    tcpdump
    on the Access Policy Manager, using a protocol analyzer, and scanning for packets destined for the specific port for your authentication server.
  2. Log in to the virtual server with both servers active.
  3. Using the
    tcpdump
    records, verify that the requests are being sent to the higher priority server.
  4. Log out of the virtual server.
  5. Disable the higher-priority server.
  6. Log in to the virtual server again.
  7. Verify that the request is being sent to the other server.
  8. Log out again, re-enabling the server, and try one more time to verify that the new requests are being sent to the high priority server.