Context
I need to put a Java application server (http port 8080, https 8181) behind IIS 7.5 (http port 80, https 443) on Windows Server 2008.
Steps
I have used IIS ARR module for enabling Proxy in order to route some requests to the Java application server. I have also created some URL Rewrite rules for the purpose. Using http, everything works fine.
The rule used states that when the requested URL matches the pattern (MyAppContextRoot.+), the action to be taken is Rewrite: http://localhost:8080/{R:0}.
For another application that uses https, the Rewrite rule is: https://localhost:8181/{R:0}.
In order to route https requests, I have read somewhere that I need to share the same certificate between IIS and Java, because IIS encrypts / decrypts the requests / answers. Correct me if I am wrong.
Since I am still at a development stage, I decided to share a self-signed certificate. I have created it with SelfSSL7 and I have imported into java keystore using keytool:
selfSSL7 /Q /T /I "Default web site" /N cn=myDomain.com /X /F MyCertificate.pfx /W myPassword
keytool -importkeystore -srckeystore C:\myPath\MyCertificate.pfx -srcstoretype pkcs12 -srcalias my -deststoretype jks -deststorepass myPassword -destalias MyAlias
Question
Both certificates do their job: https://myDomain.com and https://myDomain.com:8181 are up and running, but when trying to route, I get the error:
502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.
Looking at the certificates, however, there are differences in: Issued to, Issued by, validity, Signature Algorithm, key size. In particular, the algorithm for the one created by SelfSSL7 is sha1RSA (1024 Bits key), and the one created by keytool is sha256RSA (2048 Bits key).
It sounds like what you’re trying to do is a reverse proxy setup, not a redirection to the Java server, in which case the Java server should never be accessed directly, but only via IIS. It would therefore be “invisible” to the client (so you shouldn’t even see a different URL with a different port). It sounds like your rewrite rules are just redirections (not reverse proxy rewrite rules).
If you don’t need the connection between IIS and your Java container to be protected with SSL/TLS (only the connection from external clients to IIS), you don’t need to configure the Java container for SSL/TLS. IIS will be a client for your Java container, using plain HTTP.
If you want the connection between IIS and your Java container to be protected with SSL/TLS, you’ll need the certificate to be valid for the host where the Java container is hosted, as seen by IIS. This is unlikely to be the same certificate as the one used on IIS, since the one used by IIS is a public facing certificate, whereas the one for the Java container would only be for internal use (you could probably use a self-signed certificate or your own CA, depending on what the IIS reverse proxy module can be configured to accept).