Tab – Client Certificates

The Client Certificates settings. If client certificate authentication is activated and if authentication is successful, Airlock Gateway will provide the following additional cookies to the back-end that contain all information about the authenticated client certificate:

AL_ENV_SSL_CLIENT_S_DN:            Distinguished name of the subject
AL_ENV_SSL_CLIENT_I_DN:            Distinguished name of the issuer
AL_ENV_SSL_CLIENT_M_VERSION:       The version of the certificate
AL_ENV_SSL_CLIENT_M_SERIAL:        Serial number of the certificate
AL_ENV_SSL_CLIENT_V_START:         Validity start time of certificate
AL_ENV_SSL_CLIENT_V_END:           Validity end time of certificate
AL_ENV_SSL_CLIENT_CERT:            Complete X509 certificate (PEM format)

SSL client certificate

Specifies whether accessing this virtual host requires the client to authenticate with a valid SSL client certificate. Together with the SSL server certificate, client certificates provide mutual authentication between Airlock Gateway and the browser. If the client authenticates himself with a client certificate, any man-in-the-middle attack is prevented.

Options:

• Not needed: No certificate is requested from the client. The virtual host may be accessed without a client certificate.
• Optional: The client may send a certificate if available, but access is still allowed without. The optional setting is normally used in combination with an authentication service that presents an alternative login page if no certificate is sent. You should not use the 'optional' setting without this additional authentication service check.
• Required: The client must send a valid certificate before accessing any of the connected mappings. If no client certificate is sent, the SSL handshake is canceled and the browser typically presents the user with a technical error message.

Note: This setting is also available for each virtual host. If you need to check client certificates, it is recommended to require a client certificate on the virtual host level, not on the mapping level. If client certificates are required on the virtual host, the connected mappings can be set to "SSL client certificate: inherit from virtual host".

Chain verification depth

The verification depth specifies the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are allowed at maximum to be followed while verifying the client certificate. The default depth of 1 means that the client certificate has to be signed by a CA which is directly known to the server.

Enable OCSP validation

This option enables OCSP validation of the client certificate chain. For more information see this Apache directive.

OCSP servers must be whitelisted in the Section – Allowed Network Endpoints, since Airlock Gateway refuses connections to arbitrary hosts on the internet.

CAs for client certificate selection

The Certificate Authorities configured in this field are sent to the client during SSL handshake. These CA names are used by the browser to show a pop-up window to the user with the appropriate client certificate out of the available client certificates. Thus, this is only a usability feature which simplifies the selection of the correct client certificate. Apache allows access if the client certificate is signed by any of the Certificate Authorities listed in the field, as long as they are signed by a CA for chain validation and the verification depth is fulfilled. Usually intermediate CAs are configured in this field to prompt the user only for a subset of client certificates. For more information see this Apache directive.

Note: The CA certificates configured in this field must be in PEM format.

CAs for chain validation and OCSP server validation

CA certificates which shall be used as "trust anchor" during chain validation have to be inserted in the field "CAs for chain validation". For more information see this Apache directive.

If "Verification Depth" is set to the value N all client certificates with a valid chain of length smaller or equal to N, to one of the certificates entered under "CAs for chain validation", will be accepted for authentication. To accept only certificates which were directly issued by a CA whose certificate was entered under "CAs for chain validation" set the "Verification Depth" to 1. If "Verification Depth" is set to a value greater than 1 also certificates issued by intermediate CAs not listed under "CAs for chain validation" will be accepted. For more information see this Apache directive.

Certificate revocation list (CRL)

Airlock Gateway provides the possibility to upload the PEM representation of certificate revocation lists. If a client certificate is on such a list, it will not be accepted and the connection will fail. Although Airlock provides this functionality, it is recommended to check certificates against CRLs and other types of blacklists within the authentication service and not in Airlock.

For example, if the client certificate is blocked on Airlock Gateway using the CRL, the corresponding SSL handshake will fail and the user will not be able to connect to the authentication service. Typically, it is better to let technically valid certificates connect to the authentication service and verify the content of the certificate there. That is also true for certificate validity, expiry etc. It does not mean that anybody can connect to the authentication service since the user first needs a technically valid certificate. Use the upload, download and delete buttons to modify the CRL parameter. After that, confirm the settings on the page and activate the new configuration as usual for the changes to take effect.

Automatic update of CRLs

Airlock Gateway allows you to periodically update your certificate revocation lists (CRL). For more information please read this Techzone Article.

• Typically, only the authentication service will interpret the certificate information, map it to a registered user profile and issue the appropriate credentials to the current user's session. A commonly used technique is to configure one dedicated URL to require an SSL certificate. This URL is mapped to the authentication service which will get the certificate information and interpret it. In order to initiate the certificate authentication process on the client-side, a public login page just needs to point a web link to that special URL. As soon as the user clicks this link, the user's browser will initiate the client certificate authentication process with Airlock Gateway. The authentication service will get the certificate information just like any other authentication information if the authentication step is successful.
• Airlock Gateway services of a virtual host can be temporarily disabled by checking the maintenance page option.