HCL SafeLinx – SSL Issues

If you are using HCL SafeLinx and you cannot access your websites using “HTTPS” and you see the following error in the HCL SafeLinx “wg.log” log file:

PKCS12_parse failed, return 587686001 (error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure

Then, most likely, either you are using the wrong password for the “P12” file, database where your SSL certificates reside, or your HCL SafeLinx Server is installed on Linux and the password for the “P12” file contains some special characters that need to be escaped. In my case, it was the later.

As a workaround I created a new “P12” file, with corresponding certificates, without using any special characters in a password. After that, I just restarted all HCL SafeLinx processes and everything was fine once again. I could access all configured sites via SafeLinx using HTTPS.

This issue occurred in HCL SafeLinx version 1.1.1 on Red Hat Linux.

HCL SafeLinx 1.1.1 Version available!

Since Monday there is a new version of HCL SafeLinx available. Make sure to install it, as it contains some very important fixes. Some SafeLinx functions will not work properly without it. For example, the HCL Nomad client connectivity will not be possible without this fix.

SafeLinx 1.1.1 provides fixes for the following issues:

SAFE-540: Failover not working properly for Verse mail. When configured in failover or round robin mode connect failures would not trigger a failover to other Domino servers.
SAFE-568: Redirect port not working when multiple HTTP services are defined. If multiple HTTP services are configured to redirect from port 80 to port 443, only the first service would get redirected.
SAFE-569: Replace EULA with master copy.
SAFE-573: Secure LDAP Bind authentication broken. TLS start returns -12, LDAP_NOT_SUPPORTED. Added option to allow untrusted certificates.
SAFE-585: Add cache-control to login page to cache images.
SAFE-592: Dead-Lock in restart after crash when multiple HTTP services are defined on the same port.
SAFE-598: MEM_BAD_POINTER on exit of wg_acct.
SAFE-600: Nomad mobile-only configuration fails to generate userConfig.json.
SAFE-601: Crash in network congestion recovery. Simultaneous tear down may cause race condition.
SAFE-602: Migration fails if KDB password contains shell special characters. Issues with migration when multiple HTTP services are defined, only the first service gets migrated properly.
SAFE-626: Secure Administrator configuration not reading the PKCS12 password from wgated.conf.
SAFE-627: Add Strict-Transport-Security and generic header token add function.

Official Release Notes:

HCL SafeLinx 1.1.1 & HTTP Strict-Transport-Security

After a SafeLinx Deployment I wanted to set the HTTP Strict-Transport-Security header, but there was nothing in the documentation about it, and I also could not find any option regarding this in the SafeLinx Administrator client settings. So I opened a Support case.

According to the support you can use the command line on the HCL SafeLinx server to set the HTTP Strict-Transport-Security header as well as any other token header. Example of the command:

chwg -s ibm-wlHttpService -l http-serviceX -a hcl-strictTransSec=TRUE -a hcl-httptokens=”MyToken: my value” -a hcl-httptokens=”MyTOken2: my value2″

As of the upcoming HCL SafeLinx 1.1.1 release, which is coming next week, there is going to be a form to set it in the HCL SafeLinx Administrator client. Also, the HTTP Strict-Transport-Security header will be enabled by default in this release. Yay! 🙂

HCL Safelinx – Untrusted Certificate Issue

A few days ago I came across a rather weird issue with HCL Safelinx and HCL Domino. After setting up HCL Safelinx, it was not possible to access the Websites hosted by an HCL Domino Server. The user would just get an HTTP Error, “503 – Service Unavailable”.

I checked the network, no issues there, Safelinx could access the Domino Server via port 443 without any issues. SSL Certificates from both Domino and Safelinx were trusted, no issues could be seen there via Internet Browsers (Firefox, Chrome, …) and a quick check with “openssl” didn’t show any problems. The SSL Cipher configuration was also Ok, on both Safelinx and Domino.

After turning on all possible trace and debug settings on Safelinx, the following errors could be observed:

75613:936171264 (Sep 18 2020/10:06:12.4153)[WARN] SSLPort::raw_connect: open returns rc=414 (Unknown error — 414)
75613:936171264 (Sep 18 2020/10:06:12.4154)[ERROR] SSLPort: failed to open secure connection (rc = 414)–> <Domino_Server_IP>:443
75613:936171264 (Sep 18 2020/10:06:12.4154)[LOG] SSLPort::connect: (return), rc=-1
75613:936171264 (Sep 18 2020/10:06:12.4154)[WARN] HTTP-AS: failed to connect to server ‘<Safelinx_Server_IP>:56796 –> <Domino_Server_Hostname>:443’ (Unknown error — 0)
75613:936171264 (Sep 18 2020/10:06:12.4155)[DEBUG] setup connection, elapsed time: 23ms
75613:936171264 (Sep 18 2020/10:06:12.4155)[WARN] http-service1: failed to setup back end connection, elapsed time: 23ms [<Username>]
75613:936171264 (Sep 18 2020/10:06:12.4156)[HTTPAS]httpServerResponse: HTML pkt size: 2787
HTTP/1.1 503 Service Unavailable
Server: HCL Verse via SafeLinx
Connection: close
Content-Type: text/html; charset=utf-8

I have set some Domino HTTP Debug parameters, but I had to wait for the window where I could restart the Domino/HTTP Task. So I have decided to try setting “Accept untrusted certificates from internal servers” on HCL Safelinx.

Screenshot of the Safelinx setting.

And guess what, after restarting Safelinx, the users could access Domino Web applications without any issues.

I hope this saves you some time. 🙂