Home
Administering
This section describes how to plan for, install, configure, operate, and manage the SafeLinx Server.
Adding and configuring resources
After you complete the installation and initial configuration, continue to prepare the deployment by configuring other network resources.
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.
Managing certificates for HCL SafeLinx
Use the GSKit to work with X.509 certificates and key database files.
Requesting a certificate without a signing request
Some Certificate Authorities do not accept signing request files. Instead, they generate the signing request internally on behalf of the requesting server and then sign it as one transaction. The CA then returns to the server two files, one containing the private key for the server to use and one containing the signed server certificate. In this example, the assumption of the two files is as follows:

Administering
This section describes how to plan for, install, configure, operate, and manage the SafeLinx Server.
- Overview
  HCL SafeLinx uses standards-based protocols to enable secure access from mobile computing devices outside the firewall to business applications and data on your organization's internal network.
- Security
  HCL SafeLinx includes a range of options for configuring the security of your network, applications, and data.
- Installation planning
  Before you install HCL SafeLinx, verify that you meet the hardware and software requirements, and that the network connections that you want to use are available.
- Installing and initial configuration
  Initial configuration and installation of HCL SafeLinx varies based on your operating system.
- Adding and configuring resources
  After you complete the installation and initial configuration, continue to prepare the deployment by configuring other network resources.
  - Types of resources
    Before a deployment can support client connections, you must add components to the SafeLinx Server. You use the SafeLinx Administrator to add and configure components. These components include resources to support HTTP access services, mobile access services, and messaging services, and resources to establish security and facilitate administration.
  - Defining a SafeLinx Server by using the SafeLinx Administrator
    Before you can define a SafeLinx Server, you must configure the access manager. If you connect to a SafeLinx Server and its access manager is not yet configured, a wizard leads you through the access manager configuration first. After that process completes, you can configure the SafeLinx Server.
  - Configuring a directory server
    You can configure the SafeLinx Server to retrieve user profile information from an external LDAP server. The directory server that you configure also provides information about how to contact other directory server services. After you configure a directory server, you can assign it to an LDAP-bind authentication profile to authenticate clients when they log in.
  - 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.
    - Securing communications between the SafeLinx Administrator and the access manager
      By default, the SafeLinx Administrator communicates with the access manager over an unencrypted connection. If you run SafeLinx Administrator from a computer that is remote to the SafeLinx Server, you can use TLS protocols to encrypt communications between the two nodes. Use the GSKit to manage the X.509 certificates that you need to establish a secure SafeLinx Administrator session.
    - Securing communications among SafeLinx Servers in a cluster
      For SafeLinx Servers that participate in a cluster, you can use TLS protocols to secure communications between subordinate and principal nodes.
    - Securing communications with an LDAP server
      You can configure Transport Layer Security (TLS) to encrypt communications between the SafeLinx Server and an LDAP server.
    - Securing connections for HTTP access services
      You can configure Transport Layer Security (TLS) to encrypt communications between HTTP access services and other nodes.
    - Configuring secure connections between mobile access services and SafeLinx Clients
      You can use transport layer security (TLS) to encrypt connections between SafeLinx Clients and a mobile access service. To support secure connections from SafeLinx Clients, you install an X.509 certificate on the SafeLinx Server, and then configure an HTTPS mobile network connection (MNC) to use that certificate. You can also specify whether the service uses standard TLS ciphers to encrypt the connection, or if it must use ciphers that are FIPS 140-2 approved.
    - Managing certificates for HCL SafeLinx
      Use the GSKit to work with X.509 certificates and key database files.
      - Creating a key database file
        GSKit stores public and private keys and certificates in a key database. A key database consists of a file with a .kdb extension and up to three other files with *.sth, *.rdb, and .crl extensions. The X.509 certificates that you use to secure connections between nodes must be stored in a key database file. HCL SafeLinx provides a set of default key database files. If you do not want to use an existing key database file, create one using the GSKit.
      - Creating a self-signed certificate
        In certain contexts, obtaining a certificate from a third-party certificate authority (CA) is unnecessary. In these cases, you can use the GSKit to create a self-signed certificate.
      - Creating a Certificate Authority
        CA is short for Certificate Authority. A CA issues certificates for email accounts, web sites, or Java applets. This only expresses a trust relationship. If you trust the CA, then you automatically trust all the certificates that have been issued by the CA.
      - Issuing a server certificate with a CA
        For clients to verify a server's identitiy, the CA must issue a signed server certificate to the server.
      - Distributing the CA root certificate to clients
        For your clients to validate the signed certificate that they receive from the server during an SSL connection, they must trust your Certificate Authority. This achieved by installing the CA root certificate on the clients.
      - Installing the certificate on client systems
        For the clients to trust a certificate, its public part needs to be distributed to the clients and stored in their key databases.
      - Installing the CA root certificate
        Instead of setting up its own certificate authority, a company may use a third-party certificate authority to sign its server certificates. The client and server must have access to the third-party CA's root certificate to verify the server certificates that are signed by the third-party CA.
      - Requesting a certificate using a signing request
        In this scenario, GSKit creates a certificate request, the third-party CA signs the certificate in the request, and GSKit imports the signed certificate into the server key database.
      - Requesting a certificate without a signing request
        Some Certificate Authorities do not accept signing request files. Instead, they generate the signing request internally on behalf of the requesting server and then sign it as one transaction. The CA then returns to the server two files, one containing the private key for the server to use and one containing the signed server certificate. In this example, the assumption of the two files is as follows:
    - Configuring TLS certificates for messaging services
      You can configure public key certificates to enable transport layer security (TLS) between messaging services and messaging applications on the internal network.
    - Configuring TLS certificates for message processing applications
      To configure a secure connection between the messaging services and applications that use the messaging services and push APIs, configure each endpoint.
  - Adding HTTP access services
    Add one or more HTTP access services to provide secure access to internal applications for remote users who do not have the full HCL SafeLinx VPN client (SafeLinx Client) installed.
  - Adding authentication profiles
    Add an authentication profile to specify how HCL SafeLinx authenticates users before it permits access to application servers. SafeLinx supports the following authentication methods: LDAP-bind, RADIUS, and certificate-based.
  - Adding a mobile access service
    If there is no mobile access service configured for the SafeLinx Server, you can add one.
  - Adding messaging services
    Add messaging services to the SafeLinx Server to enable applications to send messages to messaging clients, such as a pager or a phone, over mobile wireless networks. Messaging services include support for short message service (SMS) delivery, and mobile-originated message delivery.
  - Adding users
    If your SafeLinx deployment does not use an external LDAP or RADIUS authentication server, use SafeLinx Administrator to create user accounts. You can add users individually or in a batch mode.
