Best-Practice Loadbalancing WebServer

Hallo zusammen,

ich versuche gerade einen neuen Netzwerkaufbau, allerdings stoße ich an irgendeiner Stelle immer an etwas, dass für mich nicht so recht ins 21. Jahrhundert passen möchte.

Also:
Domain A zeigt auf Loadbalancer

Nun gibt es ja 3 Optionen:

Option 1:
- Loadbalancer agiert als HTTP Balancer, erhält Zertifikat für Domain A und leitet die Anfragen dann unverschlüsselt ins Rechenzentrum an die eigentlichen Webserver weiter

Vorteil:
Geringere Last auf den Webservern, weil nichts entschlüsselt werden muss.
Client IP Adresse kann auf den Apache Webservern ausgelesen werden

Nachteil:
- Unverschlüsselte Kommunikation zwischen dem Loadbalancer und den Webservern quer durch das Netz
- Zusätzliche Anpassungen an den Websites notwendig, da keine HTTP Elemente darin auftauchen dürfen

Option 2:
- Loadbalancer agiert als TCP Balancer, Zertifikate für Domain A sind auf den Webservern - Verbindung zwischen Loadbalancer und Client bei Aufbau unverschlüsselt

Nachteil:
- Apache Webserver hat keine Möglichkeit, die Client IP in Erfahrung zu bringen, da TCP Routing und daher keine Möglichkeit für FORWARED_IP

Option 3:
- Loadbalancer agiert als HTTPS Balancer, erhält Zertifikat für Domain A und leitet die Anfragen dann verschlüsselt an die jeweiligen Webserver weiter

Vorteil:
End2End Verschlüsselung ist auch dann sichergestellt, wenn der Loadbalancer irgendwo in der Cloud steht und die Webserver in einem anderen Rechenzentrum
Client IP Adresse kann auf den Apache Webservern ausgelesen werden

Nachteil:
- zusätzliche Zertifikate sind notwendig.

Variante 3 finde ich ja fast am besten, nur ist mir nicht wirklich klar, was für ein Zertifikat ich hier auf den Backend-Servern brauche. Selbstsignierte werden logischerweise von jedem Browser angemahnt, die gleichen wie auf dem Loadbalancer klingt auch nicht wirklich sinnvoll.

Wie habt ihr sowas bisher umgesetzt?

Danke und Grüße

René