Reverse Proxy, Ubuntu 18.04, Let's Encrypt, Nginx und Zammad

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Reverse Proxy, Ubuntu 18.04, Let's Encrypt, Nginx und Zammad

Beitrag von isential gmbh »

Hallo!

Wir möchten intern bei uns eine Webanwendung (Ticketsystem Zammad) bereitstellen. Zammad soll aus dem Internet erreichbar sein. Testweise funktioniert das über HTTP problemlos, im Echtbetrieb soll die Verbindung jedoch über HTTPS erfolgen. Hierzu habe ich viele Fragen, die nicht alle direkt die UTM-Firewall betreffen. Ich werde sie aber hier trotzdem los, in der Hoffnung auf Tipps von den Experten.

Zunächst aber die Umgebung:
  • Ubuntu Server 18.04
  • IP: 192.168.70.206
  • Nginx
  • Let's Encrypt
  • Zammad

    In der Nginx-Konfiguration von Zammad (/etc/nginx/sites-available/zammad.conf)  habe ich in der Sektion "server" die FDQNs angegeben, auf die Nginx reagiert:
    server {

        # replace 'localhost' with your fqdn if you want to use zammad from remote
        server_name support.isential.de www.support.isential.de 192.168.70.206;
        . . .
    }
  • Die IP 192.168.70.206 habe ich auch angegeben, da ansonsten erreichen wir intern den Webserver nicht, da der eingeschaltete Proxy der UTM-Firewall uns davor kommt. Um intern anstelle mit der IP-Adresse die FDQN nutzen zu können, haben wir auf unseren DNS-Server auf dem Domain-Controller (Windows-Server 2012) einen entsprechenden A-Eintrag angelegt:
    Forward-Lookupzone: support.isential.de
    A-Host-Eintrag ohne Name: 192.168.70.206
  • Auf unserem Internetserver haben wir entsprechende DNS-Einträge angelegt, damit der Zugriff auf support.isential.de auf unsere IP-Adresse umgeleitet wird. Zusätzlich haben wir eine Subdomain support.isential.de angelegt, die auf unser IP-Adresse redirected wird. Eine von beiden Einstellungen war für die Installation von Let's Encrypt wichtig, da während der Installation der Domain-Besitzt geprüft wird (Ich muss noch überprüfen, ob man für den Betrieb beide Einstellungen brauch und ob diese zu Problemen führen kann).
  • Auf der UTM-Firewall habe ich den Reverse-Proxy eingerichtet:
    Netzwerkobjekt: webserver-206, IP: 192.168.70.206/32
    ACL-Set – Name: acl-webserver-206
      dstdomain: support.isential.de
      dstdomain: www.support.isential.de
    Sites:
      Domainname: support.isential.de, Servergruppe: server-webserver-206, ACL-Set: acl-webserver-206
      Domainname: www.support.isential.de, Servergruppe: server-webserver-206, ACL-Set: acl-webserver-206
In dieser Konstellation arbeitet Zammad richtig. Nun wollte ich HTTPS aktivieren, womit meine Probleme begannen.

Auf Ubuntu-Server 18.04 hat Let's Encrypt folgendes erstellt:

/letsencrypt/.updated-options-ssl-nginx-conf-digest.txt
/letsencrypt/.updated-ssl-dhparams-pem-digest.txt
/letsencrypt/accounts
/letsencrypt/archive
/letsencrypt/cli.ini
/letsencrypt/csr
/letsencrypt/keys
/letsencrypt/live
/letsencrypt/options-ssl-nginx.conf
/letsencrypt/renewal
/letsencrypt/renewal-hooks
/letsencrypt/ssl-dhparams.pem
/letsencrypt/accounts/acme-v02.api.letsencrypt.org
/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory
/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/0e2f16cf948e5e18a9ee78c0ae157e6e
/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/0e2f16cf948e5e18a9ee78c0ae157e6e/meta.json
/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/0e2f16cf948e5e18a9ee78c0ae157e6e/private_key.json
/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/0e2f16cf948e5e18a9ee78c0ae157e6e/regr.json
/letsencrypt/archive/support.isential.de
/letsencrypt/archive/support.isential.de/cert1.pem
/letsencrypt/archive/support.isential.de/chain1.pem
/letsencrypt/archive/support.isential.de/fullchain1.pem
/letsencrypt/archive/support.isential.de/privkey1.pem
/letsencrypt/csr/0000_csr-certbot.pem
/letsencrypt/keys/0000_key-certbot.pem
/letsencrypt/live/README
/letsencrypt/live/support.isential.de
/letsencrypt/live/support.isential.de/cert.pem
/letsencrypt/live/support.isential.de/chain.pem
/letsencrypt/live/support.isential.de/fullchain.pem
/letsencrypt/live/support.isential.de/privkey.pem
/letsencrypt/live/support.isential.de/README
/letsencrypt/renewal/support.isential.de.conf
/letsencrypt/renewal-hooks/deploy
/letsencrypt/renewal-hooks/post
/letsencrypt/renewal-hooks/pre
Nun liegen einige Zertifikate im PEM-Format vor. Ich weiß allerdings an dieser Stelle nicht, welches Zertifikat ich in die Einstellungen des Reverse-Proxy eintragen soll. Ein paar Versuche waren erfolglos. Entweder meldete der Import "unable to get issuer certificate" oder "Achtung! Dieses Zertifikat enthält keinen privaten Schlüssel und kann nicht als Server-Zertifikat für Applikationen verwendet werden. Wollen Sie wirklich weitermachen?".

Nun meine Fragen:
  1. Welches/welche Zertifikat/e werden benötigt?
  2. Müssen Anpassungen an dem/den Zertifikat/en vorgenommen werden und wenn, welche?
  3. Was bedeutet in den Einstellungen "Zertifikatsbasierte Authentifizierung aktivieren"? Welches CA-Zertifikat ist hier anzugeben?
  4. Wenn man Let's Encrypt verwendet, muss man spätestens alle 90 Tage (frühestens alle 60 Tage) das Zertifikat erneuern. Muss das manuell erfolgen oder kann der Reverse-Proxy gibt es seitens der UTM-Firewall eine entsprechende Funktionalität?
  5. Diese Frage hat mit dem Reverse-Proxy nicht direkt zu tun, aber sie beschäftigt mich trotzdem: Durch meine misslungenen Versuche habe ich bereits einige Zertifikate importiert und auch welche selbst erzeugt, die ich dann widerrufen habe. Nun wird die Liste der Widerrufenden immer größer und unübersichtlicher, ohne dass diese irgend einen Mehrwert hätte. Wie kann ich die Einträge der widerrufenen Zertifikate bereinigen?
Ich weiß es, viele Fragen. Ich bin mir aber sicher, dass dieses Thema auch andere interessiert, daher würde ich mich für eine rege Beteiligung sehr freuen.

Ich bedanke mich im voraus!

LG

René

Christian Beyer
Securepoint
Beiträge: 157
Registriert: Mo 17.11.2008, 21:38
Kontaktdaten:

Beitrag von Christian Beyer »

Hallo René, 


1. Welches/welche Zertifikat/e werden benötigt?

Du benötigst die komplette Kette an CAs. 
Beim Import am besten mit der obersten Ebene Anfangen: 

Root CA
Intermediate CA 1 (Wenn vorhanden)
Intermediate CA 2 (Wenn vorhanden)
und so weiter..

Diese sollten sich in der chain.pem befinden. 

Danach kommt das eigentliche Zertifikat für den Webserver. 
Das liegt hier in cert.pem und privkey.pemvor.
Am besten die Inhalte beider Dateien in eine neue einfugen und diese neue Daten importierst Du anschließen in die UTM.  


2. Müssen Anpassungen an dem/den Zertifikat/en vorgenommen werden und wenn, welche?

Ist schon etwas her das ich mit Let's Encrypt gearbeitet habe aber die Formate sollte passen. 
Am besten nur cert.pem und privkey.pem zusammenführen. Dann gibt es auch keine Warnmeldungen. 


3. Was bedeutet in den Einstellungen "Zertifikatsbasierte Authentifizierung aktivieren"? Welches CA-Zertifikat ist hier anzugeben?

Ist diese Option aktiv muss sich der Client mittels Zertifikat authentifizieren. Ist für diesen Anwendungszweck vermutlich nicht relevant. 


4. Wenn man Let's Encrypt verwendet, muss man spätestens alle 90 Tage (frühestens alle 60 Tage) das Zertifikat erneuern. Muss das manuell erfolgen oder kann der Reverse-Proxy gibt es seitens der UTM-Firewall eine entsprechende Funktionalität?

Aktuell musst Du das Zertifikat noch manuell übertragen. Wir werden dieses Jahr noch eine Möglichkeit bereitstellen Zertifikate automatisch über Let's Encrypt zu beziehen. Hier wird dann die DNS-Challenge verwendet. 


5. Zertifikate löschen

Man kann Zertifikate auch komplett aus dem UTM-System entfernen. 
Wichtig: Man muss die Konsequenzen kennen und verstehen. 

Verwaltet die UTM eine eigene CA wird über die widerrufenden Zertifikate die CRListe generiert. 
Wird nun ein Zertifikat komplett aus der UTM entfernt, wird dieses Zertifikate bei der nächsten CRL-Generierung nicht mehr berücksichtigt. 

Nun zum Vorgehen: 
1. Du erstellt zunächst eine Sicherung deiner UTM-Konfiguration. 
2. Anschließend ermittelst Du die ID des Zertifikates. (WI: Authentifizierung -> Zertifikate -> Zertifikate - Cert ID und auf dem CLI: cert get - Spalte "id")
3. Mit der ID und dem Befehl cert delete cert id $ID kannst Du das Zertifikat komplett löschen. 
4. Konfiguration speichern 

Weitere Informationen und Ergänzungen findest Du im Wiki: https://wiki.securepoint.de/Cert_cli_v11

Beste Grüße
Christian 

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Danke, das hilft mir weiter! Ich versuche, mich in diese spannende und nicht ganz einfache Materie hineinzuknien, so dass für mich jegliche Hilfestellung von großem Wert ist.

DNS-Challenge: Das bedeutet, die Firewall wird ihren eigenen LE-Client mitbringen? Hier gleich noch ein paar Fragen zum Verständnis:
  • Dann brauche ich auf dem Ubuntu-Server kein Let's Encrypt mehr, wenn die Firewall das macht?
  • Wie bekomme dann aber das Zertifikat automatisch auf den Server, wenn die Firewall es erneuert hat? Ich möchte auch im LAN – also hinter der Firewall –, HTTPS verwenden.
    • Soll dafür Ubuntu ein eigenes von der Firewall unabhängiges LE-Zertifikat für die Webanwendung verwalten?
    • Eventuell ein Selbstsigniertes für den internen Gebrauch? Kann der Reverse-Proxy damit umgehen?
  • Muss dann mein Provider die ACMEv2-API unterstützen, damit euer LE-Client die notwendigen DNS-Einträge setzen kann?
Auf jeden Fall hilft mir das weiter und ich kann weiter testen und lernen. Es kann sein, das ich dir/euch wieder auf die Nerven gehe, wenn ich nicht weiterkommen sollte. Das Thema ist schon sehr umfangreich und anspruchsvoll – es macht aber auch viel Spaß.

Schönen Dank und viele Grüße

René

Christian Beyer
Securepoint
Beiträge: 157
Registriert: Mo 17.11.2008, 21:38
Kontaktdaten:

Beitrag von Christian Beyer »

Genau, die UTM wird sich dann um die Let's Encrypt Zertifikate kümmern. 

Am besten bezieht der Server eigene Zertifikate. 
Am besten wird von der Verwendung von selbst signierten Zertifikaten abgesehen. 
Auf dem Server funktioniert es ja bereits mit den Let's Encrypt Zertifikaten. 

Das wird am Ende mit allen DNS-Providern funktionieren. 
Es wird aber einen kleinen Umweg über unseren DynDNService gehen. 
Detaillierte Anleitungen folgen zum Release. 

Beste Grüße

Christian 

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Dankeschön! Dann mache ich es zunächst per Hand und warte, bis ihr soweit seid. Ich freue mich schon darauf!
LG
René

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Hallo Christian,

erst heute kann ich wieder die Arbeit an diesem Thema wiederaufnehmen. Dazu gleich ein paar Fragen:
Christian Beyer hat geschrieben:(...)
Du benötigst die komplette Kette an CAs. 
Beim Import am besten mit der obersten Ebene Anfangen: 

Root CA
Intermediate CA 1 (Wenn vorhanden)
Intermediate CA 2 (Wenn vorhanden)
und so weiter..

Diese sollten sich in der chain.pem befinden. (...)
Wenn ich dich richtig verstanden habe, muss ich "chain.pem" als zusätzliche CA importieren – wir haben bereits eine auf der UTM für die selbstsignierten Zertifikate. Ist das richtig?
Christian Beyer hat geschrieben:(...)
Danach kommt das eigentliche Zertifikat für den Webserver.
Das liegt hier in cert.pem und privkey.pem vor.
Am besten die Inhalte beider Dateien in eine neue einfugen und diese neue Daten importierst Du anschließen in die UTM. (...)
Nun importiere ich die neue, aus cert.pem und privkey.pem manuell erstellte Datei in die UTM.

Wie läuft der HTTPS-Request intern innerhalb des lokalen Netzwerkes ab? – Hier habe ich noch Verständnisschwierigkeiten: Ich habe sowohl die CA als auch das Webzertifikat samt privatem Key importiert. Ich gehe davon aus, dass alle Anfragen aus dem Internet zuerst vom Reverse-Proxy entgegengenommen und danach an den Webserver im LAN weitergeleitet werden. Damit ist der Reverse-Proxy für die Verschlüsselung der Verbindung verantwortlich.

Schleift der Reverse-Proxy die Anfrage aus dem Internet einfach über HTTPS zum Webserver durch und verwendet er dabei dasselbe Webzertifikat?

Für ein paar erklärende Sätze wäre ich dir super dankbar!

LG

René

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Nachtrag:

Die CA-Kette habe von hier manuell erstellt (siehe auch https://letsencrypt.org/de/certificates/):

Root-Zertifikat:
--- https://letsencrypt.org/certs/isrgrootx1.pem.txt

Zwischenzertifikate (Intermediate Certificates):
--- https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt
------ https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt

Ich habe die Root- und Zwischenzertifikate der Reihe nach in eine neue Datei eingefügt und als *.pem gespeichert. Diese habe ich dann als CA importiert.

Das Webzertifikat habe ich wie folgt manuell zusammengestellt:

Die Inhalte von privkey.pem und cert.pem habe ich in eine neue pem-Datei (Webserverzertifikat.pem) eingefügt, dieses in die Firewall importiert und im Revers-Proxy in den Einstellungen als SSL-Zertifikat angegeben.

Nun funktioniert alles, allerdings zeigt mir das Webzertifikat folgendes:
unable to get local issuer certificate
Was bedeutet das?

Nochmals vielen Dank und liebe Grüße

René

Antworten