Maybe there's an easier way to do what I'm trying to do, but the reason I did it this way is so that:
(a) there's no reliance on the Internet connection for internal users (my firewall does not support loopback / reflection - which is what I understand would be required to automatically redirect mydomain.com back to the internal IP for internal users)
(b) internal users will not receive an SSL warning by accessing the https site using the internal IP (the certificate is registered for mydomain.com)
What I would like is for external users only to be automatically redirected from 80 to 443. That way they will not have to remember to enter https every time - they could simply enter mydomain.com/mysite/ and be redirected to https automgically.
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.