The Secure Sockets Layer and Transport Layer Security

Verification of X.509 Public Key Certificates for Secure Communications

Jinwoo Hwang
Published on June 06, 2012

Ever since Netscape Communications invented the Secure Sockets Layer Protocol (SSL) in 1994, after the Internet becomes under scrutiny over security, the arms race between code breakers and code makers has been accelerated in the field of the internet cryptography.

We will have a brief look at the history of cryptography and basic information about secure communications including handshake protocols of the Transport Layer Security and the Secure Sockets Layer which has become an industry standard for securing communication sessions over an unsecured network, such as the Internet. We will take advantage of the IBM Connection and Configuration Verification Tool for SSL/TLS by starting actual SSL/TLS server and client, reviewing X.509 public key certificates from live SSL/TLS servers, and extracting X.509 public key certificates from trusted production SSL/TLS servers.

History of Secure Communications

The science or study of the enciphering and deciphering messages, or the cryptography dates back to thousands of years ago in Greece. You will get a clue why Greece is related with this area of science if you find the etymology of the cryptography. The word, crypto was originated from the Greek word, kryptos, which means "hidden, concealed, secrete". The other word, graphy, also came from the Greek word, graphia, meaning "write". In other words, cryptography means secrete writing in Greek.

Why do we use Greek words to describe the science of secure writing? Would writing messages in Greek make them more secure? Not really. (This may remind you of the famous line, “It was Greek to me” spoken by Casca who conversed with Cassius in William Shakespeare’s the Tragedy of Julius Caesar).

We can give the Greeks a credit since the ancient Greeks and Spartans used a device called scytale around 600 BC according to the record written by the Greek poet Archilochus. The scytale is the first cryptographic device to date though some would argue that it is just a myth. A scytale looks like a rolling pin in your kitchen with a strip of parchment wrapped around it. Secrete messages are written on the parchment. The recipient should use a scytale with the same diameter to decrypt the messages on the parchment. A scytale uses a route cipher method, one implementation of the transposition cipher. Surprisingly scytales are still used today (not for the intended purpose though) as the emblem of the American Cryptography Association.

The first documented use of civil cryptography goes back to as early as 1900 BC in the Egyptian town of Menet Khufu. An inscription found in the main chamber of the tomb of noble man Khnumhotep II employed a substitution cipher using a simple code of hieroglyphic substitution.

Fast forward 4,000 years to the edge of the 20^th century in which the mankind made greatest engineering achievements such as computers, the Internet, automobile, airplane, electronics and many others.

In November 1990, the Hypertext Transfer Protocol (HTTP) was first used at the European Organization for Nuclear Research (CERN:Conseil Européen pour la Recherche Nucléaire) fueling explosive use of the Internet over the World Wide Web. The HTTP is an application layer protocol for two communicating applications to exchange request and response over a connection. It is the foundation of the World Wide Web that we use today.  In order to transfer funds such as electronic commerce, HTTP was not secure enough for the use and there has been growing need for secure HTTP connections.

In late 1993 Allan Schiffman and Eric Rescorla developed the Secure HTTP (S-HTTP) which Schiffman claims is the first cryptographic protocol for the Internet. He also claims that the Secure Mosaic is the first secure web browser.

In 1994, the Secure Sockets Layer Protocol (SSL) was invented by Netscape Communications to secure communications between clients and server applications over an unprotected network, such as the Internet  and it has been de facto standard for cryptographic protocol since then. SSL provides privacy and integrity of the data that client and server applications exchange and authentication of one or both endpoints of the communication session.

The Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol. One of the advantages of SSL over Secure HTTP is that the SSL specification was designed as application protocol independent protocol which means SSL is not stuck with securing web browser and server communications.

SSL now secures your email (Simple Mail Transfer Protocol, SMTP), your phone call (Voice over IP, VoIP), File Transfer Protocol (FTP) and many other protocols, let alone your web browsing (HTTP). You can even secure the 1970s IBM 3270 or 5250 terminal protocols with SSL. Of course you will probably need Telnet 3270 (TN 3270) or 5250 since you won’t easily find SNA network these days.

