Authentication and Encryption
A managed set of public key certificates that are issued by a certificate authority is required to enable TLS communications.
- The network server with which you are communicating has a certificate that is issued by a well-known certificate authority. The root signer certificates for some well-known CAs might be included in the default key database. However, the default key database is provided as a sample only and the certificates that it contains are included for testing purposes. In a production environment, it is best to create a new key file database and then populate it with the CA root certificates that you need. You must request the certificate from the CA and then add it to your key database
- The network server with which you are communicating has a certificate that is issued by an unknown certificate authority. In this case, create and submit a certificate request. After you receive the root certificate, add it to the key database. Use a key database that you create, rather than the default key database that is provided.
- The network server with which you are communicating has a self-signed certificate that was created by and for that network server. In this case, create a personal certificate request and add a root certificate to the key database.
Whichever scenario applies, to ensure consistent operation, it's important that you track the expiration dates of all certificates. Before a certificate expires, obtain a replacement certificate so that secure connectivity is not disrupted.
For HTTP access services, the SafeLinx Server can trust a secured connection to a specified application server, for example, a Domino® or Sametime® server, automatically. If you set up the SafeLinx Server to accept untrusted certificates, you do not have to install a trusted root signer certificate in the key database that the SafeLinx Server uses to secure the connection. For more information, see Adding HTTP access services.