Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an intranet site, which is running on IIS 7. The site is accessible using both the FQDN (mysite.mydomain.mycompany) and by just "mysite".

The SSL certificate is signed for FQDN. It's installed and working fine if you were to visit https://mysite.mydomain.mycompany/ (Secure). Or if you access using non-secure short or long URL either http://mysite or http://mysite.mydomain.mycompany via 403.4 redirect to the secure page.

The problem I'm running into is that when a user visits the site using https://mysite/ (secure, with short alias). IIS presents the user with the only certificate it has, for "mysite.mydomain.mycompany", which of course doesn't match the address typed in by the user and they get a SSL certificate warning.

Is there anyway for me to intercept a visit to "https://mysite" and redirect the users to https://mysite.mydomain.mycompany" before SSL handshake happens with mismatched certificate?

If not, what can I do about it?

share|improve this question

No, you cannot stop the https:// request from completing an SSL handshake before a redirection could possibly be sent.

Since IIS can't do TLS Server Name Indication, probably the only effective solution for this would be to get a certificate with mysite as a Subject Alternate Name - a public certificate authority wouldn't issue this cert, so hopefully your cert is issued from an internal CA.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.