Securing communications between the SafeLinx Server and other nodes

You can configure Transport Layer Security (TLS) to encrypt communications between the SafeLinx Server and remote nodes.

You can enable TLS between the following endpoints:

• SafeLinx Administrator clients and the access manager
• Nodes in a SafeLinx Server cluster
• SafeLinx Clients and the Mobile access service
• HTTP client devices and the HTTP access service
• The SafeLinx Server and LDAP or RADIUS servers
• The SafeLinx Server and remote databases
• The SafeLinx Server and internal application servers
• Messaging clients and messaging services

For more information about the types of connections that you can secure, see Security.

Generally, you must complete two main tasks to enable secure communications. First, you must place certificates on one or both endpoints of a connection. TLS relies on the use of X.509 public key certificates to establish trust between endpoints. You cannot have a secure network connection until you create a key for secure network communications and receive a certificate from a CA that is trusted on your server.

Second, you must configure the properties of the SafeLinx resource to use the certificates that you installed, and to instruct the resource to require TLS protocols.

Each endpoint in a connection maintains a PKCS12 keystore file that contains its personal certificate, if it has one, and a set of CA root and intermediate signer certificates. During the negotiation of a secure connection, one or both endpoints present their personal certificates. To verify a received certificate (and prove that the presenting entity is legitimate), recipients compare the public key on the certificate with the public key on the signer certificate. During verification, the recipient also checks the certificate's chain of authority, the expiration and activation dates, the validity period, and the revocation status.

To store the certificates that are used by different services, the SafeLinx Server includes a default PKCS12 keystore file, sl-default.p12, that has a default password, trusted. The file contains signer certs for popular certificate authorities (CAs). Other sections describe how to add certificates to the sl-default.p12 file or how to build a new .p12 file altogether.

After you store certificates on the endpoints of a connection, you use the SafeLinx Administrator to configure SafeLinx resources. For example, the properties pages for a resource might specify a default PKCS12 keystore file name or default keystore password.

To force a service to accept secure connections only, it might also be necessary to explicitly configure the service to check that incoming connections use secure protocols. For example, to require the access manager to accept secure connections only, you must select Force remote SafeLinx Administrator connections to use TLS. Finally, any time that you modify a key store file by adding or updating a certificate, you must restart the SafeLinx Server to put the change into effect.

For more information about how to secure different types of connections for HCL SafeLinx, see the following procedures.