Since Netscape Communication owns the SSL patent (United States Patent No. 5,657,390 : Secure socket layer application program apparatus and method), do you need to pay Netscape Communications if you want to implement SSL technology?  Fortunately, Netscape Communications granted a royalty free license to any party who wishes to build implementations covered by the patent claims or the IETF(Internet Engineering Task Force) TLS specification.

In January 1999, the IETF adopted an enhanced version of SSL 3.0 called Transport Layer Security (TLS) 1.0 (SSL 3.1) which was defined in RFC(Request for Comments) 2246. In the wake of the 21^st century, August 2008 to be exact, TLS 1.2 (SSL 3.3) became the latest TLS specification as of this writing. TLS 1.2 was defined in RFC 5246.

Cryptographic Jargons

Let us do some ground work before we move into cryptographic world. Cryptographic languages are very similar to the real world's counterparts in many ways. Let's start with keys.

A key in cryptography is a sequence of information that controls output of cryptographic operations such as encipherment and decipherment. Just like if you forget your user ID and password of your email account, you cannot read your email. Your user ID and password is your key to your email vault.

What is a certificate? Well, it is also called a public key certificate, a digital certificate or identity certificate to get more descriptive if not more overwhelming. Public key certificates are digitally signed data structures that bind public keys to subjects by a trusted certificate authority or certification authority. They are like the photo IDs issued by your local or state government such as a driver's license or a passport. Your local or state government will be a certificate authority.

A keystore is a repository of cryptographic keys and certificates. A truststore is a storage facility for trusted entities and their associated X.509 certificate chains.

The Protocol, SSL and TLS

Protocol Network Layers

The Transport Layer Security is layered on top of the Transport Layer such as TCP. The protocol is composed of two layers: the TLS Record Layer and the TLS Handshake Layer.

The TLS Record Layer is used for encapsulation of various higher level protocols such as the handshake protocol, the alert protocol, the change cipher spec protocol, and the application data protocol.

The TLS Handshake Layer consists of the handshake protocol, the alert protocol and the change cipher spec protocol. The orange box with the HTTP1 layer and TLS Record layer combined constitutes Hypertext Transfer Protocol Secure (HTTPS) as shown in Figure 1. If HTTP1 layer is replaced with FTP, the orange box will be the File Transfer Protocol Secure (FTPS). Of course, HTTP2 outside of the orange box is the plain HTTP without any security support.

Figure 1. SSL/TLS Protocol Layers

View image at full size

Handshake and Protocol Flow

Here's a flow of the protocol between a client and a server.

Figure 2. A typical flow of the TLS protocol

View image at full size

The client sends a client hello message to the server. A client hello message contains the following information:

• ProtocolVersion : The version of the TLS protocol by which the client wants to communicate during this session
• Random : A random structure which contains the current time and date and 28 bytes of a secure random number generated by the client
• SessionID: The ID of a session the client wishes to use for this connection
• CipherSuite : The CipherSuite list which contains the combinations of cryptographic algorithms supported by the client
• CompressionMethod : A list of compression algorithms supported by the client

The server responds with a server hello message in response to a client hello message if it was able to find an acceptable algorithm. A server hello message contains the following information:

• ProtocolVersion : The version of the TLS protocol by which the server agrees to communicate with the client during this session
• Random : A random structure which contains the current time and date and 28 bytes of a secure random number generated by the server
• SessionID: The ID of a session the server wishes to use for this connection
• CipherSuite : The single cipher suite selected by the server from the list of the cipher suite contained in the client hello message
• CompressionMethod : The single compression algorithm selected by the server from the list of the compression method contained in the client hello message.

Immediately after the server sends the server hello message to the client, it sends a server certificate message and a server key exchange message to the client. The certificate request message can optionally be sent by the server to request a certificate from the client if the server chooses to authenticate the client. Then the server sends a server hello done message and will wait for a client to respond.

The client sends a client certificate message to the server if the server requests a certificate in response to the server hello done message. Immediately after the client certificate message is sent, a client key exchange message and a certificate verify message are sent by the client. The client sends a certificate verify message for the server to verify a client certificate.

If the server does not request a certificate, the client key exchange message will be the first message sent by the client. A change cipher spec message and a finished message are sent by the client. In response, the server will send a change cipher specification message and a finished message. At this point, the client and server can exchange application layer data. That should be fairly enough for now to understand overall picture of the protocol. It is time for actual hands on experience to really understand how the protocol works inside and out. In order to look into further we need real scenarios. Let’s take a look at the scenarios.

