IIS7.5 Rewrite one SSL port to another with multiple SSL bindings/certs

iisiis-7.5redirect

My web server (which only hosts for intranet sites) has two certificates. One is a wildcard cert for subdomains, and the other is the server's cert which is used for internal like tools.

  • Wildcard Cert: *.internal.domain.com
  • Server Cert: server.internal.domain.com

I just recently added our first https only site to the server using the wildcard cert. It had to use a different port: 8443, because of the Server Cert is bound to 443.

When navigating to the https://mysite.internal.domain.com/ the site fails to load throwing a security warning: NET::ERR_CERT_COMMON_NAME_INVALID. To me this seems expected, as the browser is trying to use the 443 port and the Server Cert.

The site works fine if you navigate to https://mysite.internal.domain.com:8443.

I tried to write a rewrite rule that would take any request and rewrite it to the 8443 port as a test but it doesn't seem to work:

<rewrite>
    <rules>
        <rule name="To 8443" patternSyntax="Wildcard">
            <match url="*" />
            <action type="Rewrite"
                    url="https://mysite.internal.domain.com:8443/{R:0}"
                    appendQueryString="false" />
        </rule>
    </rules>
</rewrite>

I'm still getting the NET::ERR_CERT_COMMON_NAME_INVALID errors when navigating to the site.

Anyone know how I can have a user request https://mysite.internal.domain.com and redirect to https://mysite.internal.domain.com:8443?

Best Answer

Unfortunately your redirect isn't going to work. When the browser tries to navigate to https://mysite.internal.domain.com/, the browser is noticing the mismatch of common name and hostname (as you say) and dropping the connection before the redirect has a chance to take effect. For the redirect to work, the HTTPS connection would need to be successfully negotiated so the web server could then send a response to the browser to tell it to redirect to another URL. Because the HTTPS connection fails with an SSL error, it never gets that far. This is by design because it would be a security risk for a browser to continue to communicate with the web server if it believes there is an issue with the certificate that's been presented, even if it's just to be told to redirect to somewhere else.

It sounds as though the approach you're trying to take might not be the most appropriate way of doing things and it might be worth taking a step back. Without knowing your environment in more detail, it's difficult to offer an exact solution, but the following suggestions may help:

  • Does the server have an additional IP address available? If so, you could bind the mysite.internal.domain.com site to this IP address, update the DNS and bind the wildcard certificate to this site also. This would allow you to keep the site on 443, which would be neater.
  • The wildcard certificate is also valid for server.internal.domain.com, so you could use the wildcard cert for everything unless there is some other special reason for keeping the use of the server.internal.domain.com certificate.
  • It is possible (with some limitations) to use a wildcard certificate to bind multiple sites to the same port when using SSL. See this question for more information.