The protocol itself does not allow you to host two SSL certificates on the same port on the same IP.
From the Tomcat SSL Configuration HOW-TO:
Using name-based virtual hosts on a secured connection can be problematic. This is a design limitation of the SSL protocol itself. The SSL handshake, where the client browser accepts the server certificate, must occur before the HTTP request is accessed. As a result, the request information containing the virtual host name cannot be determined prior to authentication, and it is therefore not possible to assign multiple certificates to a single IP address.
An email to the Tomcat Users List states that you can do this with "a Connector and associated keystore per IP (or IP/port) you want to secure."
This will let you serve on separate ports (e.g.
0.0.0.0:443 publicly and
0.0.0.0:4443 for your API) and/or addresses (e.g.
192.0.2.1:443 publicly and
192.0.2.2:443 for your API).
It is theoretically possible to make this distinction on a per-interface or per-CIDR level before the SSL handshake (e.g. traffic from
192.168.0.1/16 gets one cert, other traffic gets the other cert), but I don't know of any single piece of software that does this; you'd need to use port forwarding via your firewall.
To do this with simple port forwarding: Forward connections from your internal infrastructure on port 443 to local port 4443 and serve your internal SSL cert on port 4443 within Tomcat.
Note: I've never heard of this being done.