LetsEncrypt auf PFSense mit nsupdate
-
Hallo zusammen,
ich versuche mich gerade in LetsEncrypt einzulesen um es auf der PFSense für den Reverse-Proxy zu nutzen.
Mir ist bisher jedoch noch nicht klar ob es so wie ich es vorhabe überhaupt funktioniert. Auf dem externen Webserver der bei All-Inkl gemietet ist werden die Domains gehostet, Mail-Accounts angelegt etc. Auf dem Server kann ich auch DNS-Einträge setzen etc.
Dort habe ich auch zum testen einfach mal das SSL-Zertifikat für eine Domain erzeugen lassen und diese funktionieren auch.
Das Zertifikat stellt sich im Backend von All-Inkl wie folgt dar (Inhalt natürlich verändert)
++ CRT information ++ Common name [CN] mydomain.de Certificate issued to mydomain.de, www.mydomain.de valid 2019-12-17 till 2020-03-16 (will expire in 78 days, will be automatically renewed) SHA1 fingerprint xx:cc:vv:bb:nn:mm:qq:ww:ee:rr:tt:zz:uu:ii:oo:pp:aa:ss:dd:ff Key strength 2048 bit Signature algorithm sha256WithRSAEncryption Issuer: Let's Encrypt, Let's Encrypt Authority X3 ++ Intermediate certificate information ++ SSL certificate #1: Let's Encrypt, Let's Encrypt Authority X3 Issuer: Digital Signature Trust Co., DST Root CA X3 ++ Certificate information for Apache/mod_ssl ++ CSR: -----BEGIN CERTIFICATE REQUEST----- xxxvieleZeichenxxxxxxvieleZeichenxxxxxxvieleZeichenxxx ... xxxvieleZeichenxxxxxxvieleZeichenxxxxxxvieleZeichenxxx -----END CERTIFICATE REQUEST----- KEY: -----BEGIN PRIVATE KEY----- xxxvieleZeichenxxxxxxvieleZeichenxxxxxxvieleZeichenxxx ... xxxvieleZeichenxxxxxxvieleZeichenxxxxxxvieleZeichenxxx -----END PRIVATE KEY----- KEY passphrase: [Leer] CRT: -----BEGIN CERTIFICATE----- xxxvieleZeichenxxxxxxvieleZeichenxxxxxxvieleZeichenxxx ... xxxvieleZeichenxxxxxxvieleZeichenxxxxxxvieleZeichenxxx -----END CERTIFICATE----- Intermediate certificates: -----BEGIN CERTIFICATE----- xxxvieleZeichenxxxxxxvieleZeichenxxxxxxvieleZeichenxxx ... xxxvieleZeichenxxxxxxvieleZeichenxxxxxxvieleZeichenxxx -----END CERTIFICATE-----Nun, das ist ja das Zertifikat für: mydomain.de, www.mydomain.de
Mein PFSense steht ja hier in der Wohnung, verfügt über eine feste WAN-IP (IPv4) und stellt das Gateway ins Internet dar. Über den Reverse-Proxy sollen später zwei verschiedene Server-VM's anhand der aufgerufenen Subdomain auf Port 443 angesprochen werden:
gw.mydomain.de -> Server-VM1 (Groupware)
cloud.mydomain.de -> Server-VM2 (Cloud)Auf dem Webserver setze ich einen entsprechenden Record damit diese beiden Subdomains auf die feste WAN-IP der lokalen PFSense zeigen.
Auf den Server-VM's können ja die selbst-signierten Zertifikate bleiben da der externe Nutzer ja mit der PFSense "kommuniziert"
Wenn ich alles richtig verstanden habe muss ich auf der PFSense nun mittels acme für diese beiden Subdomains jeweils ein Zertifikat erzeugen. Um in PFSense die "nsupdate Methode" zur Aktualisierung nutzen zu können - was ja automatisch geschehen soll - muss auf dem externen Webserver ja ein TXT-Record:
_acme-challenge.<domain name>angelegt werden welcher den Challenge enthält der sich ja jedes mal ändert. Den TXT-Record anzulegen ist ja nicht das Problem aber der ändert sich ja und damit acme diesen über nsupdate aktualisieren kann muss ja ein API-Zugang vorhanden sein. Bei All-Inkl auf der Homepage habe ich nichts gefunden. Werde auch noch per Mail dort nachfragen aber kann man mit den o.g. Keys (die ja zu mydomain.de, www.mydomain.de und nicht zu gw.mydomain.de, cloud.mydomain.de gehören) dieses Update ausführen bzw. ist dass aufgrund der vorhanden SSL-Infos ersichtlich?
Viele Grüße
sven -
Ich vermute sowas würde man über ein Wildcard-Zertifikat abhandeln. Dafür ist die DNS- Challenge erforderlich, deinen Anbieter finde ich aber nicht aufgeführt.
Du könntest u.U. dein DNS bei einem anderen Anbieter verwalten, wenn All-Inkl das nicht verbietet. -
Mir ist leider kein Hoster bekannt, der eine der automatischen DNS-Methoden untertützt. Deshalb hab ich es bei meinem Setup mittels "Webroot FTP" gelöst, da ich ohnehin einen Linux-Web-Server einsetze. Den Reverse-Proxy (HA-Proxy) habe ich dann so konfiguriert, dass beim Aufruf einer beliebigen URL/Domäne, die im Pfad mit "/acme-challenge/" beginnt immer dorthin zeigt, wo die Prüfdatei hochgeladen wurde.
Dieses Verfahren funktioniert derzeit allerdings nicht mit Wildcards. Ansonsten verwende ich dieses Setup jetzt seit mehr als zwei Jahren ohne das es jemals einen einzigen Fehler gab. Auch die automatische Erneuerung der Zertifikate funktioniert problemlos.
-
Ich habe von All-Inkl folgende Antwort erhalten:
*der _acme-challenge kann nur bei LetsEncypt Zertifikaten genutzt werden, die über das Kas eingebunden werden. Und das wiederum sind ausschließlich Domains, die entweder auf dem Kasserver liegen oder zu diesem per A-Record gelenkt werden.
Für alle anderen Domains geht LetsEncrypt nicht zu nutzen. Hier muss ein inhabervalidiertes Zertifikat verwendet werden. Bei uns kosten diese Zertifikate 99 Euro pro Jahr bzw. 159,- wenn sie für zwei Jahre gebucht werden.*
Ich vesrehe es so dass das automatische Update des _acme-challenge mittels nsupdate nur auf dem Webserver (Kasserver) bei All-Inkl funktioniert und dies nicht von einem externen Host aus erlaubt ist. Dann wird wohl lediglich die Webroot-Methode bleiben.
@inciter said in LetsEncrypt auf PFSense mit nsupdate:
Deshalb hab ich es bei meinem Setup mittels "Webroot FTP" gelöst, da ich ohnehin einen Linux-Web-Server einsetze. Den Reverse-Proxy (HA-Proxy) habe ich dann so konfiguriert, dass beim Aufruf einer beliebigen URL/Domäne, die im Pfad mit "/acme-challenge/" beginnt immer dorthin zeigt, wo die Prüfdatei hochgeladen wurde.
Der Linux-Webserver wird dann aber hier im lokalen LAN positioniert, oder? Das wäre nicht das Problem diesen zu installieren.
Kenn jemand eine gutes How-To welches die Einrichtung von "Webroot FTP" beschreibt?
-
Es ist sogar möglich, den FTP extern zu nutzen - in deinem Fall bei All-Inkl. Allerdings unterstützt die Verifikation kein SSL (SFTP oder FTP-S). Dann wäre es aus Sicherheitsgründen sinnvoll, einen separaten FTP-User einzurichten, der nur Zugriff auf einen bestimmen Unterordner hat. Im Reverse-Proxy konfigurierst du dann eine Weiterleitung die ACME an die richtige Stelle führt.
Schau dir das hier mal an:
https://sysadms.de/2018/10/pfsense-haproxy-als-reverse-proxy/Sehr gutes Video (etwas anstregend erklährt):
https://www.youtube.com/watch?v=aG3gmlQsfnw -
Wie sieht es denn damit aus, einfach einen externen DNS-Anbieter zu nutzen wie z.B.Cloudflare. Ist das mit besagten Tarifen/Anbietern nicht möglich? Bin tatsächlich ahnungslos.
-
@Bob-Dig said in LetsEncrypt auf PFSense mit nsupdate:
Wie sieht es denn damit aus, einfach einen externen DNS-Anbieter zu nutzen wie z.B.Cloudflare. Ist das mit besagten Tarifen/Anbietern nicht möglich? Bin tatsächlich ahnungslos.
Könnte man machen. ACME bietet eine Option für Cloudflare.
-
@inciter Aber erlauben das irgendwelche (Billig-)Hosting-Tarife auch, das ist die Frage.
-
@Bob-Dig said in LetsEncrypt auf PFSense mit nsupdate:
@inciter Aber erlauben das irgendwelche (Billig-)Hosting-Tarife auch, das ist die Frage.
Naja, du musst die Verwaltung der Domäne nur an Cloudflare übergeben - oder anders gesagt, die Domäne zu Cloudflare umziehen. Der DNS-Eintrag der Domain muss dann auf deinen All-Inkl-Webspace zeigen. Und die DNS-Einstellungen der Subdomains konfigurierst du dann ebenfalls bei Cloudflare.
Ich möchte hier auch meinen Vorbehalt ausdrücken. (1.) Ich habe die ACME-Cloudflare-Option nie genutzt und kann nicht sagen, wie gut oder schlecht das funktioniert. (2.) Die meisten Provider setzen bei günstigen Paketen ebenfalls Reverse-Proxies ein. Wenn du deine Domäne von All-Inkl wegziehst, kann es sein, dass du hier spezielle Konfigurationen vornehmen musst. Bei manchen Provider nennt sich das "Virtuelle Domains", damit der Reverse-Proxy von All-Inkl mit der Domäne noch was anfangen kann und an den richtigen Server weiter leitet.
Alternativ könntest du auch einfach eine weitere Domain für deine Home-Services direkt über Cloudflare registrieren.
-
@inciter said in LetsEncrypt auf PFSense mit nsupdate:
Sehr gutes Video (etwas anstregend erklährt):
Ja, "anstrengend" ist noch untertrieben :-)
Ich versuche für mich den Weg mal zu skizzieren:
- Meine feste IP (WAN) am PFSense-Gateway ist; 10.20.30.40
- Meine bei AllInkl gehostet Domain ist mydomain.de
- Meine interne (LAN) Domain ist: intern.local
Folgende Dienste im LAN (hinter PFSense) möchte ich per HTTPS von extern erreichen und dabei soll eine vertrauenswürdige SSL-Verbindung (mittels LetsEncrypt) genutzt werden und die Weiterleitung anhand der URL (gw oder cloud) auf den entsprechenden internen Server (VM) weitergeleitet werden. Das macht ja HA-Proxy.
- (Groupware): gw.mydomain.de -> 192.168.24.6
- (Cloud): cloud.mydomain.de -> 192.168.24.11
Für die acme-challenge habe ich unächst im intern LAN einen Webserver als VM. Die VM habe ich mit Ubuntu Server 18.04.3 LTS installiert. Dieser hat die IP 192.168.24.7 und den FQH: web01.intern.local
Nach der Installation des Apaches läuft dieser ja bereits auf Port 80 und stellt den Inhalt von:
/var/www/htmldar. Hier lege ich nun Pfad:
/var/www/html/.well-known/acme-challengean, und definiere einen gesonderten Benutzer der darauf zugreifen darf welcher später am PFSense in der Webroot FTP Konfig angegeben wird.
Ist das der richtige Anfang? Dieser acme-challenge läuft immer unverschlüsselt über Port 80 oder kann man dies auch sicherer gestalten?
Nachtrag: Ich glaube ich bin da flasch. Ich brauche kein Webserver sondern einen FTP-Server auf der internen VM, richtig?
-
Also. Ich habe nun wie gesagt ein VM mit Ubuntu-Server 18.04 LTS im internen LAN installiert und darauf einen FTP-Server (vsftpd) installiert. Ebenfalls habe ich für den FTP-Server einen gesonderten Benutzer (webftp) angelegt und den Zugriff auf SFTP beschränkt. Mittel FileZilla kann ich mich nun per SFTP und dem besagten Benutzer anmelden und lande in:
/home/webftpDort wiederum gibt es den das Unterverzeichnis für die acme-challenge, also:
webftp@web01:~/.well-known/acme-challengeMit dem User webftp kann ich auch in das Verzeichnis schreiben.
Bevor ich jetzt anfange acme einzurichten Im Video zur Installation sehe ich dass in der Konfiguration vom acme eben diese Verbindungsdaten (Server, Benutzer, Passwort, Pfad) bei Verwendung "webroot FTP" eingetragen werden. Vom Internet aus muss dieses Verzeichnis doch auch zugänglich sein, oder?
-
ich habe nun in acme einen Account-Key aktiviert und ein Zertifikat angelegt:
Name: gw.gehr-edv.de * Domain SAN List * Domainname: gw.gehr-edv.de Method: webroot FTP [Zugangsdaten zum internen FTP-Server]Wenn ich allerdings auf Issue/Renew klicke erhalte ich die Meldung:
gw.mydomain.de Renewing certificate account: gateway01 server: letsencrypt-production-2 /usr/local/pkg/acme/acme.sh --issue -d 'gw.mydomain.de' --webroot pfSenseacme --home '/tmp/acme/gw.mydomain.de/' --accountconf '/tmp/acme/gw.mydomain.de/accountconf.conf' --force --reloadCmd '/tmp/acme/gw.mydomain.de/reloadcmd.sh' --log-level 3 --log '/tmp/acme/gw.mydomain.de/acme_issuecert.log' Array ( [path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/ [PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/ [ftpserver] => web01.intern.local [username] => webftp [password] => geheim [folder] => /home/webftp/.well-known/acme-challenge ) [Sat Jan 4 16:51:57 CET 2020] Single domain='gw.mydomain.de' [Sat Jan 4 16:51:57 CET 2020] Getting domain auth token for each domain [Sat Jan 4 16:51:59 CET 2020] Getting webroot for domain='gw.mydomain.de' [Sat Jan 4 16:52:00 CET 2020] Verifying: gw.mydomain.de [Sat Jan 4 16:52:00 CET 2020] Found domain http api file: /tmp/acme/gw.mydomain.de//httpapi/pfSenseacme.sh challenge_response_put gw.mydomain.de, gw.mydomain.de FOUND domainitemFTP FTP Attempt Failed: Could not connect with to on port . [Sat Jan 4 16:52:03 CET 2020] Found domain http api file: /tmp/acme/gw.mydomain.de//httpapi/pfSenseacme.sh [Sat Jan 4 16:52:03 CET 2020] gw.mydomain.de:Verify error:Invalid response from http://gw.mydomain.de/.well-known/acme-challenge/PkY0xzgtjG9-eeHDfd2lLIsHNiLKfcUKqZFIXYP-bdA [37.228.164.207]: 503 [Sat Jan 4 16:52:03 CET 2020] Please check log file for more details: /tmp/acme/gw.mydomain.de/acme_issuecert.logSo wie uch die Meldung verstehe versucht er auf "http://gw.mydomain.de/.well-known/acme-challenge/..." zuzugreifen um das Zertifikat zu erneuern aber der Challange ligt doch auf dem FTP-Server "web01.intern.lan"
Wo habe ich da einen Fehler drin?
-
Das ist jetzt nicht so leicht zu sagen. Ich versuche die Logik mal aufzuspalten.
Wo dein FTP-Server liegt, wie er heißt, oder was auch immer... ist Let's Encrypt völlig egal. Wichtig ist nur, dass ACME sich am FTP anmelden kann und der Upload danach unter "http://gw.mydomain.de/.well-known/acme-challenge/" abgerufen werden kann. Ich würde auf dem FTP-Server den Pfad ".well-known/acme-challenge/" anlegen. Dann muss noch ein FTP-User angelegt werden, der darauf zugreifen kann. Jetzt kannst du bei einem Probelauf schon mal ausprobieren, ob die Datei wirklich hochgeladen / erstellt wird. Das kannst du einfach feststellen, wenn du dich selbst mit dem FTP-Benutzer am Server mit einem FTP-Client (z.B. FileZilla) anmeldest, oder über das Terminal/SSH (sofern es ein Linux-/BSD-Server ist). Wenn das funktioniert, ist der erste Teil geschafft.
Zwei Infos:
(1.) Ordner, die mit "." im Namen beginnen sind unter Linux/BSD versteckte Ordner
(2.) Bei produktiver Einstellung, hast du nur weinige Versuche, bis Let's Encrypt den Dienst verweigert. Erstelle am Besten erstmal eine Staging-/Testing-Instanz.Dann muss die Datei, wie gesagt, unter "http://gw.mydomain.de/.well-known/acme-challenge/" von extern abgerufen werden können. Das ist nämlich die Test-URL, die Let's Encrypt verwendet. Dass heißt, auf der Maschine (physikalisch oder VM) auf dem der FTP-Server läuft, muss ein Web-Server laufen. In deinem Beispiel heißt die Datei "PkY0xzgtjG9-eeHDfd2lLIsHNiLKfcUKqZFIXYP-bdA". Teste, ob du die Datei wirklich abrufen kannst. In jedem Fall muss der Proxy entsprechend konfiguriert werden.
Ich habe meinen Proxy so konfiguriert, dass ich in der Access Control List eines Frontends eine ALC-Variable (Name) "acme" erstellt habe:
Name: "acme" --- Expression: "Path starts with" --- Value: "/.well-known/acme-challenge"Die dazu gehörige Aktion:
Action: "http-request-redirect" / rule: "prefix http://acme.mydomain.de" ([durch deine Domain ersetzt]) --- Condition acl name: "acme"Als Proxy-Backend erstellt du "acme.mydomain.de", das auf den Web-Server zeigt, wo ACME deine Datei ablegt. Dazu ertellst du dann das passende Frontend.
Ich hoffe, das war einigermaßen verständlich.
-
Also bezüglich ACME/LE: Was dein Provider da von sich gibt ist quark. Klar wollen die noch Zertifikate verkaufen. Ist aber quatsch, dass es nicht mit LE gehen würde.
Wenn DNS Validation nicht geht, weil das DNS Backend wo du deine Domain hast zu doof dafür ist, kannst du immer noch via Web Auth oder auch einen DNS CNAME Alias nutzen um die Validation auf eine andere Domain zeigen zu lassen, für die man automatische TXT/DNS Einträge updaten lassen kann. Mit FTP würde ich da nicht versuchen rumzubasteln.
Genau dieses herumkaspern ist aber der Grund warum ich den DNS für meine Domains extern selbst verwalte (via Cloudflare oder Namecheap und deren APIs), was super mit acme.sh bzw. der Sense funktioniert. Egal ob Multi-SAN, Wildcard oder single Domain Zertifikat. :)
-
Sorry, ich habe es verpasst es in diesem Post zu schreiben. Ich habe es hin bekommen :-)
Siehe:
https://forum.netgate.com/topic/149458/acme-with-webroot-ftp-not-work/7
