Invalid certificate error with IE9 on Win7 and Nginx with multiple virtual hosts

Question

We have an Nginx instance with multiple virtual hosts on the same IP address. nginx.conf has configuration similar to the following:

server {
  listen      443 default_server ssl;
  server_name www.primary.com;
  ...
}

server {
  listen      80;
  server_name .primary.com;

  rewrite     ^(.*)   https://www.primary.com$1 permanent;
}

server {
  listen      443 ssl;
  server_name www.secondary.com;
  ...
}

server {
  listen      80;
  server_name .secondary.com;

  rewrite     ^(.*)   https://www.secondary.com$1 permanent;
}

server {
  listen      443 ssl;
  server_name www.tertiary.com;
  ...
}

server {
  listen      80;
  server_name .tertiary.com;

  rewrite     ^(.*)   https://www.tertiary.com$1 permanent;
}
...

Each domain has its own SSL certificate. All certificates are rated A+ on SSLLabs.com. However, all are shown as incompatible with non-SNI enabled browsers (for example, IE8 on WinXP).

Users are normally able to access http(s)://www.primary.com, http(s)://www.secondary.com, http(s)://www.tertiary.com, etc. just fine. However, some IE9 users on Windows 7 64-bit complain that they get a security warning (invalid certificate) when they try to access https://www.secondary.com or https://www.tertiary.com. If they override the security warning and proceed, the URL opens fine. Then, checking the certificate from the browser address bar shows the certificate for www.primary.com instead of that for the requested domain. The same users do not face any problems with any other browser such as Firefox, Chrome or Opera on the same machine. No other user has reported any errors (IE10, IE11, Safari, Windows 8, Mac OS, etc.). Also note that not all IE9 users face this problems. We have seen IE9 users within the same network that are able to access the websites perfectly fine.

Since the users are within a corporate environment where the use of the default browser (IE9) is encouraged by the IT policies, some of the affected users take the warning seriously and refuse to continue using the affected sites. We have tried the regular options like clearing browser cache.

Any thoughts or pointers on how to find and fix the root cause? We would like a solution that we can implement on the server side and does not require any intervention from the users (unless there is a documented issue with IE9 on Windows 7).