Test Cases

We will experiment with a scenario where you do not have a proper certificate to access an SSL server. The other scenario is where you acquire a legitimate certificate from an SSL server and communicate with the server over SSL with the certificate. We will try the scenarios with and without a tool that is not provided by your Java runtime environment.

Let's take a look at specific steps we need to take in order to execute the first scenario, if we want to start from scratch:

1. Create a key store for a server
2. Create a key pair and X.509 self-signed public key certificate in the key store
3. Review the key in the key store
4. Create an empty trust store for a client
5. Review the trust store. Make sure it is empty
6. Start an SSL server with the key store
7. Start an SSL client with the trust store
8. Connect the client to the server

The following is the steps of the other scenario:

1. Export the certificate from the server’s key store
2. Import the certificate into the client’s trust store
3. Review the certificate in the trust store
4. Start an SSL server with the key store
5. Start an SSL client with the trust store
6. Connect the client to the server

Now we have test cases. It does not hurt to equip yourself with tools before you swim into the ocean such as IBM Connection and Configuration Verification Tool for SSL/TLS or any other tools of your choice as long as they have same features for the scenario.

Tool, IBM Connection and Configuration Verification Tool for SSL/TLS

IBM Connection and Configuration Verification Tool for SSL/TLS can verify network connections and configurations over the Secure Sockets Layer (SSL) protocol and the Transport Layer Security (TLS) protocol as a SSL/TLS client or as a SSL/TLS server. It allows to you take a look at private keys and certificates in key stores and trust stores. It can also import certificates from your trusted live SSL/TLS servers if you choose to do so. You can import certificates from key stores and export to key stores.

Prerequisite

• The Java™ runtime environment version 6 or higher
• Key store and/or trust store for trusted communications

Features

• Open key stores
• Open trust stores
• Create new key stores
• Create new trust stores
• List private keys
• List X.509 certificates
• Read information about private keys in key stores
• Read information about X.509 certificates in key stores and trust stores
• Export X.509 certificates
• Import X.509 certificates
• Open SSL/TLS server socket
• Open SSL/TLS client socket
• Support client authentication
• Verify X.509 certificates
• Receive X.509 certificates from SSL/TLS server
• Send X.509 certificates to SSL/TLS client
• Perform SSL/TLS handshake
• Set default connection parameters
• Automatically import X.509 certificates from SSL/TLS server

How to start Connection and Configuration Verification Tool for SSL/TLS

You need to use the Java™ runtime environment version 6 or higher to run this tool. Depending on your system's Java runtime environment, you could execute a jar file simply by just clicking the file from your operating system’s graphical user interface or typing in the path name of the jar file from a command line interface just like an ordinary executable file.

If that is not supported, you need to use your command line interface.

Usage : <Java path>java –jar cvt<version>.jar

For example, /usr/java6/bin/java -jar cvt101.jar will start version 1.0.1 with Java runtime located in the directory, /usr/java6/bin/.

How to use Connection and Configuration Verification Tool for SSL/TLS

When you first start the tool, you will have a chance to read and accept license agreement. If you decline the license agreement, the program will terminate and you should promptly return the unused media and documentation to the party from whom it was obtained for a refund of the amount paid. If the program was downloaded, destroy all copies of the program.

Figure 3. License Agreement

View image at full size

After you accept the license agreement, you should be able to see the following initial screen of the tool.

Figure 4. Initial screen

View image at full size

You can navigate the tool with menus, icons in tool bars and key short cuts for example Control X to exit from the tool. The console frame provides messages from the tool.
You now have a tool in your tool belt. Let's start with the first test case.

Test Case #1

We will experiment with a scenario where you do not have a proper certificate to access an SSL server. Let’s follow each step:

1. Create a key store for a server
2. Create a key pair and X.509 self-signed public key certificate in the key store

First, you need to get a SSL certificate. There are a variety of options for getting a certificate from SSL certificate providers. You will need to evaluate your business needs before choosing an SSL provider. If you don’t have any SSL certificates, you can create one. Of course, it is not useful in a real world just like you cannot buy a 6-pack beer from a local liquor store by presenting a home-made ID to a cashier.

Here's how to create a self-signed certificates:
The Java Runtime Environment provides you with a command interface called keytool which manages cryptographic keys, X.509 certificates and keystores. You should be able to find it under bin directory of Java home directory of most Java virtual machine. You need to specify commands and options such as –genkeypair, -alias, -keyalg, -keystore and –dname.

Here’s an example:

$ keytool -genkeypair -alias sscert -keyalg RSA -keystore keystore -dname "CN=localhost, OU=Software Group, O=IBM, L=Research Triangle Park, S=North Carolina, C=US"

With these commands and options, you can create a key store for a server and create a key pair and X.509 self-signed public key certificate in the key store for the server at the same time.

Let's take a closer look at the command and the options to see what the each part means.

-genkeypair
This command will generate a private key and a certificate chain which has an X.509 v4 self-signed certificate.

-alias
This option specifies the name for an entry. We used sscert for the alias.

-keyalg
This option specifies the algorithm for the key pair. We use RSA (Rivest, Shamir and Adleman) algorithm to generate the key pair.

-keystore
This option specifies the name of the keystore.

-dname
This option specifies X.500 distinguished name. X.500 distinguished names are used to provide unique identification of entries. Detailed information about X.500 is defined in RFC (Request for Comments) 2253 of the Internet Engineering Task Force (IETF). We have provided only common name, organization name, organization unit name, state/province name, locality name and country name in this example. Here is a full description of the keywords used in X.500 distinguished names:

Table 1. Description of the keywords in X.500 distinguished names

String Representation of Distinguished Names was defined in RFC 1779 by IETF in 1995. If –dname is not specified, you will have to provide the keytool with the information interactively, for example:

What is your first and last name?
  [Unknown]:  localhost
What is the name of your organizational unit?
  [Unknown]:  Software Group
What is the name of your organization?
  [Unknown]:  IBM
What is the name of your City or Locality?
  [Unknown]:  Research Triangle Park
What is the name of your State or Province?
  [Unknown]:  NC
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=localhost, OU=Software Group, O=IBM, L=Research Triangle Park, ST=NC, C=US
correct?
  [no]:  yes

If all the command and the options are correct, you will have to type in passwords for the keystore and the key.

Enter keystore password:******
Re-enter new password:******
Enter key password for <sscert>:
        (RETURN if same as keystore password):

So we completed step 1 and step 2. Now we have a certificate in a keystore for an SSL server. The next step is:

3. Review the key in the key store

If you are familiar with various features of the keytool, you can use the keytool again to review the key in the key store

$keytool -list -v -keystore keystore
Enter keystore password: ******
 
Keystore type: JKS
Keystore provider: IBM
 
Your keystore contains 1 entry
 
Alias name: sscert
Creation date: May 25, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost, OU=Software Group, O=IBM, L=Research Triangle Park, ST=NC, C=US
Issuer: CN=localhost, OU=Software Group, O=IBM, L= Research Triangle Park, ST=NC, C=US
Serial number: 4ddcfd20
Valid from: May 25 08:59:12 EDT 2012 until: Jul 20 10:20:23 EDT 2032
Certificate fingerprints:
         MD5:  ...CC:72:A9:AF:83:14:C7:43:D4...
         SHA1: ...53:8A:FF:28:1A:C8:1A:23:91:F6:2F:D5:39...
         SHA256: ...07:51:4A:CD:8B:A1:C5:8A:EC:45:30:8A...
         Signature algorithm name: SHA256withRSA
         Version: 3
 
Extensions:
 
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 58 78 C4 52 8D CB 4D 32   ...
0010: DD 44 DE …                            
]
]

If you want to try an easier way, you we can use IBM Connection and Configuration Verification Tool for SSL/TLS. Let’s start the tool.

Key Information

Under the File menu, there are Open Trust Store, Open Key Store, Create Key/Trust Store and Exit menu items. If you select File->Open Key Store menu item, or do a key stroke, Ctrl-K to open the key store. With this feature, you can browse private keys and associated certificates.

Figure 5. File menu

View image at full size

Select the keystore file that you created. We used the file name, keystore. Then select Open button.

Figure 6. Open a keystore

View image at full size

You need to select key store type. You can choose JKS for the key store type.

Figure 7. Open a keystore type

