我被要求支持將許多 SSL 密鑰映射到一個 IP，但我認為這是一個壞主意。我錯了嗎？
在工作中，我被要求添加對將多個鍵映射到單個（甚至多個）IP 的支持，以支持本質上是被動 HTTP 嗅探器。它支持使用使用者上傳的密鑰進行 SSL 解密。目前，它支持一IP到一鍵映射，或一IP到多鍵映射。問題出在通知方面。目前，如果密鑰不再起作用，我們會發送 SNMP 陷阱和/或電子郵件。使用多對多映射，我將無法知道失敗是由於其中一個映射鍵的模數已更改（因此鍵已更改）還是只是添加了一個附加鍵，或者係統管理員對解密不感興趣。主要問題在這裡，因為它的實現方式，除非允許完全重寫，否則也會破壞一對一 IP/Key 映射的目前通知。
我認為這是錯誤的，這是我的論點。有人可以幫助我支持與老闆的這一論點嗎？或者如果我錯了，請告訴我我的推理錯誤在哪裡。
這個功能是必需的，因為顯然有一個案例，其中 webapp 中的多個節點使用不同的鍵，即使它們都映射到單個 VIP。請求此功能的人堅稱他們已經在客戶端環境中看到了該功能。我想確認這是一個錯誤的觀察，但我沒有 tcpdumps 可以這樣做。我認為對於單個 IP，SSL 協商將始終發送相同的證書，因此將使用相同的密鑰，因為尚未完成 HTTPS，它只知道與 IP 的連接，不知道什麼主機: 標頭出現在此階段，供 webapp/server 確定哪個應用程序將響應。因此，在我看來，不可能有任何這樣的案例。是否存在允許您將兩個密鑰放入單個 VIP 的負載均衡器？
此外，即使可以做到這一點，根據 SSL 協商的工作方式，也無法控制最終使用者是否接收到正確的證書。這基本上是一個損壞的設置。我想不出一個有效的案例，它不會在客戶端產生隨機的 SSL 不匹配錯誤。
那麼，我是否瘋狂地認為這不是應該支持的東西？如果是這樣，我很想知道何時將多個鍵映射到一個 IP 是一個有效的案例。如果沒有，請為此提供進一步的建設性論據——因為我在上述論點上沒有成功。到目前為止的回應是“如果系統管理員不稱職，這不是我們的問題，我們應該支持它”
編輯：我打破了標題
伺服器名稱指示是對 SSL/TLS 的補充，客戶端可以在初始握手期間指示它正在尋找的主機名，然後傳輸 HTTP 請求標頭，這通常會告訴伺服器正在使用哪個主機。然後，伺服器可以根據此資訊選擇要提供的證書。
由於缺乏 Windows XP 的支持，它並沒有被廣泛使用，但大多數其他作業系統/瀏覽器組合在這一點上都支持它，就像大多數主要的 web 伺服器（不是 IIS，雖然）一樣，預計它會增加一旦 XP 終於消失了，就進行部署。
因此，不幸的是，出於您的需要，確實存在單個 IP 會向 HTTPS 客戶端提供多個不同證書的情況。