Let's say I want two secure sites running from the same machine using the Apache server:
1. https://example.com
2. https://example.ca
Is it possible to use port 443 for both of the above sites?
SnapOverflow
As already explained, the SSL connection is created before any actual data is sent over the connection so Apache can not provide different SSL certificates for each of your virtual sites since it has no idea which server name is being requested. What this means is that regardless of what server name is actually requested (In this case "mysite.com" or "mysite.ca"), Apache will respond with the default SSL certificate it has been configured to use. This might be declared inside of the "default" 443 VirtualHost or in the global Apache configuration.
What this means from a usability standpoint is that you can absolutely host both sites from the same apache host and IP but users will receive a warning when accepting the certificate telling them the certificate is for the wrong site. The only way around this would be to have two different IP addresses and configure your virtual hosts so that they each listen on a different address. (Make sure to update DNS accordingly)
Once the certificate exchange has taken place, normal VirtualHost rules will apply and you can actually host different content on each server name if that's what you desire to do.
These examples are a little rough, you'll want to consult official apache documentation on the exact parameter names for setting up virtual hosts and configuring ssl if you don't know the basics already.
Example: Two servers on different IP addresses with different document roots, each presenting the correct certificate
Example: Two servers on the same IP using the wrong certificate (configured elsewhere) but still serving different content based on server name.
You can run multiple SSL sites from a single IP address using a couple of methods, each with their own drawbacks.
The first method is to have a SSL certificate that covers both sites. The idea here is to have a single SSL certificate that covers all the domains you want to host from a single IP address. You can either do this using a wildcard certificate that covers both domains or use Subject Alternative Name.
Wildcard certificates would be something *.example.com, which would cover www.example.com, mail.example.com and support.example.com. There are a number of problems with wildcard certificates. Firstly, every hostname needs to have a common domain, e.g. with *.example.com you can have www.example.com, but not www.example.org. Secondly, you can't reliably have more than one subdomain, i.e. you can have www.example.com, but not www.eu.example.com. This might work in earlier versions of Firefox (<= 3.0), but it doesn't work in 3.5 or any version of Internet Explorer. Thirdly, wildcard certificates are significantly more expensive than normal certificates if you want it signed by a root CA.
Subject Alternative Name is a method of using an extension to X509 certificates that lists alternative hostnames that are valid for that certificate. It involves adding a "subjectAltName" field to the certificate that lists each additional host you want covered by the certificate. This should work in most browsers; certainly every modern mainstream browser. The downside of this method is that you have to list every domain on the server that will use SSL. You may not want this information publicly available. You probably don't want unrelated domains to be listed on the same certificate. It may also be difficult to add additional domains at a later date to your certificate.
The second approach is to use something called SNI (Server Name Indication) which is an extension in TLS that solves the chicken and egg problem of not knowing which certificate to send to the client because the client hasn't sent the Host: header yet. As part of the TLS negotiation, the client sends the required hostname as one of the options. The only downside to this is client and server support. The support in browsers tends to be better than in servers. Firefox has supported it since 2.0. Internet Explorer supports it from 7 onwards, but only on Vista or later. Chrome only supports it on Vista or later too. Opera 8 and Safari 8.2.1 have support. Other browsers may not support it.
The biggest problem preventing adoption is the server support. Until very recently neither of the two main webservers supported it. Apache gained SNI support as of 2.2.12, which was released July 2009. As of writing, IIS does not support SNI in any version. nginx, lighttpd and Cherokee all support SNI.
Going forward, SNI is the best method for solving the name-based virtual hosting of HTTPS, but support might be patchy for a year or two yet. If you must do HTTPS virtual hosting without problems in the near future, IP based virtual hosting is the only option.
Only if the sites are on their own IPs.
SSL connectivity happens before the client asks for a website, so when the SSL connection is set up the server has no idea what the client is going to ask for.
For example if you are presenting the .com SSL cert, which would make clients asking for the .ca unhappy.
The solution is to set up a second IP for the .ca, and have a separate instance of the web server listen on that IP with the .ca's SSL cert.
Yes, as long as you assign multiple IP's to the machine. One for each SSL certificate/domain. Generally, you'll need a unique IP for each SSL server. Windows, Linux, BSD & Solaris all support multiple IP's on a single NIC or you can add extra NIC's or multi-port NIC's. It's quite common to to assign 10-20 IP's per machine/NIC in a web serving environment.
Other SSL options that won't work with your criteria.
Wildcard SSL certificates can host many sub-domains as long as the second level domain is the same, typically used for mass virtual hosting.
Shared SSL certificates can be used on multiple machines for the same domain, typically used for failover and load-balancing.
Good answers, however, using one HTTP server to host both sites has a SPOF - i.e. once instance of apache server. If that apache server goes down, both sites aren't reachable. How about a dual-port ethernet card? or, even better, using virtualization. I'm a big fan of virtualization like xen or openVZ. However, you'll need to spend some money on hardware though.
dear users kindly use haproxy in the front of your apache2 in this case you will able to forward different domain on the same apache server on the different ssl port but you need to configure tow different site under site enabled with ports such as 443 and 8443 you can copy past the first ssl site and change inside only port and domain alias you will find help regarding apache2 ssl activation also you need to difine hosts file with 2 ips like 127.0.1.1 web-ssl1 127.0.2.1 web-ssl2