0

I have a scenario where external clients are receiving a certificate that is different than the one that is bound to the IIS site. This is Win2008R2 / IIS, in the following configuration:

(interwebs) -- > (LB) --> (IIS reverse-proxy/DMZ) --> (IIS www hosting 2 separate sites each with unique FQDN, unique IP, & unique SSL EV)

There is no cert on the LB. There are no certs on the IIS rev proxy (its just an HTTP redirect / URL-rewrite)

The IIS server has (2) sites configured, each with its own unique FQDN, and corresponding SSL EV cert bound to a unique IP on the server. E.g.

  • physical IP = 1.1.1.1
    • virtual-ip1 = 1.1.1.2
    • virtual-ip2 = 1.1.1.3
  • app.abc.com = 1.1.1.2
  • app.xyz.com = 1.1.13

Currently, clients get the correct cert when reaching app.abc.com, but when going to app.xyz.com, they get an SSL cert error about name mismatch, where the FQDN doesn't match the common name. I've verified when on the IIS server, the certs FQDN and common name/issued to matches what it should be.

WHERE is this cert coming from? If I were to run packet-capture on say, the client, the IIS server, where would you think the cert will show from when filtering SSL traffic?

(apologies if this is missing information)

2
  • 1
    If the Common Name in the certificate subject is app.abc.com and external clients need to browse app.xyz.com, of course they are going to get a name mismatch error. The browser is literally saying: "app.abc.com" is not the same as "app.xyz.com" - which is entirely correct. Feb 25, 2015 at 8:39
  • clients get the correct cert when reaching app.abc.com, but when going to app.xyz.com, they get an SSL cert error about name mismatch - Of course they do.
    – joeqwerty
    Feb 25, 2015 at 16:00

0

You must log in to answer this question.

Browse other questions tagged .