This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hello. We are having trouble with the https (port 443) connection on an app that runs on Tomcat 5.5. The app is running fine on http (port 80) now. I have uncommented the "Define a SSL ..." section in the server.xml file and set all the property values (see below). I also verified with our system engineer that the firewall is open for the server on that port. However, when I try to run the app through a browser, I get the error, "The remote device or resource won't accept the connection." Also, when I run a port utility on the server to see what ports are open and listening, it displays port 80 for Tomcat, but not port 443. Any ideas would be greatly appreciated as I've been banging my head on this one for weeks.
<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
<Connector port="443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
Change all references to port 8443 in the Tomcat server.xml to 443, not just the most obvious one.
Do be aware, however that on most OS's, wiring Tomcat directly to ports 80 and 443 is a security risk, since Tomcat must be run as a privileged user in order to be able to open and listen on those ports. That is one of the reasons why the defaults are 8080 and 8443.
An IDE is no substitute for an Intelligent Developer.
Joined: Oct 01, 2012
First, thank you Tim for your reply. Regarding the port references in the server.xml file, there were two other references to port 8443 as the "redirectPort" property value in the port 80 connector section and the port 8009 connector section. I had already changed both of those values to 443, so I didn't make any changes for that sake (still not working). However, based on your other comment about port security issues, I went ahead and changed the https connector section back to port 8443 and also the two other previously mentioned connector sections. And of course it worked. So, I wonder if the "privileged user" is an issue? Are there special permissions required for the account that runs Tomcat for port 443? As you can tell, I am a Tomcat newbie, so I may not have worded that question correctly, but that's the only logical reason I can think of to explain why it worked just by changing the port back to 8443. (forgot to mention prior, our OS is Windows 2008 R2, no Apache web server, just Tomcat 5.5 to run this one app).
There has long been a standard that TCP/IP ports with numbers less than 1024 were "magic" and could only be held by privileged users. This was probably never as good an idea as it sounded, but it's entrenched, and while earlier versions of Windows didn't always enforced that rule, all the more recent editions I know of do.
The problem is, if a user is privileged, it can, if exploited, muck around with a lot more than just protected tcp/ip ports. So you really don't want to run anything as a privileged user if you can avoid it.
A lot of Internet apps have protections to limit the exposure. Programs such as the Apache httpd server "jail" themselves; they open ports 80 and 8443 and then launch their primary processors under an alternate, less privileged user ID.
Unfortunately, there's no "write-once/run-anywhere" way of doing things like that, so whatever user ID Tomcat launched under is the user ID it runs everything under and therefore use of ports 80 and 443 require a privileged user.
What's generally done to mitigate that is to proxy Tomcat with a safer server such as Apache. Apache is fairly low overhead, can offer ports 80 and 443 safely, and has the additional advantage that it allows a mix of Java and non-java webapps, since Apache itself can run things like PHP and python cgi. And, of course, Apache is one of the most efficient servers of static content available.
Joined: Oct 01, 2012
Once again, thank you very much Tim for the comprehensive response. It was very helpful and I really appreciate it.