View image at full size

You need to type in the password for the keystore. Then select Open button.

Figure 8. Password for a keystore

View image at full size

In Keys tab of the key store window, a private key is shown with the name sscert as well as the certificate localhost. When a certificate is selected, you can find subject’s common name, organization name, organization unit name, state/province name, locality name and country name as well as certificate’s version, serial number, SHA-1(a secure hash algorithm) fingerprint, MD5 (a message-digest algorithm) fingerprint, validity dates, issuer’s X.500 distinguished name, public key algorithm, format, key size, signature format, signature size, public key and signature.

Figure 9. Keys in a keystore

View image at full size

Key Store Information

If you select Key Store Information tab, you can see provider name, provider version, key store type, class name, signature algorithms, cipher algorithms and message digest algorithms.

Figure 10. Keystore Information

View image at full size

Let's move on to the next step.

4. Create an empty trust store for a client

Create Trust Store

Select File->Create Key/Trust Store. Then select a trust store type, JKS.

Figure 11. Truststore Type

View image at full size

Type in the password for the trust store twice, specify the file name for the trust store and select Create button.

Figure 12. Truststore file name

View image at full size

If the trust store is successfully created, you should be able to find the following message:

Figure 13. Truststore created

View image at full size

Before we move on, you need to make a copy of the empty trust store in case we need the empty trust store unless you do not mind creating empty trust stores again.

5. Review the trust store. Make sure it is empty

Open Trust Store

Let’s examine the newly created trust store by selecting File->Open Trust Store menu item. You can browse X.509 certificates, issuers and expiration dates in a trust store.

You will find “Open a Trust Store” dialog, select the trust store file and click Open button.

Figure 14. Opening Truststore

View image at full size

For the Trust Store Type, select JKS store type.

Figure 15. Truststore Type

View image at full size

Then enter the trust store password and click Open button.

Figure 16. Truststore Password

View image at full size

The tool will indicate that there are no X.509 certificates in the trust store.

Figure 17. No Certificates

X.509 Certificate Information

That’s exactly what we expected. We do not see any X.509 certificates in the X.509 Certificates list.

Figure 18. X.509 Certificates

View image at full size

When a certificate exists and is selected, subject's common name, organization name, organization unit name, state/province name, locality name and country name as well as certificate's version, serial number, SHA-1(a secure hash algorithm) fingerprint, MD5 (a message-digest algorithm) fingerprint, validity dates, issuer's X.500 distinguished name, public key algorithm, format, key size, signature format, signature size, public key and signature.

Trust Store Information

You can check out provider name, provider version, class name, store type, signature algorithm, cipher algorithm and message digest algorithm by selecting Trust Store information tab.

Figure 19. Truststore Information

View image at full size

Now we have a key store and an empty trust store. It is time to start server and client to test the key store and the trust store.

6. Start an SSL server with the key store

Start an SSL Server

Under Network menu, there are Start Client and Start Server menu items. You can start server by selecting “Start Server” menu item or using the short cut, Ctrl-S.

Figure 20. Network Menu

View image at full size

You need to fill in cryptographic protocol, for example SSLv3, cryptographic port number, key management algorithm, key store type, location of key store and password.

Figure 21. Start Server

View image at full size

If you want to authenticate client, you need to enable "Client Authentication Enabled" check box, and specify trust management algorithm, trust store type, location of trust store and password before starting server.

After "Start" button is clicked, the tool will list to the specified port with the given protocol. The tool is listening to the port 443 with SSL protocol version 3 in the picture. You can pause or resume the server by clicking "Pause" or "Resume" button.

Keep in mind that you will not see any information about remote address, port, cipher suite, connection time and session ID until any connection is established with a client.

Figure 22. Server Started

View image at full size

Start an SSL Client

7. Start an SSL client with the trust store

Now the server is up and running. Start SSL or TLS client by selecting Network > Start Client menu item. You need to fill in cryptographic protocol, for example SSLv3, host name, port number, trust management algorithm, trust store type, location of trust store and password.

If you want to authenticate client, you need to enable "Client Authentication Enabled" check box, key management algorithm, key store type, location of key store and password before starting client. But do not use client authentication for this test case.

Figure 23. Start Client

View image at full size

Connecting the Client to the Server

