Erfahrung mit dem Package "acme"
-
Da sonst Niemand antwortet... Schau dir mal das HAProxy Package an. Weitere DynDNS-Host anlegen, einen für jeden Server. HAProxy im Reverse-Porxy-Betrieb verbindet nach entsprechender Konfiguration zum richtigen Web-Server, was CAL und Card einschließen sollte. HAProxy besherscht zudem SSL-Offloading und kann damit deine Zertifikate handlen.
Alternativ muss jeder Server einen eindeutigen, manuell angepassten Port haben, welche forwarded werden müssen. Die Server müssen dann im einzelnen selbst die Zertifikate verwalten.
-
@mike69
Hallo,warum betreibst du nicht auf diesen Servern selbst einen ACME Client? Certbot macht seine Arbeit ganz gut.
Gruß
-
@inciter
Danke fr den Tip, schaue ich mir mal an.@viragomann said in Erfahrung mit dem Package "acme":
@mike69
Hallo,warum betreibst du nicht auf diesen Servern selbst einen ACME Client? Certbot macht seine Arbeit ganz gut.
Gruß
Die ersten Versuche scheiterten an der gleichen IP vom Provider nehme ich an. Server A Zertifizierung iO, Server B failed. Einen Tag später mit neuer IP erst Server B, was funktionierte, Server A funktionierte nun nicht mehr. Ok, die beiden Server hatten erstmal ein funktionierendes Zertifikat was auf Dauer nicht befriedigend war und habe das Thema irgendwann aus den Augen verloren.
Zur Zeit holt sich eine Maschine vierteljährig die Aktualisierung und es läuft so das zweite Jahr einwandfrei.
Eine weitere Sache ist, das die mit den Standardbrowsern in den Android Geräten kein HTTPS-Zugang zur WebGUI der pfSense möglich ist. Sind ja Selbstsigniert die Zertifikate, und die wollen signierte haben.
Da auf unseren Androiden kein Google installiert ist und die APKs händisch ohne GooglePlay installiert werden wollen, ist das Angebot von Browsern ziemlich rar gesät, welche Ausnahmen ermöglichen.Daher der Gedankengang, die pfSense holt sich die Zertifizierung und gibt diese nach hinten weiter. Kann dann mit den Standardbrowsern per HTTPS auf die pfSense zugreifen, die nachfolgenden Maschinen werden ebenfalls als "Zertifiziert" erkannt. So der Plan.
-
Bezüglich der pfSense WebGUI ist die Sache schon klar, aber Webserver...
Ich kenne die Fähigkeiten des ACME-Packages auf der pfSense nicht, aber klar ist, dass dein Vorhaben nur mit SSL-Offloading auf der pfSense funktionieren kann, ansonsten müssten ja die Zertifikate, die der ACME-Client abholt, auf den Webservern gespeichert werden. Und SSL-Offloading ist wohl nur mit einem Proxy umzusetzen.
@mike69 said in [Erfahrung mit dem Package "acme"]
Die ersten Versuche scheiterten an der gleichen IP vom Provider nehme ich an.
Heißt das, du hast nur eine öffentliche IP? Und du trennst die Dienste mittels unterschiedlicher Ports?
Dann wird dein Anliegen auch klar.
Ich habe sämtliche Webservices, die auf einer IP erreichbar sein müssen, auch auf einem Webserver laufen, bzw. setze auf diesem selbst einen Proxy ein, um auf einen anderen Server weiterzuleiten. -
@viragomann said in Erfahrung mit dem Package "acme":
Bezüglich der pfSense WebGUI ist die Sache schon klar, aber Webserver...
Ich kenne die Fähigkeiten des ACME-Packages auf der pfSense nicht, aber klar ist, dass dein Vorhaben nur mit SSL-Offloading auf der pfSense funktionieren kann, ansonsten müssten ja die Zertifikate, die der ACME-Client abholt, auf den Webservern gespeichert werden. Und SSL-Offloading ist wohl nur mit einem Proxy umzusetzen.
Dann wede ich mir mal HaProxy anschauen.
@viragomann said in Erfahrung mit dem Package "acme":
Heißt das, du hast nur eine öffentliche IP? Und du trennst die Dienste mittels unterschiedlicher Ports?
Dann wird dein Anliegen auch klar.Ja genau, eine IP vom Provider und die verschiedenen Dienste sind durch unterschiedliche Ports erreichbar. Eigentlich nur 2 die von aussen erreichbar sein sollen, FTP auf Server A und CalDAV auf Server B. Beim Zugriff per VPN werden die IPs der Server genutzt, daher haben die Webserver den gleichen Port.
Der DynDNS-Anbieter unterstützt Wildcards, so ist es möglich example.com aufzulösen und mit server1.example.com die dahinterstehen Maschinen zu erreichen. Leider können die Server nicht ootb auf die Zertifikate der Sense zugreifen, was für mich die Ideallösung wäre.
Jetzt mal kurz Off -Topic
Nutzen die pfSense im privaten Bereich und nicht beruflich, wie viele hier im deutschen Unterforum. Und manchmal entsteht der Eindruck, dass die Erwartungshaltung dem TE gegenüber gelegentlich zu hoch sind. Hier laufen genug Landeier wie Ich herum, deren Wortwahl zur Problematik auf dem ersten Blick etwas sonderbar scheint oder Defizite im Grundwissen der Netzwerktechnik haben.
Ein im Forum hinterlegtes Nutzungsprofil (Privat, Beruflich, Staff)würde da eventuell entgegenwirken.So, genug geflennt.
-
Alles klar. Aber du brauchst dich nicht zu entschuldigen. Ich hatte einfach nicht gleich deine Problematik verstanden.
Ich wäre mal froh, wenn so manche andere, die hier nachfragen auf deinem technischen Level wären.Dass das für privaten Nutzen ist, hatte ich schon vermutet. Gerade hier finde ich den HA-Proxy etwas überdimensioniert. Deshalb habe ich das eben über den Apache Proxy gelöst, der ohnehin eine andere Webseite bereitstellt. Allerdings verwendet die weitergeleitete Seite kein TLS und damit macht der Proxy auch kein SSL-Offloading, was auch damit in deinem Fall erforderlich wäre.
Wenn du gewillt bist zu lernen, kann aber HA-Proxy vermutlich mehr Möglichkeiten bieten.
-
Danke.
Schaue mir bei Gelegenheit HaProxy an, habe die Certs händisch kopiert und erstmal 3 Monate Ruhe.
-
@viragomann said in Erfahrung mit dem Package "acme":
Dass das für privaten Nutzen ist, hatte ich schon vermutet. Gerade hier finde ich den HA-Proxy etwas überdimensioniert. Deshalb habe ich das eben über den Apache Proxy gelöst, der ohnehin eine andere Webseite bereitstellt. Allerdings verwendet die weitergeleitete Seite kein TLS und damit macht der Proxy auch kein SSL-Offloading, was auch damit in deinem Fall erforderlich wäre.
Dem muss ich widersprechen. HAProxy ist sicherlich komplex und bietet für Anfänger einen schweren Einstieg. Als Reverse-Proxy und Load-Balancer hat er den größten verfügbaren Funktionsumfang, arbeitet aber trotzdem extrem effizient. Für @mike69 sehe ich ihn als alternativlos. Mit Squid als Reverse-Proxy wird er bei seinem Vorhaben scheitern - auf Details gehe ich hier nicht ein, da käme meine Tastatur ins Glühen. Ich selbst habe ein ähnliches Setup und bin wirklich dankbar, dass es HAProxy gibt.
Ein Apache oder NGinx als Reverse-Proxy wäre bestimmt eine Alternative, würde allerdings einen weiteren Host erfordern, während mit HAProxy die Lösung direkt auf der PFSense läge.
Als Tip: https://www.youtube.com/watch?v=aG3gmlQsfnw&t=314s
-
@inciter said in Erfahrung mit dem Package "acme":
Ein Apache oder NGinx als Reverse-Proxy wäre bestimmt eine Alternative, würde allerdings einen weiteren Host erfordern
So habe ich das nicht gemeint.
Ich habe 2 Hosts, auf denen jeweils Webserver laufen. Auf dem einen, der sämtliche Anfragen von außen bekommt, habe ich neben den Webapplikationen auch einen Proxy eingerichtet, der die Anfragen an den anderen weiterleitet.
Da ist kein zusätzlicher Host erforderlich. -
@viragomann said in Erfahrung mit dem Package "acme":
@inciter said in Erfahrung mit dem Package "acme":
Ein Apache oder NGinx als Reverse-Proxy wäre bestimmt eine Alternative, würde allerdings einen weiteren Host erfordern
So habe ich das nicht gemeint.
Ich habe 2 Hosts, auf denen jeweils Webserver laufen. Auf dem einen, der sämtliche Anfragen von außen bekommt, habe ich neben den Webapplikationen auch einen Proxy eingerichtet, der die Anfragen an den anderen weiterleitet.
Da ist kein zusätzlicher Host erforderlich.Hmm klar, kannst du für diesen Fall auf jeden Fall so lösen. Theoretisch könnte @mike69 auf einem der Cal-/Card-DAV auch einen Apache/NGinx installieren und als Reverse-Proxy konfigurieren. Technisch natürlich einwandfrei. Wie man es am Ende löst, ist dann wahrscheinlich eher eine philosophische Frage. Ich persönlich würde HAProxy auf der PFSense aus einem einfachen Grund bevorzugen: Ich halte damit meine Server sauber. Weniger Funktion am kritischen Endpunkt = weniger Wartungsaufwand und höhere Zuverlässigkeit. Am Ende entscheidet vermutlich aber auch, welches Grundwissen ich mitbringe.
Ansonsten kann ich nur sagen, wenn man erst mal verstanden hat, wie HAProxy funktioniert, ist das Alles kein Hexenwerk mehr. Aber das wohl mit allen Dingen so. Jaja... ich weiß, ich mag HAProxy einfach. ;)
-
Webserver laufen auf jedem Host, wird von Baïkal als CalDAV/CardDAV Server benötigt.
Kann zu Not auch per Sript die Certs verteilen.Nutze hier Traffic Shaper inkl. Limiter für einige Services und Clients, squid als Proxy hat mir die fast alles ausgehebelt. Wie sieht es bei HA-Proxy aus, auch keine Probleme mit pfBlockerNG?
-
@mike69 said in Erfahrung mit dem Package "acme":
Webserver laufen auf jedem Host, wird von Baïkal als CalDAV/CardDAV Server benötigt.
Kann zu Not auch per Sript die Certs verteilen.Nutze hier Traffic Shaper inkl. Limiter für einige Services und Clients, squid als Proxy hat mir die fast alles ausgehebelt. Wie sieht es bei HA-Proxy aus, auch keine Probleme mit pfBlockerNG?
Ja, ich bin an Squid auch verzweifelt, aber letzendlich war die schlechte Handhabung der Zertifikate (SSL-Offloading) schon allein ein Ausschlussgrund. Dementsprechend habe ich den Versuch mit Squid aufgegeben bevor ich in weitere Probleme laufen konnte.
In meiner Konfiguration betreibe ich HAProxy inkl. ACME zusammen mit pfBlocker (aktuelle Beta aus den Packages) und Snort. Läuft jetzt schon schon seit über einem Jahr (vorher natürlich mit älterem pfB) problemlos. Allerdings hatte ich zuvor Probleme, wenn die von pfBlocker erstellten Regeln voran gestellt werden - also im Regelwerk der Firewall oben stehen. In der Einstellung (IP => IP Interface/Rules Configuration => Firewall 'Auto' Rule Order) habe ich die Reihenfolge geändert, damit sie unten angehängt werden. Adware-, Tracking- und Malware-Quellen werden nachwievor perfekt rausgefiltert.
-
Die Rules werden nach der "allow any to any" Rule gesetzt und greifen noch?
Der Rest hört sich gut an, dann schau ich mir das mal an. -
@mike69 said in Erfahrung mit dem Package "acme":
Die Rules werden nach der "allow any to any" Rule gesetzt und greifen noch?
Der Rest hört sich gut an, dann schau ich mir das mal an.Also "Any2Any" iss bei mir sowieso nix ;) Also Alles streng reglementiert und nur erlaubt, was benötigt wird.
Aber ja... Ich hatte damals nach einer Lösung zu meinen Problemchen gesucht. Dabei wurde gleich mehrfach darauf verwiesen, die Regeln hinten anzuhängen. Damit greifen sie aber immer noch alle Inbounds ab, außer ein Forwarding und eben die Ports zum Webserver (80 und 443) über HAProxy. Ein weiterer Teil wird bereits im Resolver (unbound: siehe "Hidden Custom Options") abgefangen. Deshalb sind Outbounds nicht mehr das große Problem, da betroffene URLs/IPs bereits nicht mehr aufgelöst werden. Für Inbound-Requests zu den Webservern ist dann am Ende Snort verantwortlich, da hilft pfB eh nicht.
Ich war auch erst skeptisch, aber gefühlt werde ich von 99% Werbung, Spam, Tracking und Malware verschohnt. Das Firewall-Log bestätigt das - jede Menge Blocks durch pfB. Du kannst die Regeln ja erst mal hinten anhängen und erst voranstellen, wenn Alles fertig ist und läuft. Wenn dann immer noch Alles wie gewünscht funktioniert, kann es so bleiben.
-
@inciter said in Erfahrung mit dem Package "acme":
@mike69 said in Erfahrung mit dem Package "acme":
Die Rules werden nach der "allow any to any" Rule gesetzt und greifen noch?
Der Rest hört sich gut an, dann schau ich mir das mal an.Also "Any2Any" iss bei mir sowieso nix ;) Also Alles streng reglementiert und nur erlaubt, was benötigt wird.
OK, bissl unglücklich ausgedrückt.
Werde es ändern wenn ich zu Hause bin, stehen aktuell vor einigen deny Rules.
Nachtrag:
So, mal nachgeschaut, alles bis auf das Erste würfelt mir die ganzen Regeln durcheinander.
Default vorneweg und danach die Rules von pfBlockerNG, das wird nicht angeboten. -
@mike69 said in Erfahrung mit dem Package "acme":
Die ersten Versuche scheiterten an der gleichen IP vom Provider nehme ich an. Server A Zertifizierung iO, Server B failed. Einen Tag später mit neuer IP erst Server B, was funktionierte, Server A funktionierte nun nicht mehr. Ok, die beiden Server hatten erstmal ein funktionierendes Zertifikat was auf Dauer nicht befriedigend war und habe das Thema irgendwann aus den Augen verloren.
Also das würde mich wundern, damit hatte ich noch keinerlei Probleme. ACME ist das auch relativ wurscht, von welcher IP das alles kommt, wenn dann der Challenge passt. Du wirst bei produktivem ACME aber nach x Versuchen gesperrt wenn du Fehler machst, daher erstmal mit Staging testen und dann auf Production umstellen hilft Fehler zu suchen ohne gesperrt zu werden.
Dein Problem würde sich aber zu 99% leichter gestalten, wenn du statt den ganzen DynDNS Domains dir einfach selbst eine besorgst und bei einem unterstützten DNS Provider wie Cloudflare bspw. parkst bzw. deren Nameserver für die Domain nutzt. Dann kann pfSense und ACME via DNS01 auth dir problemlos so viele Zertifikate ausstellen wie du lustig bist :) Und den DynDNS kannst du mittels Cloudflare API auch mit deiner eigenen Domain problemlos nutzen ;)
Wenn dir also Zugriffstrennung durch Ports genügt und du nicht mehrere Domains brauchst weil alles bspw. auf tcp/443 hört, kannst du problemlos auch mehrere Geräte hinter der Sense mittels ACME+DNS01 auf den Geräten direkt bespaßen und das einfach forwarden. Ansonsten Acme+Haproxy ist auch nicht mehr so schwierig einzusetzen.
Grüße
Jens -
Nabend.
Ja, kann sein, dass die es zu viele Versuche waren, irgendwann ging es nicht mehr. Der eine Host lief und das reichtr mir, irgendwann das Thema aus den Augen verloren.
Dein Problem würde sich aber zu 99% leichter gestalten, wenn du statt den ganzen DynDNS Domains dir einfach selbst eine besorgst und bei einem unterstützten DNS Provider wie Cloudflare bspw. parkst bzw. deren Nameserver für die Domain nutzt. Dann kann pfSense und ACME via DNS01 auth dir problemlos so viele Zertifikate ausstellen wie du lustig bist :) Und den DynDNS kannst du mittels Cloudflare API auch mit deiner eigenen Domain problemlos nutzen ;)
Du wirst es nicht glauben, bin bei Cloudflare angemeldet.
Eine eigene Domain ist vorhanden, inkl. 10 Subdomains, DynDNS, 5 Mailaccounts usw. Mir fehlt irgendwie die Zeit und das know how das geschmeidig zu integrieren.
Edit:
Also bei cloudflare die Domain parken, klappt schonmal. DynDNS über cloudflare auf der Sense ist eingerichtet, A Records passt auch schon laut cloudflare. -
@mike69 said in Erfahrung mit dem Package "acme":
Also bei cloudflare die Domain parken, klappt schonmal. DynDNS über cloudflare auf der Sense ist eingerichtet, A Records passt auch schon laut cloudflare.
Klingt doch gut ;) Macht auf alle Fälle die Bearbeitung einfacher und wie ausgeführt via DNS01 ist es auch problemlos drin, die anderen Hosts dahinter abzufrühstücken.
Andere Variante wenn du abenteuerlustig und bastlerisch arbeiten willst: Du kannst im ACME Paket auch ein Wildcard Zertifikat abholen und ausstellen lassen. Zudem kannst du die Haken setzen, dass das Zert auf der Sense lokal gespeichert wird (nicht nur im Cert Manager), so dass du es mittels Skripten woanders hin schieben kannst/könntest. Damit könntest du einen Cron oder Push-Job einrichten, der das Zertifikat auf andere Geräte verteilt. :)
Grüße
-
@jegr said in Erfahrung mit dem Package "acme":
Tja, gestern die Hardware abgeraucht, muss erst mal Ersatz ranschaffen.
Was vorher aufgefallen ist, der FTP-Zugang funktioniert nicht über cloudflare. Es gibt ein Workaround dazu, musst aber bei jedem IP-Wechsel wieder händisch eingreifen. Hier. -
Was vorher aufgefallen ist, der FTP-Zugang funktioniert nicht über cloudflare. Es gibt ein Workaround dazu, musst aber bei jedem IP-Wechsel wieder händisch eingreifen. Hier.
FTP?
Wofür braucht man DAS heute noch!?
Und das ist IMHO kein Workaround, da steht doch nur, dass man den Eintrag mit "grauer Cloud" einstellen soll, also nicht Cloudflares CDN davor, sondern eben dass direkt die IP des Dienstes angegeben wird. Das sollte genauso funktionieren wie alle anderen Records die du dynamisch änderst auch.
Trotzdem: wenn du 2019 noch mit FTP arbeiten musst, dann läuft - nur meiner bescheidenen Meinung nach - schon was schief. Zumindest FTP/S (gruselig genug) oder SFTP müssen heute drin sein, wenn nicht eh ganz andere Methoden genutzt werden. :)Grüße