Nginx Proxy Manager zu Nginx Proxy Manager

[thron]

Hallo zusammen,

ich habe ein Problem und komme an der Stelle nicht weiter.
Ich habe zwei Server mit jeweils einem Nginx-Proxy-Manager als Docker Container laufen (NginxProxyMngr1 - 192.168.0.100) und (NginxProxyMngr2- 192.168.1.100). Beide NginxProxyMngr haben das gleiche Zertifikat (Kette) und den Private Key in diesem Fall ein Wildcardzertifikat *.subdomain.domain.net (Eigene PKI in einem Firmennetz).

Jetzt habe ich folgenden Anwendungsfall:

Client --- https ----> NginxProxyMngr1 ------ https -----> NginxProxyMngr2 --- http ---> Docker Webservice.

Wenn ich dieses Konstrukt so aufbaue und konfguriere bekomme ich einen 502 Bad Gateway zurück! Wenn ich zwischen den NginxProxyMngr1 und NginxProxyMngr2 http statt https nehme funktioniert es!

Konfiguriert ist der NginxProxyMngr1 so, dass er https annimmt und an den NginxProxyMngr2 (192.168.1.100:443) weiterleitet. Ich gehe davon aus, dass die Url mittransportiert wird. Der NginxProxyMngr2 leitete die Anfrage dann wieder per http an den internen Docker Container 172.17.10.100 weiter.

Kann mir evtl. jemand helfen, was ich falsch mache?

Vielen Dank und Grüße

 

[h00bi]

bekomme ich einen 502 Bad Gateway zurück!

von welchem npm kommt das zurück? 1 oder 2?

 

[tdbr]

Gibt es mehr Infos in den Logs?
Header Probleme?

Läuft hier NPM in einem Firmennetz? Das Ding ist ein Hobbyprojekt. Dann lieber traefik.

 

[thron]

Hallo,

habe mal geschaut un der npm1 gibt folgenden Error zurück:

2024/02/07 07:58:44 [crit] 2296#2296: *7032 SSL_do_handshake() failed (SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:SSL alert number 112) while SSL handshaking to upstream, client: 192.168.178.150, server: ferien.subdomain.domain.net , request: "GET / HTTP/2.0", upstream: "https://192.168.1.100:443/", host: "ferien.subdomain.domain.net", referrer: "https://nginxprm.subdomain.domain.net/"

2024/02/07 07:58:45 [crit] 2296#2296: *7032 SSL_do_handshake() failed (SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:SSL alert number 112) while SSL handshaking to upstream, client: 192.168.178.150, server: ferien.subdomain.domain.net , request: "GET / HTTP/2.0", upstream: "https://192.168.1.100:443/", host: "ferien.subdomain.domain.net", referrer: "https://nginxprm.subdomain.domain.net/"


@tdbr : Du hast Recht mir dem NPM und dem traefik. Nur ist der traefik für manch Kollegen einfach zu schwer und sie haben keine GUI zum konfigurieren! Deshalb NPM

 

[thron]

Keiner eine Idee?

 

[dms]

unrecognized name:SSL alert number 112

an der Meldung wolltest du nicht ansetzen?

 

[thron]

Will ich! Aber ich verstehe es nicht und komme nicht weiter! Warum kommt Bad Gateway 502?

Die Zertifikate sind zweimal die Gleichen und der gleiche Private Key. Warum der SSL Fehler?

 

[oicfar]

Option 1:
Hier https://github.com/NginxProxyManager/nginx-proxy-manager/discussions/categories/general mal fragen. Wieso nicht schon am Anfang gemacht?

Ergänzung (8. Februar 2024)

Eigene PKI in einem Firmennetz

Option 2:
Einen IT-Berater zur Rat ziehen. Kostet dann auch was.

 

[sandreas]

Ich denke, dass du den ersten Proxy so konfiguriert hast, dass er auf die IP des zweiten und nicht den DNS-Namen weiter leitet und dadurch das Wildcard-Zertifikat nicht vertrauenswürdig ist. Das quittiert der zweite Server dann mit: Achtung, du hast hier was angefordert, wo das Zertifikat nicht stimmt und der erste sagt: Nee du, das ist "Bad Gateway". Im Browser könnte man "Trotzdem anzeigen" wählen, aber der Proxy sagt halt standardmäßig: Nee, is nicht.

Das würde dann auch erklären, warum es mit http funktioniert, da er dann keine Zertifikatsprüfung macht.

Lösungsansatz: Du könntest dir mal genauer anschauen, was server1 an server2 so weiter gibt (z.B. mit Wireshark). Ich vermute, dass keine Forwarded-Header mit gesendet werden, damit könnte man den zweiten Proxy eventuell dazu bewegen, das Zertifikat für diese IP zu akzeptieren. Oder du könntest das Zerftikat einfach "installieren" und als vertrauenswürdig markieren.
Eventuell reicht auch schon die weiterleitung per DNS statt IP.