Zugriff auf Server hinter einem Nginx Reverse Proxy aus internem Netz

Besonderes Thema: Zugriff vom Internen Netzwerk auf den "Server"

Der Zugriff auf einen Server hinter einem RProxy übers Internet funktioniert gut. Die Zertifikate verwaltet der Nginx Reverse Proxy.

Problem tritt auf, wenn man auch aus dem internen Netz auf den "Server" zugreifen will. der Zugriff erfolgt dann ja nicht über den Reverse Proxy sondern direkt. Die evtl. bei der Grundeinrichtung erzeugten Letsencrypt Zertifikate werden nicht automatisch erneuert bzw. überhautp nicht erzeugt.

Abhilfe mit Hilfe eines Scripts, welches die Letsencrypt Zertifikate vom Reverse Proxserver auf den lokalen Server holen. Dazu zuerst einen per SSH-Key abgesicherten Zugang vom "Server" auf den Reverse Proxy einrichten, damit man später per script die auf dem Reverse Proxy abgelegten Zertifikate auf den lokalen "Server" kopieren kann. Zuvor ist der SSH Zugang für Root freizuschalten (/etc/ssh/sshd.conf)

Im diesem Beispiel hat der nginx Proxyserver die IP Adresse 192.168.50.8 (Fa. Ströhle) und die Zertifakte liegen unter /npm

ssh-keygen -t rsa
ssh-copy-id root@192.168.50.8

Nachfolgend beispielhaft solch ein Script für einen Kerioserver. In diesem Beispiel liegen die für den Kerio Server erzeugten Letsencrypt Zertifikate unter /npm/letsencrypt/live/npm-1 auf dem Reverse Proxy Server (IP=192.168.50.8). (Ströhle)

Script für einen Kerio Server

Diese Script holt das aktuelle Zertifikat vom Reversproxy Server und spielt es in die lokale Installation ein. Hintergrund: Portforwarding von Port 80 und 443 laufen auf den Reversproxy Server. Folglich kann nur dieser per Letsencrypt Zertifikate erneuern, die er stellvertretend auch für nachgeschaltet Server macht. Für externen Zugriff wäre das schon ausreichend. Für den internen Zugriff, der ja direkt auf den Server erfolgt muss das Zertikat in irgend einer Weise vom Proxy Server übertragen werden. Sonst hat der interne Server irgendwann nur noch ein veraltetes Zertifikat und es kommen entsprechende Fehlermeldung beim Zugriff per Webbrowser. (wie gesagt es geht um den Zugriff vom internen Netz)

#! /bin/sh
scp root@192.168.50.8:/npm/letsencrypt/live/npm-1/privkey.pem /opt/kerio/mailserver/sslcert/server.key
scp root@192.168.50.8:/npm/letsencrypt/live/npm-1/fullchain.pem /opt/kerio/mailserver/sslcert/server.crt
service kerio-connect restart

Anpassungen in der Crontab Tabelle

3 3 * * * /usr/local/bin/cp-le-certs.sh > /dev/null 2>&1

Nachfolgend beispielhaft solch ein Script für einen Nextcloudserver. In diesem Beispiel liegen die für den Nextcloud Server erzeugten Letsencrypt Zertifikate unter /npm/letsencrypt/live/npm-2 auf dem Reverse Proxy Server (IP=192.168.50.8). (Bsp. Ströhle)

Script für einen Nextcloud Server

Dieses Script holt das aktuelle Zertifiakt vom Reversproxy Server und spielt es in die lokale Installation ein. Hintergrund: Portforwarding von Port 80 und 443 laufen auf den Reversproxy Server. Folglich kann nur dieser per Letsencrypt Zertifikate erneuern, die er stellvertretend auch für nachgeschaltet Server macht. Für externen Zugriff wäre das schon ausreichend. Für den internen Zugriff, der ja direkt auf den Server erfolgt muss das Zertikat in irgend einer Weise vom Proxy Server übertragen werden. Sonst hat der interne Server irgendwann nur noch ein veraltetes Zertifikat und es kommen entsprechende Fehlermeldung beim Zugriff per Webbrowser. (wie gesagt es geht um den Zugriff vom internen Netz)

#! /bin/sh
scp root@192.168.50.8:/npm/letsencrypt/live/npm-3/*.pem /etc/letsencrypt/live/nextcloud.stroehle-elektrik.de
/etc/init.d/apache2 restart

Anpassungen in der Crontab Tabelle

3 3 * * * /usr/local/bin/cp-le-certs.sh > /dev/null 2>&1