Securing communications between the SafeLinx Server and other nodes
The SafeLinx Server and the services that it hosts exchange data with clients on the external network and with different types of servers on the internal network. To ensure the privacy of these communications, you can use TLS protocols to encrypt connections 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 key database 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 set of default key file databases. You can use the default key database files, or create your own. Table 1 lists the default key database files and the services that they support.
|Default key database file||Secure connection that uses the file|
|cm.trusted.kdb||Between nodes in a SafeLinx Server cluster
Between the SafeLinx Server and an MDM service
|http.trusted.kdb||Between client devices and an HTTP access service|
|ppg.trusted.kdb||Between client devices and Messaging services|
|wgmgrsd.trusted.kdb||Between a SafeLinx Administrator client and the access manager|
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 key database file name or stash password file name. If you use different files, you must update the references to those files.
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 SSL. Finally, any time that you modify a key database 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.