- Administering
  The SafeLinx Administrator administration client is the primary tool for viewing, adding, configuring, and managing HCL SafeLinx resources. Along with the SafeLinx Administrator, you can use the HCL SafeLinx Monitor to view information about packet flow through the SafeLinx Server. You can also use a set of command line tools to perform common SafeLinx Server tasks.
- Programming reference
  There are several programming considerations of which you might want to take advantage.
- Database schema information
  HCL SafeLinx uses a DB2, Oracle, or SQL database to store tables of information about current and past activity of SafeLinx Server sessions. The following tables are created and accessed by using the qualifier name wg for DB2 installations.

Requesting a certificate without a signing request

Some Certificate Authorities do not accept signing request files. Instead, they generate the signing request internally on behalf of the requesting server and then sign it as one transaction. The CA then returns to the server two files, one containing the private key for the server to use and one containing the signed server certificate. In this example, the assumption of the two files is as follows:

About this task

host.mycompany.com.crt: This is the file that contains the signed server certificate.
host.mycompany.com.key: This is the file that contains the server's private key

To use these files, they must be converted to an industry standard format called PKCS12 before they can be imported into a key database.

Procedure

Use OpenSSL to convert the two files into a PKCS12 file as follows:

openssl pkcs12 -export -in host.mycompany.com.crt -inkey host.mycompany.com.key -out host.mycompany.com.p12 -name "CA signed"

The OpenSSL command prompts you to enter a password. This password is only used temporarily so it can be any arbitrary password. In this example, the password is set to abc. The -in parameter specifies the file that contains the signed server certificate. The -inkey parameter specifies the file that contains the server's private key.
Import the certificate from the PKCS12 file to the server's key database file as follows:
gsk8capicmd_64 -cert -import -db host.mycompany.com.p12 -pw abc -target server.kdb
The -db parameter specifies the name of the PKCS12 file. The -pw parameter specifies the password that protects the PKCS12 file. The -target parameter specifies the name of the server's key database file. You are prompted for the password that protects the target database file.
Make the imported certificate the default certificate to use for communications as follows:

gsk8capicmd_64 -cert -receive -db server.kdb -stashed -file cert_signed.arm -default_cert yes

The -db parameter specifies the name of the server's key database file. The -label parameter specifies a label of the imported certificate.

Rate this topic

5 stars 4 stars 3 stars 2 stars 1 star

Comment on this topic.

By clicking this box, you acknowledge that you are NOT a U.S. Federal Government employee or agency, nor are you submitting information with respect to or on behalf of one. HCL provides software and services to U.S. Federal Government customers through its partners immixGroup, Inc. Contact this team at https://hcltechsw.com/resources/us-government-contact. Do not include any personal data in this Comment box.