Creating an SSL Keystore Using the Java Keytool
- Chaining and Establishing Identities
- Generating a Private Key and a Keystore
- Building the Keystore
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One of the easiest ways to secure an Internet application is to use the Secure Socket Layer (SSL) protocol. SSL allows the data from a client, such as a Web browser, to be encrypted prior to transmission so that someone trying to sniff the data is unable to decipher it.
SSL is used anywhere data needs to be secure. Typically, you see SSL used by banks and financial institutions, as well as on your favorite commercial e-commerce sites, like amazon.com or bestbuy.com. You may also see it at work; your employer may have a Web site for your personal information which is usually protected with SSL.
Many application servers and Web servers support the use of keystores for SSL configuration; WebLogic Server and JBoss both support the use of keystores for SSL. If you want to deploy SSL in your Java applications, building a keystore is one of the first steps. In this article, I show you one method to create a keystore, using the Java keytool utility with BEA's WebLogic 8.1.
The Necessities: Private Keys, Public Certificates, Certificate Authorities, and Keystores
Let's start with a very brief overview of the technology.
SSL works by allowing the client and server to send each other encrypted data that only they can decrypt. That's accomplished when the connection between the client and server is established. In a sequence of events generally known as the handshake, the server presents its public certificate for the client to accept or deny. If the certificate is accepted, the client and server agree on a hash for the duration of their conversation, which is used to encrypt the data.
The world of SSL has, essentially, three types of certificates: private keys, public keys (also called public certificates or site certificates), and root certificates. The private key contains the identity information of the server, along with a key value. It is critical to keep this information private, because it's used to negotiate the hash during the handshake -- rather like leaving your house key in the door lock. It is possible for someone to use your key to decrypt traffic – not all that likely, but a good reason to keep your private keys safe.
The public certificate is the portion that is presented to a client. The public certificate, tightly associated to the private key, is created from the private key using a Certificate Signing Request (CSR). After you create a private key, you create a CSR, which is sent to your Certificate Authority (CA). The CA returns a signed certificate, which has information about the server identity and about the CA.
Every CA provides a root certificate. A root certificate is one where the Issuer and the Subject are the exact same string. It's actually more involved than that, but that's as much as you need for the purposes of this article.
A Certificate Authority can take several forms. You may be familiar with several of these, such as VeriSign, Thawte, Commodo, GetTrust, and dozens of other companies who will sign certificates for you. Additionally, many companies and institutions act as their own CA, either by building a complete implementation from scratch, or by using an open source option, such as OpenSSL.
The final element that must be mentioned is the keystore, a special file type that can hold your keys and certificates and encrypt it all with a password. In simple terms, the keystore is just like a hashtable; it has an alias that identifies a certificate and then the certificate itself. You can access a specific certificate by specifying its alias.
Chaining and Establishing Identities
When a server and client establish an SSL connection, a certificate is presented to the client; the client must determine whether to trust this certificate, a process called the certificate chain. The client examines the issuer of a certificate, searches its list of trusted root certificates, and compares the issuer on the presented certificate to the subjects of the trusted certificates. Okay, it is more involved than that, but this is as much as you need to create a Java SSL connection.
If a match is found, the connection proceeds. If not, the Web browsers may pop up a dialog box, warning you that it cannot trust the certificate and offering the option to trust the certificate. However, if your code is making a connection, the certificate is rejected. In most cases, it raises an exception; you can choose to handle and continue, or log the exception and exit.
Okay, enough background. Let's put this to use by building a keystore.