Secure sockets layer protocol

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 algorithm. With a symmetric key algorithm, the same encryption key is used to encrypt and decrypt the data by both communication partners (SSL client and SSL server). As this key can be used to decrypt the data, it must be kept a secret and shared only between the two SSL communication partners. Therefore, at the beginning of an SSL connection an asymmetric key (private-public key) algorithm is used for the exchange of the secret symmetric key.

When a client attempts to connect to a secure server, an SSL handshake occurs. The handshake involves the following events:

1. The server sends its SSL/TLS digital certificate to the client.
2. The client verifies the validity of the SSL/TLS digital certificate sent by the server. For this to occur, the client must possess the root certificate of the CA that issued the SSL/TLS digital certificate to the server.

If the handshake succeeds, these events occur:

1. The client generates a random symmetric key and sends it encrypted to the server. For this encryption, the client uses the public part of the asymmetric key. This public key is contained in the SSL/TLS digital certificate issued to the server.
2. The server receives the encrypted symmetric key and decrypts it with its private key.

Data encrypted with the public key can be decrypted only with the corresponding private key, which is only in the possession of the server. With that it is guaranteed, that the symmetric key remains a secret, shared only between the client and the server.

As both the server and client now know the symmetric key, they can use it to encrypt the data transferred between server and client for the duration of the session. Data encryption and decryption with a symmetric key algorithm is much more efficient than with an asymmetric key algorithm. Therefore, the asymmetric key algorithm is only used to exchange the symmetric key at the beginning of an SSL connection. Then the symmetric key algorithm is used for the bulk of the data moved during the connection.

In a most simplistic setup for SSL communication, the SSL server only uses a single self-signed certificate. Therefore no involvement of a CA is needed. To authenticate the SSL server, an SSL client needs a copy of the server’s self-signed certificate in its own client keystore. During the SSL handshake, the server sends its self-signed certificate to the client. The client looks for the copy of this certificate in its own keystore and compares the two certificates. An exact match is expected for the SSL handshake to succeed.

Encryption modules used to implement SSL communication

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 a keystore that stores the digital certificates used in SSL communication.

There are two encoding formats for keystores, the open standard PKCS#12 format and a GSKit proprietary format called “CMS". GSKit supports both keystore formats, whereas OpenSSL only supports the PKCS#12 format. By convention, a PKCS#12 format keystore file has the filename extenstion “*.p12" and a CMS format keystore has “*.kdb" as file name extension. Up to and including version 14.10.xC3, Informix only uses the file name extension “*.kdb" for keystores, and thus propagated the use of the CMS format. With version 14.10.xC4W1 and newer, Informix also supports the file name extension “*.p12". With that we now recommend the use of the standard PKCS#12 format for keystores. Informix product installations that use OpenSSL as encryption module require the PKCS#12 format for their keystores.

The content in a keystore of either format is encrypted and a password is needed in order to access it. Therefore, both, the database server as well as the database client, need the respective password for their individual keystore in order to access it. To allow keystore access without providing the password interactively or upon startup of the database server or the database client, the keystore password can be stored in a password stash file in an encrypted format.

When using GSKit to manage a keystore, the keystore password can be stashed by specifying an extra option to the GSKit utility. Instead, with OpenSSL,you use the new utility “onkstash" to stash the keystore password. This utility "onkstash" is packaged and installed with Informix products of version 14.10.xC4W1 or newer. It accepts the file path name of the keystore and the cleartext password on the command line. With both methods of password stashing, the stash file is created with the same file path name but a different filename extension. The filename extension is either "*.sth" or "*.stl", depending on which encryption module is used. If GSKit and a GSKit utility is used, the filename extension is "*.sth". If OpenSSL and “onkstash" is used, the filename extension is "*.stl".

To get the password when accessing their respective keystore, both, the database server as well as the database client, can use the corresponding stash file if it exists at the expected location and has the correct filename extension.

While the content of a standard PKCS#12 keystore itself is independent from the encryption module in use, the password stash file is not compatible between GSKit and OpenSSL. This is because with each encryption module, a specific algorithm is used to encrypt the password in the stash file. Therefore it is important that the correct stash file, i.e. filename extension "*.sth" or "*.stl", is present for the access to the keystore.

The server keystore and its configuration

The keystore stores the SSL/TLS digital certificate issued to the server and corresponding private key, as well as CA certificates for authenticating all other servers that the Informix® server is connecting to. The server keystore must be located in the directory $INFORMIXDIR/ssl. The name of the keystore file must be server_name.p12 (or server_name.kdb with versions 14.10.xC3 or older), 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 must have a unique "label". This label is a name tag that identifies a certificate in a keystore. The term “label" is used by GSKit, whereas in OpenSSL documentation, the same is called “friendly name". When you set up Informix® to use SSL, you must specify the label of the SSL/TLS digital certificate issued to the server with the SSL_KEYSTORE_LABEL configuration parameter in the server configuration file.

The keystore is protected by a password that the server must know so that it can access the digital certificates in the keystore for SSL communications. The keystore password is stored in an encrypted form in a stash (.sth) file in the directory $INFORMIXDIR/ssl. The name of the keystore stash file must be server_name.sth. Note the use of the stash file name extension “.sth" as the Informix server uses GSKit as encryption module.

The password for the keystore is mandatory, because this password protects the server's private key in the keystore.

The permissions on the INFORMIXDIR/ssl/server_name.p12 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 of an Informix® client stores the root certificates needed for the authentication of all servers to which the client is connecting. A database client can retrieve its keystore password from a stash file. This stash file can be created with the utility onkstash (when using OpenSSL) or the utility gsk8capicmd (when using GSKit) to contain the keystore password in an encrypted form.

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.

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.p12 (or $INFORMIXDIR/etc/client.kdb for versions 14.10.xC3 and older) and $INFORMIXDIR/etc/client.sth (with GSKit) or $INFORMIXDIR/etc/client.stl (with OpenSSL) as the default keystore and keystore stash file names.