136423
24.01.2019
3485
10
0
Frage zu SSL Zertifikaten
Liebe Community,
ich hätte eine Frage an euch bezüglich SSL Zertifikaten und interne WebServer. Zum Problem:
Wir haben eine einzelne statische, öffentliche IP, die via PPPoE unserer ASA-Firewall zugewiesen wurde.
In lokalen Netzen dahinter befinden sich nun 2 Webserver, auf die von außen mittels Port-Weiterleitungen zugegriffen werden soll. Zwischen den Webservern befindet sich jeweils ein reverse Proxy im selben Netz, der die Anfragen entsprechend entgegennimmt und weiterleitet. Die Architektur ist folgende:
Outside-Client <=> ASA-Firewall <=> Reverse-Proxy_1 <=> Webserver_1 (Upload-Server)
Outside-Client <=> ASA-Firewall <=> Reverse-Proxy_2 <=> Webserver_2 (Ticket-Server)
Nun zur Umsetzung:
Bei unserem Hosting-Partner wurden jeweils Sub-Domains eingerichtet, welche die Nutzung erleichtern sollen:
upload.domain.de (für WebServer_1)
ticket.domain.de (für WebServer_2)
1. Jeder der beiden Subdomains erhielt als A-Entry die öffentliche IP. Zur Unterscheidung war es demnach notwendig den Aufruf über verschiedene Ports zu tätigen:
http://upload.domain.de:12345
http://ticket.domain.de:23456
2. An der ASA wurden entsprechend PAT/static_NAT Regeln definiert, die den outside-request an den Reverse_Proxy weiterleiten und diese dann an die internen Webserver.
Soweit funktioniert alles so wie gewollt, allerdings möchten wir diese Verbindung nun mit einer TLS/SSL Verschlüsselung sichern.
Als CA nutzen wir letsencrypt, von denen ich gesagt bekommen habe, dass Sie nun sogar als "offizielle Zertifizierungsstelle" eingestuft sind und Browser diese Zertifikate als "trusted" einstufen.
Leider komme ich nun etwas durcheinander WO ich WELCHE Zertifikate einspielen muss. Bisher habe ich am ReverseProxy den Endpunkt auf "https" gestellt und mir mittels letsencrypt ein Zertifikat erstellen lassen. Dieses Zertifikat ist ausgestellt auf die jeweiligen Subdomains (e.g. upload.domain.de). Trotzdem erhalte ich beim Aufruf eine Meldung, dass dieses Zertifikat nicht gültig ist. "CA SSL BAD CERT DOMAIN"
Mach ich etwas falsch oder ist es ein Problem mit dem Browser? Ich bin davon ausgegangen, dass mein "Endpunkt" der ReverseProxy ist und auch dieser das Zertifikat "vorzeigen" muss.
Die Verbindungen gehen ja:
Client <https> ASA (PAT/NAT) <https> ReverseProxy <http> Upload-Server
Hostname des ReverseProxy habe ich auf upload.domain.de gesetzt und den Upload-Server an sich auf einen anderen internen Namen.
Ist vielleicht dies das Problem? Dass der RevProxy selber die Verbindungen nur weitergibt und der RevProxy einen internen Namen erhalten muss und der Upload-Server den öffentlichen (upload.domain.de)?
Braucht der Upload-Server vielleicht auch noch ein SSL Zertifikat? Leider unterstützt das OpenSource Programm dies nicht und diese Verbindungen wären ja auch "nur" innerhalb unseres Netzes.
Mit besten Grüßen,
niLuxx
ich hätte eine Frage an euch bezüglich SSL Zertifikaten und interne WebServer. Zum Problem:
Wir haben eine einzelne statische, öffentliche IP, die via PPPoE unserer ASA-Firewall zugewiesen wurde.
In lokalen Netzen dahinter befinden sich nun 2 Webserver, auf die von außen mittels Port-Weiterleitungen zugegriffen werden soll. Zwischen den Webservern befindet sich jeweils ein reverse Proxy im selben Netz, der die Anfragen entsprechend entgegennimmt und weiterleitet. Die Architektur ist folgende:
Outside-Client <=> ASA-Firewall <=> Reverse-Proxy_1 <=> Webserver_1 (Upload-Server)
Outside-Client <=> ASA-Firewall <=> Reverse-Proxy_2 <=> Webserver_2 (Ticket-Server)
Nun zur Umsetzung:
Bei unserem Hosting-Partner wurden jeweils Sub-Domains eingerichtet, welche die Nutzung erleichtern sollen:
upload.domain.de (für WebServer_1)
ticket.domain.de (für WebServer_2)
1. Jeder der beiden Subdomains erhielt als A-Entry die öffentliche IP. Zur Unterscheidung war es demnach notwendig den Aufruf über verschiedene Ports zu tätigen:
http://upload.domain.de:12345
http://ticket.domain.de:23456
2. An der ASA wurden entsprechend PAT/static_NAT Regeln definiert, die den outside-request an den Reverse_Proxy weiterleiten und diese dann an die internen Webserver.
Soweit funktioniert alles so wie gewollt, allerdings möchten wir diese Verbindung nun mit einer TLS/SSL Verschlüsselung sichern.
Als CA nutzen wir letsencrypt, von denen ich gesagt bekommen habe, dass Sie nun sogar als "offizielle Zertifizierungsstelle" eingestuft sind und Browser diese Zertifikate als "trusted" einstufen.
Leider komme ich nun etwas durcheinander WO ich WELCHE Zertifikate einspielen muss. Bisher habe ich am ReverseProxy den Endpunkt auf "https" gestellt und mir mittels letsencrypt ein Zertifikat erstellen lassen. Dieses Zertifikat ist ausgestellt auf die jeweiligen Subdomains (e.g. upload.domain.de). Trotzdem erhalte ich beim Aufruf eine Meldung, dass dieses Zertifikat nicht gültig ist. "CA SSL BAD CERT DOMAIN"
Mach ich etwas falsch oder ist es ein Problem mit dem Browser? Ich bin davon ausgegangen, dass mein "Endpunkt" der ReverseProxy ist und auch dieser das Zertifikat "vorzeigen" muss.
Die Verbindungen gehen ja:
Client <https> ASA (PAT/NAT) <https> ReverseProxy <http> Upload-Server
Hostname des ReverseProxy habe ich auf upload.domain.de gesetzt und den Upload-Server an sich auf einen anderen internen Namen.
Ist vielleicht dies das Problem? Dass der RevProxy selber die Verbindungen nur weitergibt und der RevProxy einen internen Namen erhalten muss und der Upload-Server den öffentlichen (upload.domain.de)?
Braucht der Upload-Server vielleicht auch noch ein SSL Zertifikat? Leider unterstützt das OpenSource Programm dies nicht und diese Verbindungen wären ja auch "nur" innerhalb unseres Netzes.
Mit besten Grüßen,
niLuxx
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 399262
Url: https://administrator.de/contentid/399262
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
mal eine grundsätzliche Frage.
Warum machst Du es Dir so umständlich.
Typische wäre, dass man einen RP hat der auf beide Web-Server weiterleitet.
Dann fällt das Problem mit den Ports auch komplett weg.
LE und andere Zertifizierungsstellen stellen nur Zertifikate für Web-Server aus die auf 80/443 laufen.
Dieser eine RP kann dann auch als SSL Offloader agieren.
Zertifikate wäre dann nur hier und er leitet intern auf die Ports 80 der Webserver weiter.
Stefan
mal eine grundsätzliche Frage.
Warum machst Du es Dir so umständlich.
Typische wäre, dass man einen RP hat der auf beide Web-Server weiterleitet.
Dann fällt das Problem mit den Ports auch komplett weg.
LE und andere Zertifizierungsstellen stellen nur Zertifikate für Web-Server aus die auf 80/443 laufen.
Dieser eine RP kann dann auch als SSL Offloader agieren.
Zertifikate wäre dann nur hier und er leitet intern auf die Ports 80 der Webserver weiter.
Stefan
Hi,
E.
Zitat von @StefanKittel:
LE und andere Zertifizierungsstellen stellen nur Zertifikate für Web-Server aus die auf 80/443 laufen.
Zerifikat auf Port eingeschränkt?!LE und andere Zertifizierungsstellen stellen nur Zertifikate für Web-Server aus die auf 80/443 laufen.
E.
Hallo Stefan,
Danke für deine Antwort. Dass mit dem einzelnen ReverseProxy werde ich berücksichtigen und so umsetzen.
Wegen dem Port 443, ja das ist so eine Sache...Leider wird der Port 443 bei unserer ASA durch das öffentliche WebInterface der ASA blockiert (e.g. zum Download des VPN clients). Ich hatte das Letsencrypt Zertifikat ursprünglich über Port 80 erstellt (laut Anleitung ist das auch ok) und danach wieder auf 12345 umgestellt. Die ASA leitet diesen outside-port allerdings an die 443 am ReverseProxy weiter. Keine Ahnung ob das so funktioniert, aber ich befürchte, etwas anderes bleibt mir gar nicht übrig
Aber du bist auch der Meinung, dass nur der RevProxy das Zertifikat innehalten muss? Die Verbindung RevProxy <=> Upload-Server kann auf http bleiben?
Und es ist auch richtig, dass der RevProxy mit der Subdomain benannt werden muss? Nicht der Upload-Server selbst?
Grüße
niLuxx
Danke für deine Antwort. Dass mit dem einzelnen ReverseProxy werde ich berücksichtigen und so umsetzen.
Wegen dem Port 443, ja das ist so eine Sache...Leider wird der Port 443 bei unserer ASA durch das öffentliche WebInterface der ASA blockiert (e.g. zum Download des VPN clients). Ich hatte das Letsencrypt Zertifikat ursprünglich über Port 80 erstellt (laut Anleitung ist das auch ok) und danach wieder auf 12345 umgestellt. Die ASA leitet diesen outside-port allerdings an die 443 am ReverseProxy weiter. Keine Ahnung ob das so funktioniert, aber ich befürchte, etwas anderes bleibt mir gar nicht übrig
Aber du bist auch der Meinung, dass nur der RevProxy das Zertifikat innehalten muss? Die Verbindung RevProxy <=> Upload-Server kann auf http bleiben?
Und es ist auch richtig, dass der RevProxy mit der Subdomain benannt werden muss? Nicht der Upload-Server selbst?
Grüße
niLuxx
Moin,
LE-Zertifikate müssen alle 3 Monate verlängert werden.
Dann muss Du dazu immer den Port umstellen. Viel Spass.
Der RP muss ja nur wissen welchen Hostnamen (egal ob Domäne oder Subdomäne) er an welchen Web-Server weiterleiten soll.
Stefan
LE-Zertifikate müssen alle 3 Monate verlängert werden.
Dann muss Du dazu immer den Port umstellen. Viel Spass.
Der RP muss ja nur wissen welchen Hostnamen (egal ob Domäne oder Subdomäne) er an welchen Web-Server weiterleiten soll.
Stefan
Dann hieße das aber letztlich, dass der Upload-Server den hostnamen "upload.domain.de" erhält und nicht der reverseproxy?
Liebe Grüße
niLuxx
Liebe Grüße
niLuxx
Zitat von @136423:
Dann hieße das aber letztlich, dass der Upload-Server den hostnamen "upload.domain.de" erhält und nicht der reverseproxy?
Das kann man so und so machen Dann hieße das aber letztlich, dass der Upload-Server den hostnamen "upload.domain.de" erhält und nicht der reverseproxy?
Der RP muss wissen welche Hostnamen/URLs er an welchen Server weiterleitet.
z.B.
https://upload.firma.de -> RP -> http://upload.firma.de
Aber es geht auch
https://upload.firma.de -> RP -> http://web1.firma.de/upload
Ich würde es immer gleich machen damit es übersichtlicher ist.
Und wenn Du Port 80 auch über den RP laufen lässt, bekommst Du auch keine probleme mit den LE-Zertifikaten.
Stefan
Zitat von @emeriks:
Schonmal einen Port in ein CSR geschrieben?Zitat von @StefanKittel:
LE und andere Zertifizierungsstellen stellen nur Zertifikate für Web-Server aus die auf 80/443 laufen.
Zerifikat auf Port eingeschränkt?!LE und andere Zertifizierungsstellen stellen nur Zertifikate für Web-Server aus die auf 80/443 laufen.
z.B. https://upload.firma.de:8443
Er versucht dann trotzdem von https://upload.firma.de:443 die Datei zu laden und fällt auf die Nase.
z.B.
https://upload.firma.de -> RP -> http://upload.firma.de
Aber es geht auch
https://upload.firma.de -> RP -> http://web1.firma.de/upload
https://upload.firma.de -> RP -> http://upload.firma.de
Aber es geht auch
https://upload.firma.de -> RP -> http://web1.firma.de/upload
Für welchen Server müsste das Zertifikat dann aber registriert werden in beidenFällen?
Variante 1 => upload.firma.de ?
Variante 2 => web1.firma.de ?
Das hieße dann also:
ASA => kein Zertifikat da nur weitergeleitet wird
RP => SSL Zertifikat für dahinterliegenden WebServer, selbst wenn RP die Verbindung nur weitergibt
WebServer => kein Zertifikat
Ich verwende das Apache2 Paket als RP und dort muss ich einen VirtualHost angeben. Ich dachte immer, dass hier der Name der SubDomain rein muss.
<VirtualHost upload.domain.de:443>
...
ProxyPass / http://<Webserver>domain.de:80/
ProxyPassReverse / http://<Webserver>domain.de:80/
...
</VirtualHost>Die ASA leitet dann Anfragen auf 8443 (outside) zur 443 (RP) weiter.
Zitat von @136423:
Das hieße dann also:
ASA => kein Zertifikat da nur weitergeleitet wird
jaDas hieße dann also:
ASA => kein Zertifikat da nur weitergeleitet wird
RP => SSL Zertifikat für dahinterliegenden WebServer, selbst wenn RP die Verbindung nur weitergibt
ja, die Verbindung endet hier ja. Der RP baut dann eine 2. Verbindung zum Webserver auf und gibt die Antwort zurück.Das ist der Unterschied zur Portweiterleitung.
WebServer => kein Zertifikat
JaIch verwende das Apache2 Paket als RP und dort muss ich einen VirtualHost angeben. Ich dachte immer, dass hier der Name der SubDomain rein muss.
Ich würde nginx dafür verwendet.
Der kann das, meiner Meinung nachm besser und einfacher.
Siehe
https://www.nginx.com/blog/nginx-ssl/
Stefan
Hallo
nur zum Verständnis für niLuxx:
Auf deinem RP wo du dann i.dr 2 vhosts angelegt hast mit den aufzurufenden Domains, und dann LE verwendest, interaktiv, dann wirst du gefragt für welchen vhost du eins anfordern willst.
Du hast dann mehrere Zertifikate auf deinem RP
Ich kenn die ASA nicht, keine Ahnung wie die das handhabt,bestimmt clicky bunty, aber das sollte genauso funktionieren.
edit
lese grade Apache2 Paket.. dann funktioniert das so wie oben geschrieben.
nur zum Verständnis für niLuxx:
Auf deinem RP wo du dann i.dr 2 vhosts angelegt hast mit den aufzurufenden Domains, und dann LE verwendest, interaktiv, dann wirst du gefragt für welchen vhost du eins anfordern willst.
Du hast dann mehrere Zertifikate auf deinem RP
Ich kenn die ASA nicht, keine Ahnung wie die das handhabt,bestimmt clicky bunty, aber das sollte genauso funktionieren.
edit
lese grade Apache2 Paket.. dann funktioniert das so wie oben geschrieben.
