I'm being asked to support mapping many SSL keys to one IP but I think it's a bad idea. Am I wrong?

Question

At work, I've been asked to add support for mapping multiple keys to a single (or many even) IP to what is essentially a passive HTTP sniffer. It supports SSL decryption with user-uploaded keys. Currently, it supports a one IP to one key mapping, or one IP to many keys mapping. The problem is with the notification aspect of this. Currently we send SNMP traps and/or email if the key is no longer functional. With a many-to-many mapping, I will have no way to know if the failure is due to a modulus which has changed for one of the mapped keys (hence a key has changed) or it's simply an additional key that was added, or the system admin is not interested in decrypting. The major problem is here because the way it will be implemented, unless a full rewrite is allowed, will also break current notification for one-to-one IP/Key mappings.

I think this is wrong, and here's my argument. Can someone help me with supporting this argument with the bosses? Or if I'm wrong, please show me where my error in reasoning is.

This functionality is required because apparently there's a use case where multiple nodes in a webapp use different keys, even though they're all mapped to a single VIP. The person requesting this functionality insists they have seen it in action in a client environment. I would like to confirm that this is a mistaken observation but I have no tcpdumps to do so with. I maintain that for a single IP, the SSL negotiation will always send the same cert, and hence the same key will be used, because no HTTPS has been done yet, it only knows of a connection to an IP, no knowledge of what host: header is present at this stage for the webapp/server to determine what application will respond. Thus, in my mind there can't be any such use case. Does a load balancer exist that can allow you to put two keys to a single VIP?

Furthermore, even if it was possible to do this, based on the way SSL negotiation works, there would be no way to control that the end user is even receiving the correct cert. This would essentially be a broken setup. I can't think of a valid use-case for this where it wouldn't entail random SSL mismatch errors on the client side.

So, am I crazy to think this is not something that should be supported? If so, I'd love to know when having multiple keys mapped to a single IP is a valid use-case. If not, please provide further constructive arguments to that end - as I have been unsuccessful with the above arguments. The responses so far are to the tune of "it's not our problem if a sysadmin is not competent, we should support it"

edit: I broke the title

Answer 1

Server Name Indication is an addition to SSL/TLS where the client can indicate which host name it's looking for during the initial handshake, before the transfer of HTTP request headers which would normally be what tells the server what host is being used. The server can then select which certificate to present based on this information.

It's not in terribly wide use due to a lack of support from Windows XP, but most other OS/browser combinations support it at this point, as do most of the major web servers (not IIS, though), expect it to be increasing in deployment once XP is finally gone.

So, unfortunately for your needs, there are indeed cases where a single IP will present multiple different certificates to HTTPS clients.