0

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?

Improve this question
1

4 Answers 4

Reset to default
1

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.
Improve this answer
1

Rewrite rules are processed AFTER the HTTPS channel being established.

Think about it, the address, HTTP method, and everything else in HTTP header and body are encrypted when using HTTPS, and the rewrite rules use them. So, the HTTPS handshake must complete before the request even reaches the rules.

If you want to allow your users to start from https://mysite.internal.domain.com/ and be redirected to https://mysite.internal.domain.com:8443, there is no way other than having the SSL certificate on port 443 be valid for the domain.

I can think of these two approaches for you:

  1. Use the wildcard certificate for both bindings, since it is valid for both, as far as I can understand.

  2. Upgrade to IIS 8.0 and use SNI (Server Name Indication - http://en.wikipedia.org/wiki/Server_Name_Indication) This allows you to use different SSL certificates for different web sites that are bound to the same IP and Port, but differ only in the host name.

Improve this answer
0

If you are testing with google Chrome make sure your certificate has the common name AND the Subject Alternative Name filled with your website name (mysite.internal.domain.com) Chrome s error is not accurate as to where the problem actually is. This will get you past the ssl warning. Please post any further error message encountered

Improve this answer
0

Maybe an option to let https://mysite.internal.domain.com listen on HTTP and then redirect it to the other one? Keep in that you maybe need to instal the URL Rewrite module, if it isn't installed yet.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .