You don't. At least not yet, not on live web servers.
SSL negotiation, key exchange, sending of the certificate and all that, is done before the request is transmitted -- that is, before the server even knows which site the client is trying to connect to. The site has to serve the right certificate, though, or it will get flagged by the browser as fraudulent.
So, SSL requires one certificate per IP/port combo. No way around that, short of changing SSL itself. If you want multiple SSL sites with different certs on the same port, you'll need different IPs for each. (Although SSL sites are typically on port 443, for reference...)
Any way you might find around this will require that both sites share a certificate. And as far as SAN certs go, they seem to run between 2x and 4x as much as regular SSL certs -- and probably require lots of validation. If you don't own both domains, good luck getting one cert for them both.
If you want to try this, you may want to look at http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI -- it explains a bit on how to set up TLS virtual hosts in Apache under one IP, with different certificates for each one. But note i said TLS, not SSL -- there's no way under SSL, and it's not guaranteed to work even with TLS, as the capability requires TLS support (and an optional extension thereto) enabled in both client and server. It being optional, clients don't have to provide the server name during handshaking (and XP and many mobile browsers are particularly prone not to), making whatever sites share that IP inaccessible to them. If this is going to be for sites you intend for people to actually look at, IMO it's not an option.