Smart cards and TLS certificates

Transport layer security (TLS) certificates provide secure encrypted communication between the Rational® DOORS® server and the Rational DOORS client. When users log on to Rational DOORS with a smart card, TLS certificates are used.

TLS certificates and keystores

The client sends a certificate to the server to validate, and the server sends a certificate to the client to validate. The validation is carried out by keystores. A client keystore validates the server certificate, and a server keystore validates the client certificate.

Certificates can be organized in a tree structure, with a root certificate at the top of the tree. All of the certificates in the tree inherit the trustworthiness of the root certificate. Keystores can validate each certificate individually. If the keystore validates the root certificate, each certificate is also validated.

By default, Rational DOORS is installed with TLS certificates that are provided by IBM® GSKit, and two keystores that are ready to use.

The keystores are in the certdb folder. The client keystore is client_authentication.kdb, and the server keystore is server_authentication.kdb.

The client_authentication.kdb keystore contains a certificate that the client can send to the server called IBM_CL1, and the server_authentication.kdb keystore contains a certificate that is called IBM_SV1 that the server can send to the client. The IBM_SV1 certificate contains the name of the computer that the server is running on. By default, the name is IBMEDSERV.

The client keystore also contains the root certificate of the tree that contains the server certificate, which the client keystore uses to validate the server certificate. For example, the client_authentication.kdb keystore contains the root certificate of the tree that contains the IBM_SV1 certificate, and uses the root certificate to validate IBM_SV1. The server keystore contains the root certificate of the tree that contains the client certificate, and uses it to validate the client certificate.

If you start the Rational DOORS server in secure mode, all of the Rational DOORS clients make secure connections with the server. If you do not specify command-line switches, these default settings are used:
  • server_authentication.kdb is the name of the server keystore
  • IBM_SV1 is the name of the certificate
  • IBMEDSERV is name of the server

You can change the default settings and set up your system to your specifications. To specify your own settings, run command-line switches to specify a different keystore, certificate name, or server name. For example, you can change IBM_SV1 to a different certificate name or change IBMEDSERV to a different server name.

Smart card certificates and distinguished names

When you use smart cards, the client certificate is not on the Rational DOORS client. Instead, the client certificate is on the smart card, along with the distinguished name (DN), which is associated with the user. The certificate on the smart card is identified by a certificate label. The user is identified by a DN. The DN is made up of attribute=value pairs that are separated by commas:
CN=Ben Gray,OU=US,OU=users,DC=com,DC=ibm,DC=sales

Keystore certificates

When you use keystore certificates, the certificate is in the keystore, along with the distinguished name (DN), which is associated with the user. The keystore certificate is identified by a certificate label and the user is identified by a DN. The DN is made up of attribute=value pairs that are separated by commas:
CN=Ben Gray,OU=US,OU=users,DC=com,DC=ibm,DC=sales

Distinguished names and the administrator user account

The administrator user account bypasses all access rights checks, and is used only when absolutely necessary; for example, if no other users can log in, or if other users cannot access part of the database. When you are using smart cards and certificates, you must associate a distinguished name (DN) with the administrator user so that the administrator user can access the database.

Configuration process

To set up your system to use smart cards and Transport Layer Security (TLS) certificates:
  1. Set up users.

    Before you enable card authentication for a server, you must set up smart card users. You set up a user by associating the user with a distinguished name.

  2. Associate a distinguished name with the administrator user.

    You must associate a distinguished name (DN) with the administrator user to allow the administrator user to access the database.

  3. Enable smart card authentication in the database server.
  4. Enable smart card authentication in the client.

What to do next

Set up users. If you are using public key infrastructure (PKI) authentication, follow the instructions in Setting up PKI authentication users. If you are using Microsoft Certificate Store (MCS) authentication, follow the instructions in Setting up MCS authentication users.

Feedback