Secure sockets layer protocol
Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are communication protocols that use encryption to provide privacy and integrity for data communication through a reliable end-to-end secure connection between two points over a network.
You can use SSL for the following connections:
- IBM® Data Server Driver for JDBC and SQLJ connections with Informix®
- IBM Informix ESQL/C connections with Informix
- IBM Informix ODBC Driver connections with Informix
- DB-Access connections
- Enterprise Replication connections
- High-availability data replication (HDR) connections between an HDR primary server and one or more secondary servers of any type (HDR secondary, SD secondary, or RS secondary)
- Distributed transaction connections, which span multiple database servers
- The dbexport, dbimport, dbschema, and dbload utility connections
- Connection Manager connections between servers in a cluster
The SSL protocol provides these advantages over the Informix communication support modules (CSMs):
- SSL is a more widely used alternative to the IBM Informix CSMs.
- You can use SSL for encrypted communication with both DRDA and SQLI clients. You can use the CSMs only for connections with SQLI clients; you cannot use them for connections with DRDA clients.
You can also configure the Encrypt and Simple Password Communications Support Modules (ENCCSM and SPWDCSM) with SSL connections. However, because these CSMs provide encryption functionality, configuring the ENCCSM or SPWDCSM with SSL involves additional effort with no extra benefit.
You can configure Pluggable Authentication Module (PAM) and the Generic Security Services Communications Support Module (GSSCSM), which uses the Kerberos 5 security protocol for single sign-on (SSO) with SSL connections.
For information about tools for setting up SSL on the database server and clients, see IBM Global Security Kit (GSKit).
Digital certificates that exchange keys in SSL connections
SSL uses digital certificates, which are electronic ID cards issued by a trusted party, to exchange keys for encryption and server authentication.
The trusted entity that issues a digital certificate is known as a Certificate Authority (CA).
The CA issues a digital certificate for only a limited time. When the expiration date passes, you must acquire another digital certificate.
With SSL, the data that moves between a client and server is encrypted by a symmetric key (secret or private key) algorithm. An asymmetric key (public key) algorithm is used for the exchange of the secret keys in the symmetric algorithm.
When a client attempts to connect to a secure server, an SSL handshake occurs. The handshake involves the following events:
- The server sends its digital certificate to the client.
- The client verifies the validity of the server digital certificate. For this to occur, the client must possess the digital certificate of the CA that issued the server digital certificate.
If the handshake succeeds, these events occur:
- The client generates a random symmetric key and sends it to the server, in an encrypted form, by using the asymmetric key in the server digital certificate.
- The server retrieves the symmetric key by decrypting it.
Because the server and the client now know and can use the symmetric key, the server and client encrypt data for the duration of the session.
Keystores that store SSL keys and digital certificates
A keystore is a protected database that stores SSL keys and digital certificates. Both the client and server must have the keystore that stores the digital certificates used in SSL communication.
The server keystore and its configuration
The keystore stores its digital certificate and the root CA certificate of all other servers that Informix is connecting to. The server keystore must be located in the INFORMIXDIR/ssl directory. The name of the keystore file must be server_name.kdb, where server_name is the value specified in the DBSERVERNAME configuration parameter.
Each Informix instance must have its own keystore.
Each certificate in the keystore has a unique label. When you set up Informix to use SSL, you must specify the name of the label of the digital certificate in the SSL_KEYSTORE_LABEL configuration parameter in the onconfig file. If you do not specify a label name in the SSL_KEYSTORE_LABEL configuration parameter, Informix uses the default certificate in the keystore for SSL communication. Only one certificate in a keystore is the default certificate.
The keystore is protected by a password that Informix must know so that it can retrieve the digital certificate for SSL communications. Informix stores its keystore password in an encrypted form in a stash (.sth) file in the INFORMIXDIR/ssl directory. The name of the keystore stash file must be server_name.sth.
The password for the keystore is mandatory, because this password protects the private key for the server.
The permissions on the INFORMIXDIR/ssl/server_name.kdb and $INFORMIXDIR/ssl/server_name.sth files must be 600, with informix set as both the owner and the group, even though Informix does not enforce these permissions.
The client keystore and its configuration
The keystore on the Informix client stores the root CA certificates of all servers to which the client is connecting. A password for the keystore is optional on the client.
For Informix SQLI clients (ESQL/C, ODBC, DB-Access, and the dbexport, dbimport, dbschema, and dbload utilities), the location of the keystore and its stash file is not fixed. Instead, the conssl.cfg file in the $INFORMIXDIR/etc directory specifies the keystore and the stash file for Informix clients.
The following table shows the client configuration parameters that are in the conssl.cfg file.
IBM Informix Client Configuration Parameter | Description |
---|---|
SSL_KEYSTORE_FILE | This is the fully qualified file name of the keystore that stores the root CA certificates of all of the servers to which the client connects. |
SSL_KEYSTORE_STH | This is the fully qualified file name of the stash file containing the encrypted keystore password. |
If a conssl.cfg file does not exist or the SSL_KEYSTORE_FILE and SSL_KEYSTORE_STH configuration parameters are not set, the client uses $INFORMIXDIR/etc/client.kdb and $INFORMIXDIR/etc/client.sth as the default keystore and keystore stash file names for the client.