Creating a self-signed certificate to test Tomcat https is easy, and this article gives you the step-by-step instructions on the following parts:
1. Create a self-signed host certificate using openSSL
2. Create a PKCS12 keystore and convert it to java keystore
3. Configure Tomcat 6 to use https, and redirect http to https
4. Create a Java client to talk to the Tomcat over SSL with the self-signed certificates
Part 1. Create a self-signed host certificate using openSSL
There are different ways of creating a self-signed certificate, such as using Java keytool. But I prefer openSSL because the keys and certificates generated this way are more standardized and can be used for other purposes. The openSSL HOWTO page gives you a lot of details and other information.
1.1 Create a pair of PKI keys
PKI stands for Public Key Infrastructure, which is also known as Asymmetric key pair, where you have a private key and a public key. The private key is a secret you guard with your honor and life, and the public key is something you give out freely. Messages encrypted with one can be decrypted with the other. While generally speaking, given one key, it should be infeasible to derive the other. However, openSSL makes it so that given a private key, you can easily derive the public key (but not vice versa, otherwise the security is broken). For this reason, when you generate a key using openSSL, it only gives you a private key.
As a side note, the word asymmetric is really a poor choice. Once, a security expert was giving a presentation to a roomful of students on PKI, and one of his slides was supposed to have the title “Asymmetric key scheme”, but perhaps it was the fonts he used, or perhaps he made a last-minute typo, it looked like there was a space between the letter “A” and the rest of the letter. After that presentation, quite a few naive students began to think that PKI is a symmetric (WRONG!) key scheme where it should be exactly the opposite — this is probably a less forgivable mistake than blowing up the chemistry lab because someone thinks inflammable means not flammable.
1.1.1 Create a host private key using openSSL
1
|
openssl genrsa -out HOSTNAME-private.pem 2048 |
This private key is 2048 bits long, generated using RSA algorithm, and we choose not to protect it with an additional passphrase because the key will be used with a server certificate. The name of the private key is HOSTNAME-private.pem where HOSTNAME should be replaced by the name of the machine you intend to host Tomcat.
1.1.2 Derive the public key using openSSL. This step is not necessary, unless you want to distribute the public key to others.
1
|
openssl rsa - in HOSTNAME-private.pem -pubout > HOSTNAME-public.pem |
1.2 Create a self-signed X509 certificate
1
|
openssl req -new -x509 -key HOSTNAME-private.pem -out HOSTNAME-certificate.pem -days 365 |
Then you will be prompted to enter a few pieces of information, use “.” if you wish to leave the field blank
1
2
3
4
5
6
7
8
|
----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Indiana Locality Name (eg, city) []:Bloomington Organization Name (eg, company) [Internet Widgits Pty Ltd]:Cool Org Organizational Unit Name (eg, section) []:Cool IT Common Name (eg, YOUR name) []:Cool Node Email Address []:. |
You will now see your host certificate file HOSTNAME-certificate.pem
UPDATE: The field Common Name is quite important here. It is the hostname of the machine you are trying to certify with the certificate, which is the name in the DNS entry corresponding to your machine IP.
If your machine does not have a valid DNS entry (in other words, doing a nslookup on the IP of your machine doesn’t give you anything), the host certificate probably won’t work too well for you. If you are only doing some very minimalistic https connection using only the HttpsURLConnection provided by Java, you can probably get by by disabling the certificate validation as outline towards the end of this article; however, if you use other third-party software packages, you will probably get an exception look like the following:
1
|
java.io.IOException: HTTPS hostname wrong: should be <xxx.yyy.zzz> |
This is because many security packages would check for things such as URL Spoofing, and when they do a reverse lookup of the machine IP, but do not yield the same hostname as what is in the certificate, they think something is fishy and throws the exception.
Part 2. Create a PKCS12 keystore and convert it to a Java keystore
Java keytool does not allow the direct import of x509 certificates with an existing private key, and here is a Java import key utility Agent Bob created to get around that. However, we can still get it to work even without this utility. The trick is to import the certificate into a PKCS12 keystore, which Java keytool also supports, and then convert it to the Java keystore format
2.1 Create a PKCS12 keystore and import (or export depending on how you look at it) the host certificate we just created
1
|
openssl pkcs12 - export -out keystore.pkcs12 - in HOSTNAME-certificate.pem -inkey HOSTNAME-private.pem |
It will ask you for the export password, and it is recommended to provide a password.
2.2 Convert the PKCS12 keystore to Java keystore using Java keytool.
1
|
keytool -importkeystore -srckeystore keystore.pkcs12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS |
Keytool will first ask you for the new password for the JKS keystore twice, and it will also ask you for the password you set for the PKCS12 keystore created earlier.
1
2
3
4
5
|
Enter destination keystore password: Re-enter new password: Enter source keystore password: Entry for alias 1 successfully imported. Import command completed: 1 entries successfully imported, 0 entries failed or cancelled |
It will output the number of entries successfully imported, failed, and cancelled. If nothing went wrong, you should have another keystore file: keystore.jks
Part 3. Configure Tomcat to use HTTPS
With the keystore in place, we can now configure Tomcat to communicate via SSL using the certificate.
3.1 Configure Tomcat HTTPS Connector.
Edit CATALINA_HOME/conf/server.xml, where CATALINA_HOME is the base directory of Tomcat. By default, the HTTPS Connector configuration is commented out. We can search for “8443” which is the default port number for HTTPS connector, and then either replace the configuration block, or add another block just below. We are going to use the Coyote blocking connector:
1
2
3
4
5
6
7
|
<!-- <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" /> --> < Connector port = "8443" protocol = "org.apache.coyote.http11.Http11Protocol" SSLEnabled = "true" maxThreads = "150" secure = "true" scheme = "https" keystoreFile = "PATH/TO/keystore.jks" keystorePass = "JKS_KEYSTORE_PASSWORD" clientAuth = "false" sslProtocol = "TLS" /> |
In the snippet above, PATH/TO/keystore.jks is the path to the Java Keystore we created earlier, and I recommend using the absolute path to eliminate any confusion. Also provide the keystore password – it is in plain text, so protect server.xml using the correct permission (700).
The Tomcat SSL configuration instruction is a bit misleading and may let us believe both blocking and non-blocking should be configured. This is not true because the port number can only be used by one connector type.
This configuration enables Tomcat to communicate HTTPS on port 8443. At this point, it is a good idea to fire up Tomcat and make sure the configuration works using a web browser.
1
2
|
cd CATALINA_HOME bin/startup.sh |
And point your web browser to https://HOSTNAME:8443 to see if Tomcat’s front page shows up. Since we are using a self-signed certificate, your browser may complain about the certificate being not secure. Accept the certificate so your browser can display the page.
3.2 Configure Tomcat to redirect HTTP to HTTPS
However, so far, Tomcat still supports HTTP (default port is 8443, but it may have been changed in your situation). It would be desirable to automatically redirect any requests to the HTTP over to the HTTPS. The first thing to do is edit CATALINA_HOME/conf/server.xml again, and this time, locate the Connector configuration for HTTP, and modify it so that the “redirectPort” attribute points to the HTTPS port (8443 by default).
1
2
3
|
< Connector port = "8080" protocol = "HTTP/1.1" connectionTimeout = "20000" redirectPort = "8443" /> |
Now save server.xml, and edit web.xml, and add the following block to the end of the file, just before the </web-app> tag (in other words, the security-constraint section must be added AFTER the servlet-mapping sections:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
< web-app ...> ... < security-constraint > < web-resource-collection > < web-resource-name >All Apps</ web-resource-name > < url-pattern >/*</ url-pattern > </ web-resource-collection > < user-data-constraint > < transport-guarantee >CONFIDENTIAL</ transport-guarantee > </ user-data-constraint > </ security-constraint > </ web-app > |
Save this file, restart Tomcat again. This time, open a browser and enter the URL to the normal HTTP port, and see if Tomcat redirects to the HTTPS port.
Part 4. Create a test Java client to talk to Tomcat over SSL
Since we created our own self-signed certificate, if we just use a Java HttpsURLConnection client trying to connect to the Tomcat over SSL, it will not honor the certificate and throw an exception like the following: