Well, my preferred application architecture usually has a non-secured welcome page, so that's on Port 80. Even if the rest of the app is secured, I just like to have sort of a "signpost" that leads into things. The welcome page would then typically link to the secured URLS, would could be HTTP or HTTPS. With Tomcat container-managed security, Tomcat itself would typically respond to secured resource requests on port 80 by sending back a "302" challenge that would tell the browser to switch to 443.
As for the cert "error" part, that sort of depends on your larger network architecture. Often a proxy such as Apache HTTP is used to frontend Tomcat, and typically the internal users would simply use the same URL/IP address as the external users.
I'll admit, I'm hazy on some of this, because, yes, normally I don't have to worry about the details. I just follow standard practices and it more or less "Just Works".
One thing you can do if it's more friendly to your network setup is to simply define 2 separate virtual hosts in Tomcat for the 2 different IP addresses, but that wouldn't affect the protocols required. Then again, it's not such a bad idea to encrypt internal traffic as well. Especially if you're Sony.