Although I dont' know the specifics for Tomcat the general setup for providing TLS goes like this:
- server certificate
- server private key
- additional certificates to complete the chain between your server certificate and the root certificate of the CA that signed your server certificate
A Java keystore (I guess Tomcat should be able to use such) is able to store all three information in one single java keystore file. In addition you may could try to use what's known as a PKCS#7/8/12 (? don't know from the top of my head right now - but it's one of those three) file - it's pretty much the standardized version from what the java keystore JKS format seems to be derived.
Otherwise you may have to provide all three as their own files.
Just as an example: I use Let's Encrypt with my Apache - so I have my private key, the server certificate signed by the LE intermediated CA and the LE intermediate ca certificate in three files: server.pem, server.key and chain.pem. To have this working I have Apache configured to use the server.pem as the server certificate, server.key as the server private key and chain.pem as additional ca chain file.
As by recommended standards like SSLLabs you have to include all intermediate CAs to complete the chain but NOT the CA root certificate itself as this has to be stored in the client for verifying the chain.
If your server is public then use the server tester on ssllabs.com to check if you have setup all correctly. Don't bother to get an A+ at first try - get it working and progress from there.
Although I've configured SSL for Tomcat countless times, it still gives me grief. Which is why I didn't reply earlier. I'm not comfortable enough to offer a sure-file solution. But basically, what Bob has said is on the right track.
A Java keystore is a special encrypted database file and Tomcat uses one just like any other Java application using a keystore would. You tell Tomcat the keystore password and Tomcat looks up the necessary information - which by default would be found via the key named "tomcat" in the keystore.
Where the fun comes in is in keeping track of the private key versus its cert (some servers combine both into a single file, but Java keystores have separate entries) and - most importantly - ensuring that your cert and private key are encoded properly, since there's only about 17 different schemes being used for different webapp servers. And Apache web server and Tomcat webapp server don't use the same one, incidentally. Grr. Plus, as Bob mentioned, you have to maintain the chain of trust, but that's actually not too hard, since you can't add an entry out of sequence there - the internal references in the chained certs will ensure that you can only add them in the proper order. Each cert, incidentally is also a key/value entry in the keystore, but the name(s) you store the intermediate cert(s) under aren't required to be anything specific as long as they are unique. And of course, not "tomcat", since that's the key for the Tomcat server itself.
One thing I've found that can help immensely is the Java tool "portecle", available from sourceforge.net It provides a GUI maintenance utility for keystores and can also convert cert formats as needed. It's supposed to download and run via JNLP, although that's not working properly ony my system at the moment, so I had to download and unzip the package myself.
Incidentally, using SSL on Tomcat is not as useful as you might think. Very often, Tomcat is not facing the open Internet, it's accessed via a reverse proxy such as Apache httpd or nginx or even IIS. In that case, the SSL would be the SSL for the proxy server and configured on the proxy server. You hopefully have a secure internal network, so the proxy-to-Tomcat communications would not be SSL. And, in fact, would often be via the AJP proxy-to-Tomcat (coyote) connector, not HTTP/HTTPS.
And it's a lot easier to set up SSL for Apache or Nginx!
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.
Evil is afoot. But this tiny ad is just an ad:
Two software engineers solve most of the world's problems in one K&R sized book