Server Groups

Overview

This section defines Server Groups: the highest level of organization within Link11 WAAP. A Server Group is based on a Proxy Template, and contains at least one SSL Certificate and a Security Policy.

Usage

The usage of Server Groups is explained in detail here: Policy Mapping and Traffic Routing.

Typically, a Server Group represents a single domain.

Administration

The main window (shown above) lists all currently defined Server Groups.

The administration (addition/deletion/editing/versioning) of these Groups follows the conventions described here.

Parameters

Name

A name for this Server Group, to be used within the interface.

Challenge's cookie domain

The domain to use when bot challenges are issued.

Description

Information about this Server Group, to be used within the interface.

Match Host/Authority Headers

The scope for this Server Group (typically this is a list of domains), specified as a regex. If this list is edited, the edits must be saved before a new SSL Certificate can be generated.

Security policy

The Security Policy for this Server Group, with its parameters displayed for convenience.

Proxy template

The Proxy Template that this Server Group is based upon.

Mobile Application Group

The Mobile Application Group for this Server Group, if any.

Server Certificate

The SSL certificate for this Server Group. The Generate button will generate a new certificate.

To avoid errors, the Server Certificate Generate button will be disabled if the Match host/authority headers field has been edited and the edits have not yet been saved.

CA Certificate

The CA Certificate to use when enforcing mTLS for the domain (read more about this). The available certificates are those defined in the CA Certificates tab of the Certificates page.

In use, CA certificates are verified against the CRLs in the Certificate Revocation List.

CA Certificate features will only be available if both of the following are true:

• An AWS NLB (Network Load Balancer is being used. (When using a Link11 Load Balancer, contact support.)

• CA Certificates have been enabled within the System DB.

Mode

Specifies how clients (i.e., end users) should present CA certificates for mTLS validation. Options are:

• [Off] Client authentication is disabled. The system will not request CA certificates from clients.

• [On] CA certificate is required for authentication. The system will request and validate CA certificates from clients.

• [Optional] CA certificate is requested but not required for authentication. The system will not require clients to provide CA certificates. However, if a client does provide a certificate, it must be valid in order for its request to be accepted. If the client provides an invalid certificate (e.g., expired, revoked, or forged), the request will be blocked.

Sending CA data to the origin

When CA Certificates are enabled, Link11 WAAP will add headers to requests before passing them to the backend.

If a CA Certificate is provided, Link11 WAAP will add it to the request header, along with these additional headers:

Header	Description	Example Value
SSL_CLIENT_VERIFY	Client certificate verification status	SUCCESS (valid) / FAILED (invalid)
SSL_CLIENT_CERT	Full client certificate in URL encoded	-----BEGIN CERTIFICATE----- ...
SSL_CLIENT_S_DN	Client's Subject Distinguished Name (DN)	CN=John Doe, O=ExampleCorp, C=US
SSL_CLIENT_I_DN	Issuer (CA) Distinguished Name (DN)	CN=Example CA, O=ExampleCorp, C=US
SSL_CLIENT_SERIAL	Unique serial number of the client certificate	1234567890ABCDEF
SSL_CLIENT_FINGERPRINT	SHA-1 fingerprint of the client certificate	5F:7C:1E:2B:...

If no certificate is provided, the following headers will be passed:

Header	Description	Example Value
SSL_CLIENT_VERIFY	Indicates no client certificate was provided	NONE
SSL_CLIENT_CERT	Empty (not passed or -)	-
SSL_CLIENT_S_DN	Empty (no subject DN since no cert exists)	-
SSL_CLIENT_I_DN	Empty (no issuer DN since no cert exists)	-
SSL_CLIENT_SERIAL	Empty (no serial number since no cert exists)	-
SSL_CLIENT_FINGERPRINT	Empty (no fingerprint since no cert exists)	-

Using CRLs to revoke client certificates

Link11 supports CRLs (Client Revocation Lists). Admins can revoke client certificates that were previously allowed for mTLS authentication, so that unauthorized or compromised clients will be rejected without waiting for certificate expiration.

When Enable CRL validation is enabled, admins can add entries to the Client Revocation List. Each entry is a URL of a CRL.

During mTLS negotiation, if a CA certificate has been specified, the client certificate is validated against the specified CRL(s).

• If the certificate is revoked, the connection is rejected with a status code of 496. The Events Log will contain an entry with a Block reason of “General: Client certificate revoked.”

• If the certificate is signed by another CA, the connection is rejected with a status code of 495. The Events Log will contain an entry with a Block reason of “General: Client certificate could not be verified.”

• If the certificate is not in the CRL, the connection succeeds (assuming other validation checks pass).

If the Client Revocation List is populated, Link11 WAAP will fetch CRL data from the specified URL(s) every eight hours.