8. Connect the client to the server

As soon as you click "Start" button, you will see a message, "SSLHandshakeException : Received fatal alert: certificate_unknown" because you do not have any certificate in your trust store. You can click "OK" button to acknowledge it.

Figure 24. SSL Handshake Exception

View image at full size

The tool will ask you whether you want to trust the server. Click on the no button for now.

Figure 25. To trust or not to trust

View image at full size

You can find information about the secure connection such as protocol, local address, local port, remote address, remote port, cipher suite, connection time, session id, client authentication, supported protocols, enabled protocols, supported cipher suites and enabled cipher suites from the "Connection" tab.

Figure 26. Connection Information

View image at full size

So far you tried to connect the server with empty trust store and the tool indicated that you do not have any certificate to trust the server.

Test Case #2

In this scenario, you will acquire a legitimate certificate from an SSL server and communicate with the server over SSL with the certificate. The first step is:

1. Export the certificate from the server's key store

Exporting a Certificate

Exporting a certificate with keytool

You could use export command of the keytool to export the certificate.

$keytool -export -alias sscert -keystore keystore -rfc –file sscert
Enter keystore password:
Certificate stored in file <sscert>
 
-----BEGIN CERTIFICATE-----
…
CBMCTkMxEDAOBgNVBAcTB1JhbGVpZ2gxDDAKBgNVBAoTA0lCTTEXMBUGA1UECxMOU29mdHdhcmUg
R3JvdXAxIDAeBgNVBAMTF1NlbGYgU2lnbmVkIENlcnRpZmljYXRlMB4XDTExMDQyMTE0MjAyM1oX
DTExMDcyMDE0MjAyM1owdTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5DMRAwDgYDVQQHEwdSYWxl
…
-----END CERTIFICATE-----

The -export command by default exports a certificate in its binary encoding. If the –rfc option is specified, it will export a certificate in the printable encoding format defined by the Internet RFC 1421 standard, also known as "Base 64 encoding".

Exporting a certificate with IBM Connection and Configuration Verification Tool for SSL/TLS

Select File > Open Key Store menu item or do a key stroke, Ctrl-K to open the key store.

Figure 27. Opening Keystore

View image at full size

Select the keystore. Then select Open button.

Figure 28. Selecting Keystore

View image at full size

Select key store type and type in the password for the keystore. Then select Open button.

Figure 29. Keystore Type and Password

View image at full size

Now you can see the key, sscert and its certificate.

Figure 30. Verifying Key and Certificate

View image at full size

Let's export the certificate to a file encoded with Base 64 or encoding format defined by Internet RFC 1421 standard by selecting the certificate in the certificate chain list and selecting Certificate Management->Export a certificate menu.

Figure 31. Exporting a certificate

View image at full size

Name the file that will hold the certificate and select OK button.

Figure 32. Export File Name

If the export of the certificate is successful, you can see the following message:

Figure 33. Certificate Export completed

View image at full size

Now we have exported the self-signed certificate using the encoding format defined by Internet RFC 1421 standard. If you take a look at the exported certificate, it will look like this:

-----BEGIN CERTIFICATE-----
…
CBMCTkMxEDAOBgNVBAcTB1JhbGVpZ2gxDDAKBgNVBAoTA0lCTTEXMBUGA1UECxMOU29mdHdhcmUg
R3JvdXAxIDAeBgNVBAMTF1NlbGYgU2lnbmVkIENlcnRpZmljYXRlMB4XDTExMDQyMTE0MjAyM1oX
DTExMDcyMDE0MjAyM1owdTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5DMRAwDgYDVQQHEwdSYWxl
…
-----END CERTIFICATE-----

Importing the Certificate

The next step is:

2. Import the certificate into the client's trust store

Before you import the certificate, make sure you have a copy of the empty trust store because you will need an empty trust store later to test out one of key features of the tool.

Importing the certificate with keytool

If you want to import with the keytool, you can use import command.

$keytool -import -alias cert -file sscert -keystore truststore
 
