Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If your cert is only valid for <code>https://www.foo.com</code> then requests to <code>https://foo.com</code> will always be greeted with that cert mismatch message.</p> <p>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.</p> <p>The obvious solution would be to not send traffic to <code>https://foo.com</code> if all activity is meant to take place on the <code>www</code> subdomain. After all, you'd get the same message by sending traffic to <code>https://xyz.foo.com</code>, 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 <code>https://foo.com</code>. </p> <hr> <p>In response to your update:</p> <blockquote> <p>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 ?</p> </blockquote> <p>It's not really a timing issue. IIS <em>has</em> 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.</p> <p><a href="http://tools.ietf.org/html/rfc2818#section-3.1" rel="nofollow">http://tools.ietf.org/html/rfc2818#section-3.1</a></p> <blockquote> <p>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.</p> <p>[...]</p> <p>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.</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload