Secure Sockets Layer (SSL) protocol is a cryptographic protocol that provides privacy and security for data communication over the network. It uses encryption to provide a reliable end-to-end, secure, and authenticated TCP/IP connection. SSL uses digital certificates to exchange keys for encryption, server authentication, and optionally, client authentication.
Digital certificates allow unique identification of an entity. They are, in essence, electronic ID cards issued by trusted parties. A digital certificate serves two purposes: it establishes the owner's identity, and it makes the owner's public key available. A digital certificate is issued by a trusted authority (a certificate authority or CA) and is issued only for a limited time. When its expiration date passes, the digital certificate must be replaced.
The digital certificate contains specific pieces of information about the identity of the certificate owner and about the certificate authority, including:
- The owner's distinguished name
- The owner's public key
- The date the digital certificate was issued
- The date the digital certificate expires
- The issuer's distinguished name (this is the distinguished name of the issuing CA)
- The issuer's digital signature
How to request digital certificates
A digital certificate is required to run SSL. To acquire a digital certificate, generate a request using iKeyman (or GSKCapiCmd) and submit the request to a CA. The CA will verify your identity and send you a digital certificate. Digital certificates are stored in key database (also known as keystore). Let's take a look at how to create a certificate request using GSKCapiCmd:
- Generate the certificate request using the
gsk7capicmdcommand, as shown in Listing 1:
Listing 1. Generate a certificate request
gsk7capicmd -certreq -create -db demo.kdb -pw snoopy -label demolabel -dn "CN=lenexa.ibm.com,O=ibm,C=US" -file demo.cert
- demo.kdb is the name of the key database (or keystore) in which the certificate request is to be created
- snoopy is the password to the key database
- demolabel is the unique name for the certificate in the key database
- demo.cert is the file to which the certificate request will be stored
For instructions on creating a key database and a complete list of command line options, refer to GSKCapiCmd User Guide.
- Verify that the certificate request was successfully created:
- Make sure that the key database recorded the request. The
command, as shown in Listing 2, should list the label created
Listing 2. List certificate requests
gsk7capicmd -certreq -list -db demo.kdb -pw snoopy
- View the contents of the certificate request file:
Listing 3. View the contents of the request
gsk7capicmd -certreq -details -db demo.kdb -pw snoopy -label demolabel
- Make sure that the key database recorded the request. The command, as shown in Listing 2, should list the label created earlier:
- Send the newly created file to certificate authority (CA).
It usually takes two to three weeks to get a certificate from a well-known CA. While waiting for an issued certificate, you can create a self-signed digital certificate to test SSL sessions between clients and the server. A self-signed digital certificate contains the owner's distinguished name, the owner's public key, and the owner's own signature over these fields. Self-signed digital certificates are used for testing purposes or when you are acting as your own CA for a private Web network.
How SSL works
With SSL, the data going back and forth between client and server is encrypted using a symmetric key (secret key) algorithm. An asymmetric key (public key) algorithm is used for the exchange of the secret keys to be used in symmetric algorithm and for digital signatures. The asymmetric algorithm uses the public key in the server's digital certificate. With the server's digital certificate, the client can also verify the server's identity.
At the beginning of an SSL session, an SSL handshake is performed. This handshake produces the cryptographic parameters of the session. A simplified overview of how the SSL handshake is processed is shown in the diagram below.
Figure 1. SSL handshake
Steps to configure IDS to use SSL
Let's take a look at how to configure IDS to use SSL using "self-signed certificates":
- Set up ONCONFIG:
- Configure the server name and server aliases according to the
requirements. For example, let's configure
lenexa_onto use regular TCP,
menlo_onto use SSL, and
portland_onto SSL for DRDA clients:
Listing 4. Set DBSERVERNAME and DBSERVERALIASES
DBSERVERNAME lenexa_on DBSERVERALIASES menlo_on,portland_on
- SSL encryption and decryption operations are performed on
Encrypt VP. Depending on the load on the system, configure
Encrypt VPs using the
VPCLASSonconfig parameter (as shown in Listing 5). If
VPCLASSis not configured, IDS will start one Encrypt VP by default.
Listing 5. Set
- Depending on the load of the system, configure poll threads
for SSL connection using the
NETTYPEonconfig paramter (as shown in Listing 6). If poll threads are not configured, IDS will start one poll thread.
Listing 6. Set
- Configure label for server's digital certificate in keystore.
If not configured, the server will use the default label in
keystore for SSL communication.
Listing 7. Configure label for server's digital certificate
- Configure the server name and server aliases according to the requirements. For example, let's configure
- Configure or create $INFORMIXDIR/etc/conssl.cfg file.
This file is needed by only SQLI clients like dbaccess, esql applications, etc., and contains the fully qualified filename of the client keystore, and fully qualified filename of the client stash file.
Listing 8. Configure CONSSL.cfg file
SSL_KEYSTORE_FILE /u/keystores/clikeydb.kdb SSL_KEYSTORE_STH /u/keystores/clikeydb.sth
If conssl.cfg does not exist or if any of the above parameters are not configured, the client keystore and stash file will default to $INFORMIXDIR/etc/client.kdb and $INFORMIXDIR/etc/client.sth.
- Set up sqlhosts.
Based on the current example, sqlhosts will have entries for lenexa_on, menlo_on, and portland_on. drsocssl will be used to support SSL communication with DRDA clients and onsocssl/olsocssl will be used to for supporting SSL communication with SQLI clients and between servers in ISTAR, HDR, ER, SDS/RSS.
Listing 9. Configure sqlhosts file
lenexa_on onsoctcp pinchy lenexa_serv menlo_on onsocssl pinchy menlo_serv portland_on drsocssl pinchy portland_serv
- Create server keystore.
The location and name of the server keystore and server stash file is predefined:
Listing 10. Name of Server keystore and stash file
Where servername is the value of the
Listing 11 shows the commands for creating keystore and a self-signed test certificate using a non-Java command line utility (
Listing 11. Commands to create keystore and self-signed certificate
gsk7capicmd -keydb -create -db lenexa_on.kdb -pw snoopy -type cms -stash gsk7capicmd -cert -create -db lenexa_on.kdb -pw snoopy -label ssltestlabel -dn "CN=lenexa.ibm.com,O=ibm,C=US" -size 1024 -default_cert yes
Export the certificate to an ASCII file (to be imported to client keystore). Listing 12 shows the commands for how to do this:
Listing 12. Commands to export the certificate
gsk7capicmd -cert -extract -db lenexa_on.kdb -format ascii -label ssltestlabel -pw snoopy -target ssltestlabel.cert
Change the permissions on the keystore and stash file to 600/informix:informix.
- Create client keystore.
Listing 13 shows the commands for creating keystore and importing the server certificate using a non-Java command line utility (
Listing 13. Commands to create client keystore and import server's certificate
gsk7capicmd -keydb -create -db clikeydb.kdb -pw snoopy -type cms -stash gsk7capicmd -cert -add -db clikeydb.kdb -pw snoopy -label ssltestlabel -file ssltestlabel.cert -format ascii
Change the permissions on the keystore and stash file to 664/informix:informix.
In an INFORMIXDIR that contains CSDK or I-Connect, you should have public read access; if the INFORMIXDIR only contains IDS, you might use just 600 or 640 permissions.
- Initialize the server:
- Move the server and client keystores to the specified location (as described in earlier steps).
- Initialize the server. All the communication between client and server on the SSL configured port will be encrypted using SSL protocol.
Troubleshooting SSL in IDS
Setting incorrect or different keystore label in ONCONFIG file
SSL_KEYSTORE_LABEL configuration parameter
specifies the label of the server digital certificate used in the keystore
database, a protected database that stores SSL keys and digital
certificates. The default value is the name of the label for the default
SSL certificate that is stored in the IDS keystore in the
SSL_KEYSTORE_LABEL onconfig variable is
not set to default (which is empty, say XXX) and the server's self-signed
certificate is created using some other values, then the following error
message occurs during IDS initialization:
Listing 14. Keystore label error message
15:27:48 Dynamically allocated new virtual shared memory segment (size 8820KB) 15:27:48 Memory sizes:resident:13068 KB, virtual:16820 KB, no SHMTOTAL limit 15:27:49 IBM Global Security Kit (GSKit) version 220.127.116.11. 15:27:49 Secure Sockets Layer error: GSK_ERROR_BAD_KEYFILE_LABEL.
In order to correct this error, ensure the value of the
SSL_KEYSTORE_LABEL onconfig variable matches
the server's self-signed certificate, or use the default value.
Using incorrect or non-existing server keystore
SSL_KEYSTORE_FILE 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. If the server keystore file,
$INFORMIXDIR/ssl/servername.kdb, does not exist or is corrupted, the
following error message will appear during IDS initialization:
Listing 15. Incorrect keystore error
15:34:13 Dynamically allocated new virtual shared memory segment (size 8820KB) 15:34:13 Memory sizes:resident:13068 KB, virtual:16820 KB, no SHMTOTAL limit 15:34:13 IBM Global Security Kit (GSKit) version 18.104.22.168. 15:34:13 Secure Sockets Layer error: GSK_KEYFILE_IO_ERROR
In order to correct this error, ensure that the server keystore exists.
Missing server keystore stash file
SSL_KEYSTORE_STH is the fully qualified file
name of the stash file containing the encrypted keystore password. If this
file is missing, the following error will appear during IDS
Listing 16. Missing stash file
15:39:14 Dynamically allocated new virtual shared memory segment (size 8820KB) 15:39:14 Memory sizes:resident:13068 KB, virtual:16820 KB, no SHMTOTAL limit 15:39:14 IBM Global Security Kit (GSKit) version 22.214.171.124. 15:39:14 Secure Sockets Layer error: GSK_ERROR_BAD_KEYFILE_PASSWORD.
Missing values for keystore and stash file location in conssl.cfg file
The conssl.cfg file is only used by SQLI clients, and contains the location
of client keystore and client stash file. If conssl.cfg does not exist or
if any of previously mentioned parameters are not configured, the client
keystore and stash file will default to $INFORMIXDIR/etc/client.kdb and
$INFORMIXDIR/etc/client.sth. If the values for
SSL_KEYSTORE_STH, or both are set incorrectly,
then the following error will appear when the client connects to IDS:
Listing 17. Missing values in conssl.cfg file
[toru:/work/manojm/sqldist/11.50/etc] dbaccess - - > connect to "@demo_ssl_on" user "bob"; ENTER PASSWORD: 28014: Secure Sockets Layer error: GSK_KEYRING_OPEN_ERROR-Keyring file did not open. Bad file number Error in line 1 Near character position 1
Ensure that valid values are used in the clients conssl.cfg file (if you need to use it).
Security of data in transit over the Internet becomes increasingly necessary. Nowadays, every user of a public network sends various types of data, from e-mail to credit card details daily, and would therefore like them to be protected when in transit over a public network. This article provides an overview of how you can use the SSL feature of IDS to secure the data in transit.
- Secure Sockets Layer (SSL): Secure Sockets Layer is a communication protocol developed by Netscape to transmit data securely over the network.
- Digital certificates: Digital certificates are electronic ID cards issued by trusted parties know as Certificate Authority (CA) that establish credentials.
- Certificate Authoriaty (CA): Certificate Authority (CA) is a trusted entity that issues digital certificates for use by other parties.
- Keystore: A keystore is a protected database that holds keys and digital certificates.
- Informix library: Get more details about SSL and IDS from the Informix library.
- IBM Informix Dynamic Server v11.50 Information Center: Learn more about IDS 11.50.
- In the developerWorks Informix page: Read articles and tutorials and connect to other resources to expand your Informix skills.
- developerWorks Information Management zone: Learn more about Information Management. Find technical documentation, how-to articles, education, downloads, product information, and more.
- Stay current with developerWorks technical events and webcasts.
Get products and technologies
- Informix Dynamic Server Developer's Edition: Download Informix Dynamic Server Developer's Edition.
- Build your next development project with IBM trial software, available for download directly from developerWorks.
- Participate in the discussion forum.
- Participate in developerWorks blogs and get involved in the My developerWorks community; with your personal profile and custom home page, you can tailor developerWorks to your interests and interact with other developerWorks users.
Dig deeper into Information management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.