Ich habe viele Server, die auf verschiedene externe Webservices zugreifen, von denen die meisten SSL verwenden, von denen einige Client-Zertifikate erfordern. Ich möchte die Konfiguration von Client-Zertifikaten zentralisieren und die Präsentationsschicht von den zugrunde liegenden Servern trennen.
Obwohl ich Squid zum Proxy der Anforderungen verwenden könnte, kann ich in den Dokumenten nicht sehen, wie Squid angewiesen werden soll, ein Client-Zertifikat auszuwählen, das für den Ziel-Webservice spezifisch ist. Ist das möglich?
Ein Ansatz wäre, eine Gruppe von Stunnel-Instanzen über den Squid-Proxy hinaus zu verwalten und dann die Client-Software so zu konfigurieren, dass http-Anforderungen mit einem URL-Rewriter verwendet werden, um die Anforderung über die entsprechende Stunnel-Instanz weiterzuleiten. Dies wird jedoch unterbrochen, wenn ich eine XML-Antwortreferenzierung erhalte eine HTTPS-DTD (es sei denn, ich schreibe den Inhalt mit einem vollständigen MITM neu).
Gibt es eine andere Lösung?
aktualisieren
Das Problem beim Umschreiben von 'https' in 'http' besteht darin, dass dann alle zusätzlichen Ressourcen mit einem http-URI unterbrochen werden - da der Protokolladapter diese dann wieder in https konvertiert!
Ich bin auf diesen Artikel gestoßen, in dem das Problem des Hinzufügens eines Client-Zertifikats zu einer Proxy-Verbindung behandelt wurde - was möglicherweise eine Lösung darstellt. Erfordert jedoch, dass der Client für die Verwendung eines Proxys konfiguriert ist, gibt es auch Probleme beim Benennen von Dingen und bei der Funktionsweise von Split-DNS. Zugegeben, keine großen Probleme, aber ich dachte, dass das, was ich hier beschreibe, das Muster ist, das von den meisten CDN-Anbietern verwendet wird. Daher erwäge ich derzeit, Apache Traffic Server als Zwischenkomponente zu verwenden. Dies ermöglicht die Verwendung von geteiltem DNS und getrennten SSL-Kanälen zwischen diesen der Client und der Ursprung sowie Client-Zertifikate für die Kommunikation mit dem Ursprungsserver.