IBM Support

Renegotiation of an SSL session fails between WebSEAL and Chrome browser

Question & Answer


Question

How to configure WebSEAL to support SSL certificate authentication with Chrome browser when WebSEAL is configured with accept-client-certs=prompt_as_needed ?

Cause

IBM Security Access Manager (ISAM) 9.0 Fixpack 1 (FP0001) readme file states:
"The chrome browser does not support the renegotiation of an SSL session, which means that the accept-client-certs=prompt_as_needed WebSEAL configuration entry (for SSL certificate authentication) was not functioning correctly. WebSEAL has been enhanced to overcome this browser limitation by allowing a secondary port to be configured and used when a client certificate authentication is determined to be necessary."

Fixpack readme file indicated about an option to configure secondary port but documentation on how to implement configuration was not included in the readme file.

Answer

A new configuration parameter, secondary-port, is added to [certificate] and [interfaces] stanzas that modifies the behavior of accept-client-certs=prompt_as_needed:

1. The interface that has been configured with accept-client-certs=prompt_as_needed and has a non-zero secondary-port is not used to prompt for certificates.
2. A new macro is provided, %SECONDARY_BASE%.
  • When secondary-port is non-zero, the macro has the value:
    • HTTPS://%HOSTNAME%:<secondary-port>
  • When secondary-port is zero, or not set, the macro has an empty (zero length) value.
3. The certlogin.html and stepuplogin.html pages are updated to use the %SECONDARY_BASE% macro.
4. The “Certificate Login” button POSTs to %SECONDARY_BASE%/pkmslogin.form
5. In this mode the [certificate] cert-prompt-max-tries parameter is not used, and the login requires significantly less redirects to operate.

It is expected that if secondary-port is set to a non-zero value, then a secondary interface must be configured for that secondary port with the following set accept-client-certs=required
 
The behavior of interfaces configured with accept-client-certs=required is also modified so when a successful authentication that uses client certs occurs on a request accessing /pkmslogin.form, WebSEAL will redirect back to a request cached due to being interrupted by the login process. The following parameter must be set
  [server]  cache-host-header=yes
The new behavior allows WebSEAL to redirect the request from /pkmslogin.form where it would previously not disrupt the access to the page requested by prompting the user for a certificate.

A new configuration parameter, always-neg-tls, is added to [server] and [interfaces] stanzas.
If parameter is set to
always-neg-tls=yes any TLS connections on this interface will only process one request. After the request is complete the connection is closed and the TLS session destroyed. This setting forces a full TLS session renegotiation every connection and is an expensive method of using TLS so only enable this option if necessary. Typically it could be enabled on the interface the secondary-port is referring to so the TLS on that interface always requests a certificate from the client (browser).
Review APAR IV92957 mentioned in the "Related Information" section to find details about use-secondary-listener parameter.

Configuration

Assuming the existing WebSEAL prompt_as_needed configuration is:
  [server]  https = yes  https-port = 443  network-interface = 172.16.99.10  [ssl]  webseal-cert-keyfile-label = WebSEAL-Test-Only  [certificate]  accept-client-certs = prompt_as_needed


Convert this to using the secondary port method:
  [server]  https = yes  https-port = 443  network-interface = 172.16.99.10  [interfaces]  interface1 = network-interface=172.16.99.10;https-port=444;certificate-label=WebSEAL-Test-Only;accept-client-certs=required;always-neg-tls=yes;use-secondary-listener=yes  [ssl]  webseal-cert-keyfile-label = WebSEAL-Test-Only  [certificate]  accept-client-certs = prompt_as_needed  secondary-port = 444



These changes can also be done via the LMI:
(Note values do not match previous example, screen captures are for reference)






Implications
  • There is an extra port that needs to be exposed from WebSEAL.
  • If a load-balancer is placed between WebSEAL and the browser, then it must be configured to so clients are sticky to the same WebSEAL instance for both ports.  This is to ensure that a client accessing the different HTTPS ports on WebSEAL be sent to the same WebSEAL instance (or at least the primary and matching secondary-port access go to the same WebSEAL server).   This requirement might be lifted if the DSC is being used.

[{"Business Unit":{"code":"BU008","label":"Security"},"Product":{"code":"SSPREK","label":"Tivoli Access Manager for e-business"},"Component":"WebSEAL;Reverse Proxy","Platform":[{"code":"PF004","label":"Appliance"}],"Version":"9.0.0.1;9.0.1;9.0.2;9.0.2.1;9.0.3;9.0.4;9.0.5;9.0.6;9.0.7;9.0.7.1","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Product Synonym

TAM;ITAM;IBM Tivoli Access Manager

Document Information

Modified date:
26 March 2020

UID

swg21983582