How to configure tomcat 7 with SSL on Ubuntu 14 - the unanswered questions

Question

There are hundreds of guides to installing SSL on tomcat, but none of them I can find answer these key questions.

There are two ways to install SSL: one is to us keytool, the other is to simply put the cert files on the FS and point the server.xml at these files (not using keytool).

Here are the questions I would be very grateful if someone knows the answer:

1. Is there any advantage to using the more complex keytool, vs just putting the certs on the FS, e.g. in /etc/ssl
2. If using keytool, you have to supply "-keystore xxx.jks". Where should the xxx.jks be located e.g. /root, /home/tomcat7, /etc /var/lib/tomcat7? I could only find one guide which said how to setup the keystore, and it said to put it in tomcat dir, which seems mad as when we upgrade tomcat, we lose the certs, but if this is a hard requirement then we can do it.
3. If using keytool, which user should use the tool to import the cert, tomcat7 or root?
4. They available examples show how to import a cert into a keystore which was used to generate the original csr. We didn't use it to generate the csr (we were given the certs from a 3rd party). Does this mean we cant use keystore, or need to generate a dummy csr first?

We don't know which CA was used to issue the cert, so cant look there for answers. We have 3 files: gd_bundle-g2-g1.crt, our.crt and our.key

we use java 7.

----- UPDATE 1 ------

Having received advice that we cant use keytool for our existing key/crt files (issued by go daddy we think), we tried the old way of putting the key/certs right into the server.xml, which certainly used to work with older versions of tomcat:

We get this error:

 java.io.FileNotFoundException: /usr/share/tomcat7/.keystore (No such file or directory)

---- UPDATE 2 -----

We found this post which showed how to use existing certs with tomcat:

openssl pkcs12 -export -in mycert.crt -inkey mykey.key -out our.p12 -name tomcat -CAfile myCA.crt -caname root -chain

Then edit the server.xml:

<Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
           maxThreads="200" scheme="https" secure="true"
           keystoreType="PKCS12"
           keystoreFile="/etc/ssl/our.p12" keystorePass=""
           clientAuth="false" sslProtocol="TLS" />

however, this brings this message in catalina.out:

 SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"]
 java.net.SocketException: No such file or directory

----- UPDATE 3 -----

So we don't know why 433 fails (port 80 works, and nothing else is on 443, and we are starting it as root), but if we change it to 8443, tomcat starts with no errors (horay!), but when we navigate to www.oursite.com/ourwebapp:8443 we get 404. If we try https://www.oursite.com/ourwebapp:8443 we get "this web page is not available" from chrome.

netstat -a

Shows that its listening on port 8443 (and 80, but nothing on 443)

Any ideas?

Answer 1

Do you actually WANT Tomcat to handle SSL itself, or is it behind a web server that is going to handle SSL for it anyway? If the latter, simply comment out the SSL connector in server.xml.

Answer 2

To address this part of the above problem reported in catalina.out...

SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-443"] java.net.SocketException: No such file or directory

For me this was caused by tomcat not being allowed to bind to port 443, and was nothing to do with the keystore/certificates.

I fixed it by running...

sudo touch /etc/authbind/byport/443 
sudo chmod 500 /etc/authbind/byport/443 
sudo chown tomcat7 /etc/authbind/byport/443

if you don't have authbind installed, install it via

apt-get install authbind

Answer 3

1. As previously stated, it depends on your connector, Apr based connectors use openssl (individual files), JSSE based connectors use the java runtime ssl implementation (keystore). Apr performs better (generally speaking) when the number of http clients/requests increases.

2. Fedora link recommends /etc/pki/app/private as the location to store private keys and certs. We use /opt/pki/httpd/private.

3. User doesn't matter as long as it can write to the keystore file, but the keystore should be owned (writeable) by the user (in our case we use group) that runs tomcat.

4. You have to import the cert, the bundle and the key into the keystore, preferably in that order. Assuming they are PEM encoded (because they work in apache httpd) you can use the pkcs route:

openssl pkcs12 -export -in our.crt -inkey our.key \ -out our.p12 -name some-alias \ -CAfile gd_bundle-g2-g1.crt -caname root -chain

Use changeit as the password. Sometimes -CAfile -caname doesn't work and you have to use -certfile gd... instead.

