Configuring secure connections between HTTP access services and clients

You can use transport layer security (TLS) to encrypt connections between remote HTTP clients and an HTTP access service. You can specify whether the service uses standard TLS ciphers to encrypt the connection or if it uses ciphers that are FIPS 140-2 approved. You can also configure the service to require client devices to present X.509 certificates when they connect to the server.

About this task

You configure TLS connections by using the GSKit to add and manage certificates, and then editing properties for the HTTP access service.

To enable the server to prove its identity during TLS protocol negotiations, you store an X.509 certificate for the HTTP access service in a Cryptographic Message Syntax (CMS) key database file on the SafeLinx Server. You can use the default key database file, http.trusted.kdb, or create your own file. The key database is secured with a stash password that is encrypted and stored in a stash password file. The default stash password file is http.trusted.sth. The default stash password is trusted.

When you first test secure connections, you can generate and use a self-signed certificate. However, for greater security it is best to use third-party certificates to secure connections with remote clients.

After you receive a signed certificate into the key database, use the SafeLinx Administrator to configure the HTTP access service to enable TLS and use the new certificate.


  1. Obtain a certificate for the HTTP access service, and add it to the default HTTP access service key database (http.trusted.kdb), or another key database of your choosing.

    For information about obtaining a certificate from a third-party certificate authority, see Requesting an X.509 certificate from a third-party certificate authority.

    For information about adding certificates to a key database file, see Adding certificates to a key database file.

  2. From the SafeLinx Administrator, right-click the HTTP access service that you want to configure and then click Properties.
  3. Open the Service page and in the Service URL field, verify that the protocol identifier is set to https.
    For example,
  4. Verify the information in the File name of key database and File name of stash password fields.

    The SafeLinx Server provides a default key database (http.trusted.kdb) and stash password file (http.trusted.sth) for the HTTP access service. If you used files other than the default files, replace the default entry in each field with the correct file name. If you placed files in a directory other than the default SafeLinx Server installation directory, type the full path for each file.

  5. To require clients to use secure protocols to connect to the HTTP access service, from the Service page of the HTTP Access service properties. select Use secure connection.
  6. Specify which parties must present certificates. Choose one of the following options:
    • Choose Server session if you want to require a certificate from the HTTP access service only. This is the default setting.
    • Choose Server session with client certificate validation to enforce two-way certificate validation. When this setting is in effect, an HTTP client must provide its certificate first during the SSL handshake. Only after the client certificate is accepted, does the HTTP access service present its certificate. Typically, this setting is combined with a further credential checking to permit access to HTTP clients that have valid certificates only.
    For more information about using two-way certificate validation, see Client certificate authentication for HTTP access services.
  7. Specify the ciphers that the SafeLinx Server uses to negotiate TLS connections with HTTP clients. From the SSL Ciphers page of the HTTP access service properties, choose one of the following options and then select the individual ciphers that can be used to encrypt connections.
    • Click Use only FIPS 140-2 approved ciphers to require the use of cryptographic modules that are certified by the U.S. government in Federal Information Processing Standards (FIPS) publication 140-2, Security requirements for cryptographic modules.
    • Click Use standard ciphers to use the default TLS cryptographic standards to secure connections.
  8. From the SafeLinx Administrator, restart the SafeLinx Server.
  9. If you have configured HTTP application servers, log in from an HTTP client application to verify that the certificate is working.
    If the HTTP Service does not secure incoming connections, view the wg.log file for help in understanding whether the issue is certificate-related. On Linux, the wg.log file is in /var/adm. On Windows, you can find the file in \Program Files\HCL\SafeLinx Server\logs.