Enter keystore password:
Re-enter new password:
Owner: CN=localhost, OU=Software Group, O=IBM, L=Research Triangle Park, ST=NC, C=US
Issuer: CN= localhost, OU=Software Group, O=IBM, L= Research Triangle Park, ST=NC,C=US
Serial number: 1c69387c
Valid from: Thu Apr 21 10:20:23 EDT 2012 until: Wed Jul 20 10:20:23 EDT 2021
Certificate fingerprints:
         MD5:  CC:72:A9:AF:83:14:C7:43:D4:CB:C5:61:61:E9:55:C2
         SHA1: 53:8A:FF:28:1A:C8:1A:23:91:F6:2F:D5:39:12:90:EB:A9:47:14:2C
         SHA256: 07:51:4A:CD:8B:A1:C5:8A:EC:E9:5D:6E:66:38:6C:89:E0:46:6C
         Signature algorithm name: SHA256withRSA
         Version: 3
 
Extensions:
 
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 58 78 C4 52 8D CB 4D 32   4D AF 71 F5 F7 E1 3A 9F...
0010: DD 44 DE …
]
]
 
Trust this certificate? [no]:  yes
Certificate was added to keystore

Importing the certificate with IBM Connection and Configuration Verification Tool for SSL/TLS

Select File->Open Trust Store menu item and select Certificate Management->Import X.509 Certificate or Ctrl-I to import the certificate.

Figure 34. Importing a Certificate

View image at full size

If the import is successful, you can see the following message:

Figure 35. Imported Certificate

View image at full size

The next step is:

3. Review the certificate in the trust store

Figure 36. Reviewing Certificate

View image at full size

You can also use list command of the keytool if you want to do the same task.

$keytool -list -v -keystore truststore
Enter keystore password:
 
Keystore type: JKS
Keystore provider: IBM
 
Your keystore contains 1 entry
 
Alias name: cert
Creation date: Apr 21, 2012
Entry type: trustedCertEntry
 
Owner: CN=localhost, OU=Software Group, O=IBM, L=Research Triangle Park, ST=NC, C=US
Issuer: CN= localhost, OU=Software Group, O=IBM, L= Research Triangle Park, ST=NC, C=US
Serial number: 1c69387c
Valid from: Apr 21 10:20:23 EDT 2012 until: Jul 20 10:20:23 EDT 2021
Certificate fingerprints:
         MD5:  CC:72:A9:AF:83:14:C7:43:D4:CB:C5:61:61:E9:55:C2
         SHA1: 53:8A:FF:28:1A:C8:1A:23:91:F6:2F:D5:39:12:90:EB:A9:47:14:2C
         SHA256: B1:E9:5D:6E:66:38:6C:89:E0:46:6C
         Signature algorithm name: SHA256withRSA
         Version: 3
 
Extensions:
 
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 58 78 C4 52 8D CB 4D 32   4D AF 71 F5 F7 E1 3A 9F  Xx.R..M2M.q...:.
0010: DD 44 6D DE                                        .Dm.
]
]

The next step is:

4. Start an SSL server with the key store

Figure 37. Start Server

View image at full size

Fill in cryptographic protocol, for example SSLv3, cryptographic port number, key management algorithm, key store type, location of key store and password, then click on the start button.

Figure 38. SSL V3 Server Started

View image at full size

The SSL server is up and running with the key store. The next step is:

5. Start an SSL client with the trust store

Starting an SSL Client

Now you can start client with the trust store which has now the same certificate that the server’s keystore has. Start the client by selecting Network->Start Client menu item.

Figure 39. Start Client

View image at full size

You need to fill in cryptographic protocol, for example SSLv3, host name, port number, trust management algorithm, trust store type, location of trust store and password. On an IBM Java runtime environment, you can choose JKS, PKCS12 or JCEKS for key store type. You can choose TLS or SSL for cryptographic protocol. There are IBMPKIX, IBMX509,X509 and PKIX for trust store management algorithms to choose from.
Select the trust store that you imported the certificate into and click “Start” button.

Figure 40. Start SSL V3 Client

View image at full size

If you want to authenticate client in future test, you need to enable “Client Authentication Enabled” check box, key management algorithm, key store type, location of key store and password before starting client.

Figure 41. Start SSL client with client authentication enabled

View image at full size

But do not use client authentication at this time. As soon as the start button is clicked, the next step kicks in:

6. Connect the client to the server

Congratulations! You successfully established connection to the SSL server with the certificate extracted from the server's keystore.

Figure 42. Connection Established

View image at full size

