Introduction

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.

Back to top

Digital certificates

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:

1. Generate the certificate request using the gsk7capicmd command, 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

   
   

   Where:

   • 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.

2. Verify that the certificate request was successfully created:
   1. Make sure that the key database recorded the request. The command, as shown in Listing 2, should list the label created earlier:
      
      Listing 2. List certificate requests
      

      gsk7capicmd -certreq -list -db demo.kdb -pw snoopy

      
      
   2. 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

      
      
3. 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.

Back to top

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.

Back to top

Steps to configure IDS to use SSL

Let's take a look at how to configure IDS to use SSL using "self-signed certificates":

1. Set up ONCONFIG:
   1. Configure the server name and server aliases according to the requirements. For example, let's configure lenexa_on to use regular TCP, menlo_on to use SSL, and portland_on to SSL for DRDA clients:
      
      Listing 4. Set DBSERVERNAME and DBSERVERALIASES
      

      DBSERVERNAME lenexa_on DBSERVERALIASES menlo_on,portland_on

      
      
   2. SSL encryption and decryption operations are performed on Encrypt VP. Depending on the load on the system, configure Encrypt VPs using the VPCLASS onconfig parameter (as shown in Listing 5). If VPCLASS is not configured, IDS will start one Encrypt VP by default.
      
      Listing 5. Set VPCLASS
      

      VPCLASS encrypt,num=3

      
      
   3. Depending on the load of the system, configure poll threads for SSL connection using the NETTYPE onconfig paramter (as shown in Listing 6). If poll threads are not configured, IDS will start one poll thread.
      
      Listing 6. Set NETTYPE
      

      NETTYPE socssl,3,50,NET

      
      
   4. 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
      

      SSL_KEYSTORE_LABEL ssltestlabel

      
      
2. 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.

3. 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

   
   
4. 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
   

   $INFORMIXDIR/ssl/servername.kdb $INFORMIXDIR/ssl/servername.sth

   
   

   Where servername is the value of the DBSERVERNAME onconfig parameter.

   Listing 11 shows the commands for creating keystore and a self-signed test certificate using a non-Java command line utility (gsk7capicmd/gsk7capicmd_64):

   
   
   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.

5. Create client keystore.

   Listing 13 shows the commands for creating keystore and importing the server certificate using a non-Java command line utility (gsk7capicmd/gsk7capicmd_64):
   
   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.

6. Initialize the server:
   1. Move the server and client keystores to the specified location (as described in earlier steps).
   2. Initialize the server. All the communication between client and server on the SSL configured port will be encrypted using SSL protocol.

Back to top

Troubleshooting SSL in IDS

Setting incorrect or different keystore label in ONCONFIG file

The 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 INFORMIXDIR/ssl/servername.kdb directory.

If 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:

	
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 7.0.4.27.
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:

	
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 7.0.4.27.
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 initialization:

	
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 7.0.4.27.
	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_FILE, SSL_KEYSTORE_STH, or both are set incorrectly, then the following error will appear when the client connects to IDS:

	
[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).

Back to top

Conclusion

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.

Back to top

Appendix: Terminology

• 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.

Resources

Learn

• 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.
  
  

Discuss

• 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.
  
  

About the authors

Manoj Mohan is a software engineer and has worked on IBM Informix Dynamic Server for the past 10 years in the networking and security area of IDS. His experiences include designing and implementing PAM, IPV6, SSO, and LBAC support in IDS.

Lynette Adayilamuriyil is a software engineer and has worked on IBM Informix Dynamic Server for the past 10 years in the SQL, kernel, and security areas of IDS. Her experiences include designing and implementing LBAC and SSL support in IDS.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Digital certificates
• How SSL works
• Steps to configure IDS to use SSL
• Troubleshooting SSL in IDS
• Conclusion
• Appendix: Terminology
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Informix Ultimate Edition
• Buy: Informix Ultimate Edition

Dig deeper into Information Management on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers