Letsencrypt Zertifikate für Reverse-Proxy Sites mit Securepoint UTM

Reverse Proxys sind aus mehreren Gründen ziemlich praktisch. Sollen zum Beispiel Webserver aus lokalen Netzwerken für den Zugriff vom Internet verfügbar gemacht werden, kann ein Proxy die Zugriffe filtern und eine gewisse Schutzfunktion darstellen.

Sollen mehrere Server verfügbar gemacht werden, kann das über den Proxy mit einer IP Adresse und dem jeweiligen Standardport des Dienstes passieren. Mit der Alternative Portforwarding ist dies so nicht möglich, da jeweils eine IP/Port Kombination pro Host benötigt wird.

Mittlerweile ist der verschlüsselte Zugriff auf Webseiten Standard. Dazu wird ein Zertifikat benötigt. Damit es im Browser des Anwenders nicht zu Fehlermeldungen, kommt muss dies von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt sein und den voll qualifizierten Hostnamen (FQDN) als CN enthalten. Solche Zertifikate verursachen allerdings oft einiges an Kosten, deshalb sind Alternativen wie https://letsencrypt.org/ sehr beliebt. Natürlich muss vor dem Ausstellen von Zertifikaten sichergestellt werden, das der Antragsteller auch Besitzer der jeweiligen Domain ist, um Missbrauch zu verhindern. Letsencrypt bietet mehrere Möglichkeiten dazu an und stellt nach erfolgreicher Überprüfung Zertifikate mit jeweils 90 Tagen Gültigkeit aus. Um den Aufwand für den Aussteller und die Antragsteller so gering wie möglich zu halten gibt es mehrere Programme oder Scripte, die das nach der Ersteinrichtung automatisch erledigen.

Bei einem Reverse Proxy muss nun das Zertifikat nicht nur auf dem Webserver (für interne Zugriffe), sondern auch auf dem Proxyserver installiert werden. Weiterhin ist es bei einigen Firewallsystemen auch nicht möglich, Scripte oder Programme zur Erneuerung der Zertifikate zu installieren.

In einem konkreten Anwendungsfall sollte im internen Netz eines Kunden ein Mailsystem und eine Nextcloud Installation, jeweils in einer eigenen VM installiert, über den Reverse-Proxy einer Securepoint Firewall im Internet und im LAN zur Verfügung gestellt werden.

Da sich in der Firewall für den Reverse-Proxy nur ein Zertifikat einstellen lässt, wurde ein Zertifikat mit 3 Hostnamen, also in dem Fall cloud.example.org, mail.example.org und zusätzlich gleich noch remote.example.org, für den Zugriff auf die Firewall selbst, benötigt.

Einer der Webserer bekam die Aufgabe, die Zertifikate zu erstellen und per cronjob jeweils zu erneuern. Die Übertragung auf den 2. Webserver erfolgt einfach per Script, in dem dieser sich das von dem anderen Server bei Vorhandensein eines neueren Zertifikates holt. Die Übertragung des Zertifikates auf die Firewall erfolgt vom Administrator aktuell immer noch von Hand, nachdem dieser eine Mail mit dem neuen Zertifikat bekommen hat.

Zur Erstellung der Zertifikate wird als ACME Client das Script „certbot“ genutzt, als Challange zur Authentifizierung „http-01“. Das war nötig, da der HTTPS Port ja bereits durch den Reverse-Proxy belegt ist. Der HTTP Port wird nun per Portforwarding auf den Webserver weitergeleitet. Um die mögliche Angriffsfläche so gering wie möglich zu halten allerdings nur in dem Zeitraum, in dem der cronjob die Erneuerung durchführt.