It has been cumbersome to export the certificate from server's keystore and import it to client's trust store. Let’s get things simplified this time by taking advantage of the tool.

Simplifying Test Cast #2 with Auto Certificate Import by IBM Connection and Configuration Verification Tool for SSL/TLS

You need an empty trust store. I am sure you have one. If not, you can always go back to File > Create Key/Trust Store menu item and create one for you.

You need to start client with the empty trust store by selecting Network > Start client, fill in protocol and trust store information and click "Start" button.

Just like the test case #1, as soon as you click "Start" button, you will see a message, "SSLHandshakeException : Received fatal alert: certificate_unknown" because you do not have any certificate in your trust store.

Figure 43. Unknown Certificate

View image at full size

You can click "OK" button.
The tool will ask you whether you want to trust the server.

Figure 44. Not a trusted server

View image at full size

This time, click "Yes" button to see what happens. If you are nervous or rather cautious, you can check out the server's certificates by selecting Certificates tab before making any decisions on whether to trust or not to trust.

Figure 45. Reviewing the Certificate

View image at full size

If you choose to trust the server, the tool automatically retrieves the certificate from the server and imports it into your trust store. You will see the following message:

Figure 46. Certificate Imported

View image at full size

You could review the client's trust store to make sure certificates were actually imported and subsequent connections are successful without any problems after the automated test gets completed. Let's check out your trust store by selecting File > Open Trust Store. You can see the certificate in the trust store.

Figure 47. X.509 Certificate in truststore

View image at full size

That means you can connect the server without any problem from now on with the trust store.

Stop the client and try Network > Start Client menu item again with the trust store and you will find out that you can establish a secure connection to the server successfully from now on.

Figure 48. Successful Connection

View image at full size

You can find information about the secure connection such as protocol, local address, local port, remote address, remote port, cipher suite, connection time, session id, client authentication, supported protocols, enabled protocols, supported cipher suites and enabled cipher suites from the “Connection” tab.

Figure 49. Connection Information

View image at full size

Miscellaneous Features

Let's take a look at the rest of the features that the IBM Connection and Configuration Verification Tool for SSL/TLS offers.

View menu

Under View menu, there are Options, User Interface Profiles, Help Contents Browser, Show Console and Clear Console menu items.

Figure 50. View Menu

View image at full size

Set default options

If you select View > Options, you can change default settings for cryptographic port, cryptographic protocol, trust store type, key store type, trust management algorithm, key management algorithm and connection time out in seconds.

Figure 51. Options Menu

View image at full size

Set user interface profile

You can change user interface experience with View->User Interface Profiles menu item. There are Nimbus, System and Java user interface options.

Figure 52. User Interface Profile

View image at full size

Set default help contents browser

You can choose your system's web browser or the tool's internal web browser to read the tool's help contents documents by selecting View->Help Contents Browser menu item.

Figure 53. Default Browser

View image at full size

How to use Help menu

The Help menu has Help Contents, About and License Agreement menu items.

Figure 54. Help Menu

View image at full size

Help Contents

If you select Help->Help Contents, you can read this document from the tool.

Figure 55. Help Contents

View image at full size

About Menu

You can read basic information about the tool by selecting Help->About menu item.

Figure 56. About the tool

View image at full size

License agreement menu

You can review the license agreement by selecting Help->License Agreement menu item.

Figure 57. License Agreement Document

View image at full size

Conclusion

In this article, we've learned about the history of cryptography and basic information about secure communications including handshake protocols of the Transport Layer Security and the Secure Sockets Layer. We also covered basic features of the IBM Connection and Configuration Verification Tool for SSL/TLS including starting SSL/TLS server and client, reviewing X.509 public key certificates from SSL/TLS servers, and extracting X.509 public key certificates from trusted SSL/TLS servers. We also used real life scenarios to utilize the tool.

If you need a copy of the IBM Connection and Configuration Verification Tool for SSL/TLS or more information, visit the IBM developerWorks. See the Related topics section for a link.

Downloadable resources

• PDF of this content

Related topics

• The Secure Sockets Layer (SSL) Protocol Version 3.0
• The TLS Protocol Version 1.0
• The Transport Layer Security (TLS) Protocol
• The Transport Layer Security (TLS) Protocol Version 1.1