Then convert to keystore:

keytool -importkeystore \
    -deststorepass changeit -destkeypass changeit -destkeystore our.jks \
    -srckeystore our.p12 -srcstoretype PKCS12 -srcstorepass changeit \
    -alias application

Answer 4

Let's start by clearing a few things up.

First, X.509 certificates are X.509 certificates, whether they are bundled within a Java keystore, PKCS12 keystore, or in separate PEM files like OpenSSL-based software usually uses. You can convert back and forth between all of those.

Second, Tomcat has two different types of connectors: those based upon JSSE (which all currently require the use of Java or PKCS12 keystores) and the native APR-based connector, which requires the use of PEM-encoded files on the disk, like Apache httpd does.

There is one big reason to prefer the native APR-based connector over the JSSE-based connectors: performance. And I'm not just talking about a few percent. Recent benchmarks put OpenSSL performance at an order of magnitude faster than JSSE.

If you expect to use a JSSE-based connector, then you should probably generate your key and CSR using keytool: it will be a lot easier for you that way. If you expect to use the APR-based connector, you should probably use OpenSSL from the command-line to manipulate everything.

(Note that in the upcoming Apache Tomcat 9 (and possibly Tomcat 8, if it gets back-ported which has a fairly good change) will accept TLS configuration for any connector in any of these formats. That is, you can use PEM-encoded certificates and keys in separate files or Java/PKCS12 keystores with either the native APR-based connector or the JSSE-based connectors.)

Third, if you didn't generate the key yourself (or someone you really trust, like a coworker, NOC, etc.), then @EJP is right: your certificate is not secure. If your certificate authority generated your key for you, then you really should start again. There is no reason for you to trust your certificate authority.

(As for not knowing which CA signed your key... the various certificates you have should not have any mysterious identification or anything like that. The whole point of a certificate authority is that it is well-known and trusted. You shouldn't have a difficult time determining who the CA is based upon the certificates that you have in front of you. If you can't determine which CA is involved, you may want to give this task to someone else who is more familiar with X.509 certificates.)

Answer 5

There are hundreds of guides to installing SSL on tomcat, but none of them I can find answer these key questions.

The only one you need is the one that comes with Tomcat.

There are two ways to install SSL: one is to us keytool, the other is to simply put the cert files on the FS and point the server.xml at these files (not using keytool).

Untrue. In both cases you have to generate a keypair and a CSR. The Tomcat documention shows how to do that with both openssl and the Java keytool. You can't just start from nowhere with a certificate file.

Is there any advantage to using the more complex keytool, vs just putting the certs on the FS, e.g. in /etc/ssl

Straw-man argument. The keytool is IMHO considerably less complex than openssl.

If using keytool, you have to supply "-keystore xxx.jks". Where should the xxx.jks be located e.g. /root, /home/tomcat7, /etc /var/lib/tomcat7?

Anywhere you like. Tomcat provides the means whereby you tell Tomcat where the keystore is.

I could only find one guide which said how to setup the keystore, and it said to put it in tomcat dir, which seems mad as when we upgrade tomcat, we lose the certs, but if this is a hard requirement then we can do it.

It is of no interest to discuss what an unstated piece of arbitrary Internet junk says. Follow the Tomcat documentation.

If using keytool, which user should use the tool to import the cert, tomcat7 or root?

It doesn't matter as long as the user has write access to the keystore.

They available examples show how to import a cert into a keystore which was used to generate the original csr. We didn't use it to generate the csr (we were given the certs from a 3rd party).

In that case you can't even start. Your first step is to generate a keypair. Nobody else can do that for you. The private member of the pair is private to you. If somebody else has provided it, it isn't private, so it cannot possibly fulfil the purpose for which it was intended.

Does this mean we cant use keystore, or need to generate a dummy csr first?

You need to generate a real keypair, a real CSR, get it signed, and import it back into the keystore, using the same alias in all three cases.

We don't know which CA was used to issue the cert, so cant look there for answers. We have 3 files: gd_bundle-g2-g1.crt, our.crt and our.key

Throw them all away and start again. The process you have been following, or given, is completely and utterly invalid and insecure from start to finish. If you have been given a .key file it is entirely worthless, and whoever gave it to you doesn't know what they're talking about and should be taken out of this loop. Fired.