LetsEncrypt auf PFSense mit nsupdate

inciter

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.

pixel24

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?

inciter

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

Bob.Dig

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.

inciter

@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.

Bob.Dig

@inciter Aber erlauben das irgendwelche (Billig-)Hosting-Tarife auch, das ist die Frage.

inciter

@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.

pixel24

@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/html

dar. Hier lege ich nun Pfad:

/var/www/html/.well-known/acme-challenge

an, 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?

pixel24

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/webftp

Dort wiederum gibt es den das Unterverzeichnis für die acme-challenge, also:

webftp@web01:~/.well-known/acme-challenge

Mit 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?

pixel24

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.log

So 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?

inciter

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.

JeGr

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. :)

pixel24

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