Client Authentication Policies

Client certificates enable network administrators to authenticate clients using a certificate generated by a central Certificate Authority (CA). When it is necessary to authenticate a client during the handshake process of the SSL, AppDirector sends a client certificate request to the client. To complete the handshake, the client then sends the client certificate to AppDirector to be validated. If the certificate is valid then the handshake process is complete on both sides and can start sending data. If the certificate is not valid then the session is terminated.

Performing Client Authentication

Authentication Setup

1.	An Administrator sets up an Organizational CA. As part of this process, the CA has a self-signed (or third-party) Certificate installed on it to identify it.

2.	The CA server generates Client Certificates for the Clients. Clients install certificates into their Browser repository.

3.	To create trust between the CA and the Authentication Server (AppDirector), the Client CA certificate is imported into AppDirector.

4.	The Administrator then sets up an OCSP server (may be the same CA, or a central OCSP of a few organizational CAs).

5.	An OCSP URL for sending the OCSP validation requests is set up on the OCSP server

6.	The OCSP URL is updated as a field inside the Client Certificate and/or AppDirector.

7.	Optionally, the OCSP server receives a certificate for signing OCSP responses or the OCSP certificate is imported into AppDirector to validate OCSP response

8.	CRLs are generated by Clients CA and updated regularly for the OCSP server.

Automated Authentication Flow

1.	As part of the SSL handshake, the Client sends a Client Certificate to AppDirector.

2.	AppDirector matches the Client CA issuer field against the Client CA that is trusted according to its configuration.

3.	AppDirector checks the Certificate’s valid dates.

4.	AppDirector then sends an OCSP validation request to the OCSP server URL.

5.	The OCSP Server generates a response (valid/invalid), signs it with its own certificates and returns it to AppDirector.

6.	AppDirector validates the response with the OCSP Certificate.

7.	If all is verified, a SSL tunnel is established.

Certificates

The certificate is a digitally signed indicator that identifies the server or user. This is usually provided in the form of an electronic key or value. The digital certificate represents the certification of an individual business or organizational public key. It can also be used to show the privileges and roles for which the holder has been certified. It also includes information from a third party verifying identity and authentication is needed to ensure that persons in a communication or transaction are who they claim to be.

A basic certificate includes:

The certificate holders identity.

The certificate‘s serial number.

The certificate holders expiry date.

A copy of the certificate holder’s public key.

The identity of the Certificate Authority (CA) and its digital signature to affirm the digital certificate was issued by a valid agency.

To certify a public key, prospective subscribers requesting the certificate must register their public key with a CA. Once this is performed and the CA approves the request, a certificate is generated and issued to the subscriber.

To authenticate the client’s identity a CA certificate has to be imported into AppDirector. This CA certificate is used when AppDirector receives a client certificate and attempts to validate it. The client certificate is valid only when its issuer conforms to the CA certificate that was imported into the AppDirector. Client certificates must be installed on the client browsers by the organization or by the clients. You can check if a valid client's certificate was revoked by the CA by configuring AppDirector to check its status using OCSP (Online Certificate Status Protocol).

Certificate Revocation List (CRL)

AppDirector supports downloading CRLs from CDPs using the CDP URI embedded in client certificates or URI statically configured in the AppDirector authentication policy.

This means that multiple CDPs can be used for a single service. For example, if a single Web site supports Client Certificates from multiple CAs (for example, the Web site of a central bank that supports users using Client Certificates from different regional banks), then various CDP URI locations are extracted from the client’s certificates. As the downloaded CRL files include the validity period in which the list is valid and after which it should be updated, AppDirector fetches a new copy of the list when validity requires it.

When using CDP, Client Certificate verification is performed in the same way as importing CRLs manually. Once a CRL is downloaded using CDP, all clients that arrive at the SSL tunnel are requested to present a Client Certificate and then AppDirector checks if they appear in the CRL. If the Certificate displays in the CRL, then the request is denied.

The CRL authorizes the client and specifies which customers must be denied access to the Web server when this feature is enabled. This list must be updated periodically by importing it into AppDirector. To add a newly revoked certificate to the CRL, it must be added to the list of existing revoked certificates and then the file must be imported to the platform. For example, a bank main office might need to revoke a certificate of one of its customers. The bank must add this customer’s certificate to the CRL. Once the CRL file is modified, it must be imported into AppDirector so that requests received from the revoked certificate are denied access.

Note: Supported formats for CRL (the *.crl extension) are currently PEM and DER.

1.	When a CRL is selected as a mode of verification in an Authentication policy, a CRL file must be uploaded to AppDirector.

2.	Upon receiving a new CRL file (manually or by CDP) the following validations are performed:

a.	The signature is validated to ensure that it was not altered.

b.	If the signature is OK, another check is performed to ensure that the file is in its validity period.

3.	When the Client certificate is presented to AppDirector, its serial number is looked-up in the CRL and if it displays, then authentication is rejected.

Certificate Distribution Point (CDP)

Certification Authorities (CA) are responsible for the distribution and availability of CRLs (Certificate Revocation Lists) to the community (clients/organizations) that they serve.

Often this is achieved by posting the CRL to an X.500 directory server managed by the CA. It is then the responsibility of the end user, or the end user's software application to retrieve the CRL from the X.500 directory. There are alternative distribution methods such as e-mailing the CRL to all end users or posting the CRL to a Web site so that end users can download the file.

The locations where you can find posted CRLs are called CDPs (Certificate Distribution Points). CRLs posted in CDPs can be accessed by LDAP and HTTP. Each CDP is characterized with a complete URI, which is used to access the CRL, for example; http://www.example.com/crl/crl-site.txt.

Online Certificate Status Protocol (OCSP)

Instead of using CRLs, AppDirector can verify the revocation status of Client Certificates by using the on-line method of OCSP (Online Certificate Status Protocol), defined in RFC 2560.

OCSP eliminates problems related to CRL management and distribution, such as CRL updates. Each Client Certificate is tested when a new connection is established. This method is slower yet extremely safe. The client is blocked at the moment that the Client Certificate is revoked, not only when a new CRL is received.

When a request is sent to an OCSP responder for certificate status information, it receives a digitally signed response that can have one of the following three states:

A good certificate status indicates that the certificate is not revoked at the time of the request, according to the OCSP responder's knowledge of the certificate's status. This does not mean that the certificate was ever issued, or that the time of the response was within the certificate's validity interval.

A revoked certificate status indicates that the certificate is either permanently revoked or temporarily suspended.

An unknown certificate status indicates that the responder does not know about the certificate requested.

To configure AppDirector Client Authentication policy

1.	From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > Client Authentication Policies. The Authentication Policies pane displays.

2.	Set the parameters.

 

