Use of the WebSEAL test certificate for SSL connections
Client-side certificate authentication must take place over a Secure Socket Layer (SSL) connection. The SSL connection is established prior to the certificate authentication process. The SSL connection can be established when a client attempts to access a resource over HTTPS. When the resource does not require authenticated access, the client negotiates an SSL session with the WebSEAL server. The SSL session is established when the client and server (WebSEAL) examine each other's certificate and accept the validity of the signing authority.
In order to enable the establishment of SSL sessions on a new WebSEAL server, WebSEAL contains a self-signed test server certificate. WebSEAL can present the self-signed certificate to the client. If the client accepts the certificate, the SSL session is established.
This test certificate is not suitable for permanent use by the WebSEAL server. Although this test certificate allows WebSEAL to respond to an SSL-enabled browser request, it cannot be verified by the browser. This is because the browser does not contain an appropriate root Certificate Authority (CA) certificate — as is the case for when the browser receives any self-signed certificate for which a root CA certificate does not exist. Because the private key for this default certificate is contained in every WebSEAL distribution, this certificate offers no true secure communication.
To ensure secure communication over SSL, WebSEAL administrators must obtain a unique site server certificate from a trusted Certificate Authority (CA). We can use the LMI to generate a certificate request sent to the CA. We can also use the LMI to install and label the new site certificate.
Use the webseal-cert-keyfile-label stanza entry in the [ssl] stanza of the WebSEAL configuration file to designate the certificate as the active WebSEAL server-side certificate (this setting overrides any certificate designated as “default” in the keyfile database).
If we require different certificates for other scenarios (such as for mutually authenticated junctions), we can use the LMI to create, install, and label these additional certificates. See Configuration of the WebSEAL key database file.
It is also important to ensure that validation of certificates includes checking of Certificate Revocation Lists (CRLs). Configure WebSEAL to access the appropriate LDAP server as an LDAP user with sufficient permission to access the appropriate CRLs. Supply values for the following configuration file entries:
[ssl] crl-ldap-server crl-ldap-server-port crl-ldap-user crl-ldap-user-password
WebSEAL can be configured to cache CRLs. To configure the cache, supply values for the following configuration file entries:
[ssl] gsk-crl-cache-size gsk-crl-cache-entry-lifetime
Instructions for setting values that affect CRL access and handling, including valid ranges for cache settings, are in the web reverse proxy Stanza Reference topics.
See also Configuration of the CRL cache.
Parent topic: Key management
Related concepts
- Key management overview
- Key management in the Local Management Interface
- Client-side and server-side certificate concepts
- Configuration of the WebSEAL key database file
- Certificate revocation in WebSEAL
- CRL distribution points
- Configuration of the CRL cache