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 = 188.8.131.52
- virtual-ip1 = 184.108.40.206
- virtual-ip2 = 220.127.116.11
- app.abc.com = 18.104.22.168
- 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)