Protect your data with Secure Sockets Layer support in Informix Dynamic Server, Part 1: Setting up SSL support in IDS

Learn how to use the Secure Sockets Layer (SSL) feature of IBM® Informix® Dynamic Server (IDS) 11.50 to encrypt data in transit from client to server.

Manoj Mohan (manojm@us.ibm.com), IDS Software Development Engineer, IBM

Manoj MohanManoj 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 D. Adayilamuriyil (lynetta@us.ibm.com), IDS Security Software Development Engineer, IBM

Lynette AdayilamuriyilLynette 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.



10 March 2010

Also available in Portuguese

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.


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.


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
Illustration showing SSL handshake between client and server, where the client issues secure session request, server sends x.509 certificate containing server's public key, client authenticates certificate against known list of CAs (client also has option to accept certificate if CA is unknown), client generates random symmetric key and encrypts it using server's public key; client and server now both know the symmetric key and encrypt end-user data using symmetric key for duration of session.

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.

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:

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

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

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

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


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.


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

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=456879
ArticleTitle=Protect your data with Secure Sockets Layer support in Informix Dynamic Server, Part 1: Setting up SSL support in IDS
publish-date=03102010