HTTPS only verifies the host name when checking a certificate (see RFC 2818 Section 3.1), not the port, so you shouldn't have any problem using the same certificate for two different applications on the same host.
You could have:
- Apache Httpd on
https://www.example.com/
(port 443, default)
- IIS on
https://www.example.com:8443/
(port 8443)
Where it's going to be a problem is if you want to use the same port for Apache Httpd and IIS. It's not necessarily a good idea to have a different server running on a non-standard port for HTTPS: it may cause problems since some firewalls (and some proxy servers) will not let you connect to HTTPS on another port than 443 (or at least, port 8443 won't be open).
A solution to this is to use Apache Httpd as a front-end and forward a "section" of the request (e.g. eveything starting with https://www.example.com/iis/
) to IIS in the back. This can be done using a reverse proxy (see mod_proxy_http
in Apache Httpd). If your IIS server is on the same machine, the redirection can effectively go to localhost
(on the port of your choice for IIS, maybe not the default 80). In this case, the connection between Apache Httpd and IIS don't need to be secured with SSL/TLS, so you wouldn't need to set up a certificate for IIS (you can if you really want to, but it's not useful on localhost
connections). All SSL/TLS connections from the users would end at Apache Httpd, which would then dispatch internally some request to IIS in the back.
There might be more documentation generally available about this when putting Apache Tomcat (or a Java container) behind Apache Httpd, but the principles should be the same when replacing Tomcat with IIS.
Here is some documentation about Apache Httpd with Jetty: http://wiki.eclipse.org/Jetty/Howto/Configure_mod_proxy#Configuring_Apache_mod_proxy_with_Jetty
From Apache Httpd's point of view using IIS instead of Jetty should be very similar. You may have to tweak the IIS configuration to make it pretend its incoming requests come over HTTPS (since they will come over plain HTTP), if some of your IIS apps are configured to require this.
I think IIS also has reverse-proxy capabilities, so if this approach is too tricky, you should be able to reverse the roles. Look for using IIS as your HTTPS entry point and putting your Apache/PHP application in the back.