I think the best way to look at this is to consider a Web Server's 'main' role in life is to serve up static content. So Apache is great at doing this very efficiently, it can serve up static html pages all day over either HTTP or HTTPS, depending how it is configured.
If apache wants to serve up a dynamically created page, it can hand-off to another mechanism (eg mod-perl, CGI, servlet enigine etc) which will generate the active content and apache can then present the final result (as it belives the generated page was a static one).
Tomcat, on the other hand is a web-container. It's main roles in life are to host servlets and JSP
pages, namely it can generate dynamic pages within the web-container, without having to fork new processes as we used to do in the bad-old days. However, tomcat has a few more functions in its armoury: It can serve static pages (just like apache) over either HTTP or HTTPS (config) as well has having an internal JNDI server should you wish to use it.
So, tomcat can serve dynamic or static pages over HTTP or HTTPS.
Apache serves static pages over HTTP or HTTPS.
Therefore, you can most things you need in Java
with Tomcat alone.
However, using tomcat to serve lots of static pages is really not what it was intended for, once you scale things up, it will probably run out of steam.
For an Enterprise Web-Server, you would typically use Apache to service static pages and get it to hand-off dynatic request to Tomcat servlets to process.
It really depends on the scale of the application you are aiming at.