1

I'm using a tool called : ISAPI Rewrite 3 Lite from Helicon Tech (an "apache .htaccess mod_rewrite compatible module for IIS").

I've applied the "Redirecting non-www version to www" rule (from : http://www.helicontech.com/isapi_rewrite/doc/examples.htm#hotlinking ). i.e. : 

RewriteEngine on

RewriteCond %{HTTPS} (on)?
RewriteCond %{HTTP:Host} ^(?!www\.)(.+)$ [NC]
RewriteCond %{REQUEST_URI} (.+)
RewriteRule .? http(?%1s)://www.%2%3 [R=301,L]

This works ok, but I have a slight problem with browser warnings when used with SSL. Say I want a url request like : https://MyDomain.com/abc/login.aspx to be re-directed to : https://www.MyDomain.com/abc/login.aspx The browser will show a warning like : "The security certificate presented by this website was issued for a different website's address." This makes sense because our SSL certificate only works for "www.MyDomain.com" (and not "MyDomain.com"). If you click "Continue to this website ?" it redirects fine to the required url, and all is well.

My question : is there something that can be done to make the browser SSL certificate warning NOT come up ? (Preferably without having to change the SSL certificate).

Thanks.

EDIT :

I was hoping that there was some way to get ISAPI Rewrite to change the url, so that IIS does not "see" the request to : "MyDomain.com", and only sees the altered request to : "www.MyDomain.com" (so that the SSL certificate warning would not occur). I thought it might have been a timing issue of sorts. But it looks like the timing of events is fixed, so that IIS will always check the SSL certificate in the context of the original request ? Can anyone confirm this ?

Moe Sisko
  • 11,665
  • 8
  • 50
  • 80

1 Answers1

2

If your cert is only valid for https://www.foo.com then requests to https://foo.com will always be greeted with that cert mismatch message.

Wildcard certs are often expensive but if you shop around a bit you can find one for close to the price of a normal cert.

The obvious solution would be to not send traffic to https://foo.com if all activity is meant to take place on the www subdomain. After all, you'd get the same message by sending traffic to https://xyz.foo.com, but it's a non-issue, because there's no reason to send traffic there. Similarly, there's probably no reason to send traffic to https://foo.com.

In response to your update:

I was hoping that there was some way to get ISAPI Rewrite to change the url, so that IIS does not "see" the request to : "MyDomain.com", and only sees the altered request to : "www.MyDomain.com" (so that the SSL certificate warning would not occur). I thought it might have been a timing issue of sorts. But it looks like the timing of events is fixed, so that IIS will always check the SSL certificate in the context of the original request ? Can anyone confirm this ?

It's not really a timing issue. IIS has to "see" the request in order to redirect it, and is required to present its identity on every request. Conforming browsers are required to alert the user (or simply "hang up") when the server's identity doesn't match the host name.

https://www.rfc-editor.org/rfc/rfc2818#section-3.1

If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.

[...]

If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error.

Community
  • 1
  • 1
Dagg Nabbit
  • 75,346
  • 19
  • 113
  • 141