Certain very-restrictive corporate proxies will only let you CONNECT to a remote port :443.
This presents somewhat of a problem if you intend on using port 443 heavily. One, unix machines often will not let normal users listen on it. Two, often you may want to use that port for multiple things (https:// serving being the most obvious).
So... how do we allow multiple services to simultaneously sit on port 443?
Normal :80 HTTP has the concept of virtual hosts. This has been long unsupported by SSL/TLS, but it's recently been added to TLS v1.1, in the form of TLS ServerName Extensions. It adds an option field to the very first HELLO packet, allowing the client to specify which servername it would like to contact.
If your firewall allows CONNECTing to destination port :80 as well, then one can use TLS-over-HTTP along with normal HTTP virtual-host fields to do virtual-host functionality using currently widely available software.
Instead of multiplexing based on data available before the encyrpted session is set up (at the first HELLO packet, or before HTTPS even starts), you can have one program do all SSL negotiation and decryption, and then send the unencrypted data to multiple different programs on the system. The downside with this is that each endpoint may have zero control over the specific SSL negotiation configuration for their setup.
One can use OpenSSL to wrap Apache and/or other things
Apache's mod_ssl itself looks like it has some proxy capability...