A few months ago I was tasked with setting up a LAMP server to run Apache Tomcat, and ODK Aggregate. The installation went fairly smoothly, considering it was my first having to deal with tomcat.
About a week ago our developer decided he wants to use SSL for his tomcat traffic. I have spent several days studying and following various online tutorials on how to accomplish this, but so far, no luck.
My setup so far: Debian Squeeze, apache2, tomcat6 running fine with ODK Aggregate, the only app running in tomcat so far.
I have the following lines in pointing to my certificate files in /etc/apache2/sites-available/default-ssl
A little quick googling makes it appear that this particular message comes from the Chrome browser, so you might want to try another browser and see if you can get a more informative message.
I think you know this, but it never hurts to remind people: The security cert formats are not the same for Tomcat and Apache httpd. Which is a real pain. Not only can you not share the certs directly, but the process of format conversion can be really annoying.
An IDE is no substitute for an Intelligent Developer.
Joined: Jul 13, 2012
Thanks Tim. Perhaps I should have mentioned this in my initial post, but I did quite a bit of google searching (as I always do) before posting. I did see the issue with Chrome coming up, but I'm getting errors in all browsers (IE and Firefox), so I'm inclined to believe the issue is with the server, not the browser. Here's what I get in Firefox:
Secure Connection Failed
An error occurred during a connection to test.com:8443.
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.
Most probably you are sending a http (non-encrypted) request to the https port, despite your intentions of sending it https-format.
How it's getting sent without the encryption isn't obvious to me at the moment, though.
Joined: Jul 13, 2012
That kinda makes sense. After reading your last post, I got an idea to try both https://test.com:8080 and https://test.com:8443. As I suspected, they both return the same error. So apparently, Tomcat is listening on both ports in http only, even though in the configuration I have scheme="https", secure="true", and sslProtocol="TLS" for 8443.
Is it possible that Tomcat tries to load the SSL info for port 8443, finds something wrong in the config or maybe the certificate and then just fails over to regular http? I'll check my Catalina logs again...
Joined: Jul 13, 2012
After much frustration, I decided to try generating a self-signed certificate. After doing so, telling server.xml where to find it, restarting tomcat, I noticed the following in my catalina log:
and another tomcat restart, it now runs SSL on port 8443!
Somewhere in the many tutorials I've studied in the course of setting this up, I remember someone saying that permissions on all certificate files should be set to 400, which is what I've been doing.
Clearly this doesn't work (at least not if root is the owner), but 755 does.
Of course, I still want to be able to use the Thawte certificate I paid for, so my next question is: How should I set permissions in my certificate files to allow tomcat to read them, but still keep them secure?
-- btw thanks Tim Holloway for stimulating some ideas and helping me along this far. I will post my findings and my working SSL connector once I get everything working.
The keystore isn't a certificate file, it's a database. To access the certs, you have to invoke a retrieval process that must be given a password, and beyond that there are 2 levels of passwords available for the exceptionally paranoid.
I noticed that the actual rights I have set on my test system are 664, although I suspect that 600 would probably be more appropriate. Why write access? Not sure, but there may be some history that needs updating when the keystore is accessed.
If you're serious about securing the keystore, several additional things can help. First, place it in location that's more generally secured and out of harm's way. On Linux, that would be in the /etc directory, although /etc has its public aspects. Secondly, you could consider using the selinux security system to limit access to the keystore on a fine-grained basis. That's not a trivial process, but it's an effective one.