Parameter	Description
Policy Name	Name of the Policy.
General Settings
Trusted CA	Client CA certificates to be used
CA Depth	Defines the maximum intermediate CAs in the CAs chain that AppDirector searches to validate the link between the client's certificate to the specified Client CA certificate. Default: 2
CA Required	Defines whether AppDirector verifies that the specified CA in the Client CA Certificate field has signed the client certificate. When disabled, any certificate that the client presents is accepted, regardless of whether it was issued by the trusted CA. If OCSP is enabled then the revocation test is performed. Values: enabled, disabled Default: enabled
Redirection URL	Defines the URL to redirect clients to when Client Authentication fails and you want to notify this to users in a graceful way rather than by default browser message. Default: Empty
Certificate Revocation Check	Defines whether AppDirector verifies that the client's certificate has not been revoked by the CA (Certificate Authority) before completing the SSL/TLS handshake. The revocation check can be performed using OCSP. Values: OCSP, CRL, CDP, Disable Default: Disable
Certificate Validation Policy	Defines the Client's certificate field validation policy to be used during Authentication. For more information about Certificate Validation Policy see Certificate Validation Policies.
Pass Certificate info in Headers	Allows forwarding Client Certificate information to the application servers using HTTP headers. For more information see Certificate Information Headers. Note: When full certificates are sent in HTTP headers, they are encoded in PEM format.
OSCP Parameters (when Certificate Revocation Check is set to OCSP)
OCSP URI	Specify a URI for OCSP certificate status check.
Response Allowed Signing Algorithm	Defines the specific signature algorithms allows for signing OCSP responses. Values: All, MD5, SHA1, SHA256, SHA384, SHA512 Default: All
Verify Certificate Chain	When enabled, an OCSP request is sent for every certificate in the chain, when disabled, an OCSP request is sent to client certificate only.
Response Time Deviation (Seconds)	Allows for overlooking small deviations between AppDirector and OCSP server timestamps for OCSP signatures verification. Values: 0 – 3600 seconds Default: 0 Note: For correct time validation, Radware recommends using NTP, and you must define the AppDirector Time-Zone. See Time Settings.
OCSP Cache Time (Minutes)	Defines the time for which validated OCSP responses are cached. Since CA servers update the CRLs on the OCSP parochially (every 12 hours or 24 hours), there is no need to overload the OCSP server with repetitive OCSP requests for the same certificate. The Cache is per Client Authentication or TSL Authentication policy and entries are not shared between policies. The OCSP cache time is defined in minutes. Values: 0 – 180000 Default: 0 Note: When set to 0, OCSP Cache is disabled.
Send Nonce	An OCSP nonce offers an optional tool for a relying party to determine that it is receiving up-to-date certificate status information from a responder. A nonce is a random sequence of 20 bytes placed in an OCSP request. The responder must use its secret key to sign a response containing this nonce. Values: Enabled, Disabled
OCSP URI Precedence	Controls OCSP URI precedence, whether to use the user-configured URI or the URI that is embedded in the client's certificate.
CDP (when Certificate Revocation Check is set to CDP)
CDP Backup URI	LDAP or HTTP URI to be used to fetch CRL files as an alternative to the URI that appears inside the client’s certificates CRL location extension. If the initial CDP lookup fails or times out, the lookup continues with the CDP backup URI.
CDP Backup Password	Password to be used when accessing CDP to fetch new CRL.
CDP Backup1 Username	Username to be used when accessing CDP to fetch new CRL.
CDP Backup Update Interval (Minutes)	Defines, in minutes, the time for periodical access to fetch CRL from CDP. When set to 0 (zero) the updates are performed according to NextUpdate field in the current CRL.
CDP General Grace Time (Minutes)	Defines for how long a CRL may be used beyond the NextUpdate value that appears inside the CRL indicating when it needs to be updated.
Last successful CRL fetch	Last successful download of CRL.
Last unsuccessful CRL1 fetch	Last unsuccessful download of CRL.
CRL (when Certificate Revocation Check is set to CRL)
CRL File Name	Latest CRL filename.

3.	Click Set.

4.	Go to Layer 4 Policies.

5.	In the required Layer 4 policy, select the Client Authentication policy that you configured.

Purge OCSP Cache

You can purge None of the OCSP cache information or ALL (for all the Authentication policies).

To purge OCSP cache

1.	Select a policy name from the drop-down list with policies names.

2.	Click Purge. The Cache is purged.

Purge CDP Cache

You can purge None of the CDP cache information or ALL (for all the Authentication policies).

To purge CDP cache

1.	Select a policy name from the drop-down list with policies names.

2.	Click Purge. The CDP is purged.

Notes:  

With Generic-SSL offloading, you cannot use HTTP headers to forward data to servers.

With each Certificate of Client CA you can bind multiple CA Certificates to a single Client Authentication policy by concatenating multiple certificates into a single import operation. To use multiple client CA certificates on the same Client Authentication policy: open the CA’s PEM certificate files with a text editor and copy the content. In the AppDirector certificate import, paste the certificates text into the text box together one after the other. During the import they are concatenated.