HCL SafeLinx – Encrypted Communication Between the SafeLinx Client and the SafeLinx Server

After deploying HCL SafeLinx, one of the first things you should do, is to configure the communication between the HCL SafeLinx Administrator client and the HCL SafeLinx Access Manager, so that it takes place in an encrypted and secure manner.

For this, only a few simple steps are needed.

  • Generate a new p12 keystore together with a new private key and SSL certificate, which we will use for accessing the HCL SafeLinx Access Manager.
    • For this, we need OpenSSL or similar software.
    • Example using OpenSSL:

openssl req -newkey rsa:4096 -nodes -sha256 -keyout sf.key -x509 -days 3650 -subj “/C=DE/ST=Florida/O=NOW/CN=<insert_your_sf_fqdn_here>” -out sf.crt

This will create a new private key “sf.key” and a certificate “sf.crt”. The Subject name of the certificate, in this case, is not important, use it for your reference.

With the next command, we will create a new p12 keystore using the private key and the certificate we created earlier.

openssl pkcs12 -export -out sfNew.p12 -inkey sf.key -in sf.crt

  • Copy the p12 keystore to the HCL SafeLinx server.
    • You can place it into the installation folder of HCL SafeLinx server or outside of it.
  • Configure the HCL SafeLinx Access Manager to use the new p12 keystore.
    • To do this, we will use the HCL SafeLinx Administrator.
    • Connect to the HCL SafeLinx Server, switch to the “Resources” tab and open “Access Manager” properties:
Open the Access Manager properties by double-clicking on the “Access Manager” entry.
  • Change the p12 keystore.
    • Switch to the “TLS” tab and enter the path to the newly created p12 keystore, as well as the password you have set for the database.
Here you can also modify the TLS settings for the connection, for example, I am only using TLS 1.3.

Note: If you have copied the p12 keystore into the installation folder of the HCL SafeLinx server, then you can use the relative path to the file, as in the screenshot above.

  • Create a new “secure” connection profile in the HCL SafeLinx Administrator client.
    • Open the “Login Profile Details” menu:
Go to “File”, then select “Login Profiles…”.
  • In the next menu, select “Add Secure Profile…”:
This will open a new window.
  • Now we must enter the path to the p12 keystore on the client, as well as the password for opening the database:
After filling out all the information needed, click the “OK” button.

As of now, you should be able to use HCL SafeLinx Administrator to connect to the HCL SafeLinx server over an encrypted connection.


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. 🙂