hi zusammen,
ich muss für einen Webserver ein lets encrypt Zertifikat per http-01 abholen also beide Ports 443 und 80 dafür per NAT...
opnsense ist 444 und redirect Port is aus für GUI
Port 80 wird nicht weitergereicht, ich check nicht wieso wenn ich das WAN interface und Port 80 logge kommt nichts im log.
logge ich WAN interface und Port 443 kommt alles schön sichtbar...
proxy hab ich keinen ... wieso kommt das nicht auf der Firewall an?
thanks
System: Settings: Administration -> HTTP Redirect ausgeschaltet? Ach ja, schriebst Du ja schon.
Filtert eventuell Dein ISP?
Am Rande: Wildcards mit DNS-01 sind komfortabler und sicherer, weil die wirklichen Servernamen verborgen bleiben, siehe https://crt.sh.
Quote from: meyergru on April 29, 2025, 08:48:16 PMAm Rande: Wildcards mit DNS-01 sind komfortabler und sicherer, weil die wirklichen Servernamen verborgen bleiben, siehe https://crt.sh (https://crt.sh/).
Was nimmst du als DNS-Server? Einen Provider per API? Ich komm einfach nicht dazu (lies: hab kein' Bock) mich mit dem ACME-DNS auseinanderzusetzen, hätte es aber gerne self-hosted.
Ich nutze dazu zunächst mal den "DNS Alias Mode", der es erlaubt, alle meine Domains über eine einzige dynamische Zone zu bedienen. Dazu muss man in den verwendeten Domains nur einen Alias _acme-challenge.domain.de auf die eine Ziel-Zone challenge.dynamic.de richten. Damit brauche ich für das jeweilige DNS-API eben auch nur ein Ziel.
Das dann zu nutzen, ist super einfach, weil acme.sh für viele DNS-Anbieter API-Unterstützung anbietet, siehe hier (https://github.com/acmesh-official/acme.sh/wiki/dnsapi). Da sind die üblichen Verdächtigen wie Hetzner usw. nativ dabei und man kann die jeweils im ACME plugin per Dropdown auswählen.
Für mein eigenes Hosting nutze ich einfach BIND mit nsupdate per Key. Erzeugen kann man den Key sowohl für das Credential-Feld als auch zur Aufnahme in die BIND-Konfiguration mit "rndc-confgen -k key-name".
In BIND sieht das dann so aus:
##############################################################################
key "key-name" {
algorithm hmac-sha256;
secret "OrOi+2pZ5vKP6ggukc/fu3LFn4xJuTBMASj7FPljit8=";
};
zone "challenge.dynamic.de" IN {
type master;
file "dyn/challenge.dynamic.de.zone";
allow-update { key key-name; };
# update-policy local;
allow-transfer { trusted-servers; };
allow-query { any; };
check-names ignore;
notify explicit;
also-notify { 1.2.3.4; };
forwarders { };
};
##############################################################################
Und man legt eine Stub-Zone in "dyn/challenge.dynamic.de.zone" an. Somit kann ich die "normalen" Zonen statisch (also ohne freeze und thaw) editieren und die Zone challenge.dynamic.de.zone ist die einzige, die voll dynamisch aktualisiert wird. Wie man sieht, gibt es (natürlich) einen DNS Slave (1.2.3.4).
Im Challenge-Teil des ACME Plugins muss man dann nur noch seinen BIND-Server, den Key und die Zone angeben. Ich empfehle eine DNS Sleep Time > 0.
Im Zertifikat dann "DNS Alias Mode" = "Automatic Mode (uses DNS Alias Lookups)" und als Namen "domain.de" und "*.domain.de".
Noch ein Hinweis zu "sicherer":
Wie ich neulich feststellen musste, ist eine meiner Domains inzwischen komplett verbrannt, weil ich früher einmal mit HTTP-01 Multi-Domain-Zertifikate eingerichtet hatte. Unter https://crt.sh sind die "immer noch" verfügbar.
Gemerkt habe ich das, als ich in meinem Firewall-Log Zugriffe per IPv6 bemerkte, was mich doch stark wunderte, weil eigentlich IPv6-Scans nicht sinnvoll erscheinen.
Von diesen Zugriffen gab es drei Typen:
1. Zugriffe von vielen IPv6 mit Quell-Port 433 auf echte IPv6 in meinem Netz (verschiedene Ziel-Ports). Das waren nur beendete SSL-Sessions, die wegen Out-Of-State abgelehnt wurden. Haken dran.
2. Zugriffe von drei IPv6 mit unterschiedlichen Quellports auf eine einzige IPv6 Port 5182x, deren EUI-64 ich gar nicht belegt habe. Eine Rückrechnung der EUI-64 ergab eine OUI von AVM. Hier hatte der "Vorbesitzer" meines Präfix offenbar ein Wireguard-VPN-Netz mit Gegenstellen aufgebaut, die immer noch versuchten, auf seine Fritzbox zuzugreifen. O.K., Zufälle.
3. Zugriffe von einem bekannten Port-Scanner-Netzwerk auf die verschiedensten Zielports auf die korrekte WAN-Interface-IPv6 meiner OpnSense. Die kann man nicht erraten, also wurde dazu DNS verwendet - nur: die DNS-Namen sind nicht weithin bekannt. Leider hatte ich dafür aber einstmals per HTTP-01 Multi-Domain-Zertifikate ausstellen lassen und das war's.
Man muss unabhängig vom "Verstecken per IPv6" auch bedenken, dass man, auch wenn man per IPv4 Reverse Proxies verwendet, eben SSL nutzen, aber trotzdem nicht verraten will, welche Services sich dahinter verbergen. Das geht nur mit Wildcards und dazu braucht man eben zwingend DNS-01.
Warum will man das? Weil diese Scanner die Ergebnisse samt Fingerprinting der gefundenen Services in Datenbanken ablegen, aus denen man im Fall von gefundenen Vulnerabilities der gehosteten Services sofort Angriffsversuche starten kann. Dann ist also kein mühsames Suchen mehr notwendig.
Quote from: meyergru on April 29, 2025, 11:28:38 PMFür mein eigenes Hosting nutze ich einfach BIND mit nsupdate per Key.
BIND auf OPNsense?
Nein, ursprünglich war das mal ein Linux-Server, der jetzt als VM unter Proxmox läuft. Auf dem läuft u.a. auch eine OpnSense, aber meine BIND-Konfiguration ist historisch recht komplex und ich wollte das nicht portieren.
Offen gesagt habe ich mir BIND unter OpnSense noch gar nicht angesehen und weiß daher nicht, ob/wie sich das per GUI konfigurieren ließe.
Dann guck ich wohl selbst mal und schlag mich doch mit dem acme-dns, wenn's nicht klappt. Ich bin dann ja doch der Port Maintainer für das Teil 😬
@meyergru, @monviech
So, hab jetzt ein acme-dns auf einem VPC bei Vultr auf FreeBSD, IPv6 only, API per Firewall eingeschränkt auf meine OPNsense - und das geht mit dem Caddy wie's Brezelbacken. Echt nice.
Wildcards rule!
Schick, also ein maßgeschneiderter DNS-Service, kannte ich gar nicht. Es ist aber beeindruckend, wie viele APIs ACME.sh unterstützt. Und entscheidend ist eben der Trick mit der delegierten _acme-challenge Zone. Damit muss man die Updates auch nur einer einzigen Domain anbieten und kann es überall verwenden.
acme-dns ist ja sogar noch cooler - da kann man ggf. sogar per API Clients registrieren.
Eins verstehe ich allerdings nicht: Die Möglichkeit, die Updates auf IP-Ranges zu beschränken, ist eigentlich doppelt gemoppelt, der zugewiesene API-Key sollte ja hinreichend sicher sein. Aber die Registrierung macht man ja ganz ohne Authentifizierung, also könnte jemand die API mit Anfragen überhäufen. In der Konfiguration kann man die Registrierung nur ganz abschalten - eine selektive Freischaltung scheint aber nicht vorgesehen?
Ich nehme an, das war der Grund für die Einschränkung per Firewall? Schicker wäre, wenn der /register Endpunkt auch per Key oder per Client-Zertifikat geschützt werden könnte. Wenn man Updates "von überall" erlauben will, wird es de facto schwierig, neue Registrierungen durchzuführen. Das passt vom Scaling her nicht so ganz zu einer echten Datenbank - die ja suggeriert, man habe ganz viele Einträge da drin, z.B. im Rahmen eines Hostings.
Quote from: meyergru on May 05, 2025, 11:33:02 PMEins verstehe ich allerdings nicht: Die Möglichkeit, die Updates auf IP-Ranges zu beschränken, ist eigentlich doppelt gemoppelt, der zugewiesene API-Key sollte ja hinreichend sicher sein. Aber die Registrierung macht man ja ganz ohne Authentifizierung, also könnte jemand die API mit Anfragen überhäufen. In der Konfiguration kann man die Registrierung nur ganz abschalten - eine selektive Freischaltung scheint aber nicht vorgesehen?
Ja ... das ist so ein wenig "gebastelt". Die Idee ist, dass man die Registrierung nur kurz einschaltet, evtl. das Teil auch nur über 127.0.0.1 erreichbar macht, dann einen/den Client registriert, und dann die Registrierung wieder abschaltet.
Ich kann da von der Port-Seite ja auch nichts am Ausgangsprodukt ändern. Sinnvollerweise gäbe es eine Access-Liste für bereits registrierte Clients und eine Access-Liste für Registrierungen.
Kannst du natürlich machen, indem du einen Reverse-Proxy davor klebst ;-)
Ich hab für mich selbst einfach den Zugriff aufs gesamte API auf meine Sense beschränkt, ich hab ja im Moment keinen anderen Client. Sicher ist sicher ... und eine Handvoll Zeilen pf sind jetzt auch nicht wirklich wild.
Mal gucken, hab gerade auf Github einen Issue aufgemacht, um erst mal zu klären, was denn überhaupt das amtliche Upstream-Repo ist. Da gibts nämlich zwei ...
Grüße
P.S. Das wäre natürlich auch ein nettes OPNsense-Plugin. Registrierung nur über 127.0.0.1 und sinnvolle Defaults. Aber ich muss jetzt als erstes was am Port tun und upstream einkippen. Das Teil (der FreeBSD-Port) muss noch lernen, nach SIGHUP die Logfiles zu und wieder auf zu machen ...
Falls Du schon issues am Ursprung öffnest: SQLite als drittes Backend wäre auch eine Idee, um das etwas mehr lightweight zu machen... mehr braucht kein Mensch.
Ja, klar, ein Reverse Proxy kann das. Ist aber ansonsten unnötig angesichts der direkten Unterstützung von TLS.
Tatsächlich bräuchte es ein einmaliges "/register-register" mit der selben Struktur wie das jetzige "/register" für das Update, dann könnte man den register-Endpunkt auf 127.0.0.1 einschränken... ;-)
Quote from: meyergru on May 05, 2025, 11:55:23 PMFalls Du schon issues am Ursprung öffnest: SQLite als drittes Backend wäre auch eine Idee, um das etwas mehr lightweight zu machen... mehr braucht kein Mensch.
SQLite ist das Default-Backend und auch der Default im FreeBSD-Port.
[database]
engine = "sqlite3"
connection = "/var/db/acme-dns/acme-dns.db"
Quote from: meyergru on May 05, 2025, 11:33:02 PMWildcards rule!
Meine DNS-Einträge für die einzelnen Dienste hab ich trotzdem noch separat mit CNAME auf den Caddy. Das landet dann ja nirgends in irgendeiner Registry, oder? Die führen nur eine Liste der aktiven Zertifikate ...?
Danke,
Patrick
Ach, ich hatte nur MySQL und PostreSQL gelesen...
Und ja: Siehe https://crt.sh, es sind einfach die Zertifikate. In Deinen DNS kann keiner reinsehen, wenn Du keinen Zonentransfer erlaubst...
Quote from: meyergru on May 06, 2025, 12:12:03 AMUnd ja: Siehe https://crt.sh (https://crt.sh/), es sind einfach die Zertifikate. In Deinen DNS kann keiner reinsehen, wenn Du keinen Zonentransfer erlaubst...
Top! Danke!
Quote from: meyergru on May 06, 2025, 12:12:03 AMAch, ich hatte nur MySQL und PostreSQL gelesen...
Und ja: Siehe https://crt.sh, es sind einfach die Zertifikate. In Deinen DNS kann keiner reinsehen, wenn Du keinen Zonentransfer erlaubst...
Jein. Musste ich auch schon feststellen und konnte mit jemand sprechen, der sich da in Punkte Public DNS auch "etwas mehr" auskennt: Es gibt da durchaus inzwischen auch einen "grauen" Markt mit den Zone-Infos, die bspw. bei Public DNSen angefragt werden. Eine neue Domain, frisch registriert, nur einen sehr random Sub Domain Namen generiert und den einmal vom Rechner aus auf nem Public DNS angefragt -> 3 Tage später die erste Zugriffe aus Ost und Fernost. Die Subdomain war nirgendwo bekannt oder eingerichtet. Nur bei DNS queries. Das ist also durchaus wohl inzwischen ein Ding, dass auch neue Domains via DNS abgegrast oder verschachert werden. Und da war die Domain noch nichtmal irgendwo im TLS Transparency Log weil noch kein TLS ausgestellt wurde. Ab dann ist es eigentlich öffentlich, egal was du machst, weil sich genug einfach den "tail" vom SSL/TLS transparency log abgreifen um Domains zu fischen.
Quote from: meyergru on April 29, 2025, 11:41:52 PMWie ich neulich feststellen musste, ist eine meiner Domains inzwischen komplett verbrannt, weil ich früher einmal mit HTTP-01 Multi-Domain-Zertifikate eingerichtet hatte. Unter https://crt.sh (https://crt.sh/) sind die "immer noch" verfügbar.
Was meinst du mit "immer noch verfügbar"? Sind die Infos nicht aus dem transparency log? Das löscht sich ja nicht einfach, sondern protokolliert einfach nur, wann welche Domain wie mit Zertifikat ausstaffiert worden ist. Und da sind DNS Varianten auch mit drin. Nicht nur HTTP. Verstehe nicht ganz, was es bringen soll auf HTTP01 zu verzichten an der Stelle? Freu mich aber über Erklärung :)
Cheers :)
@JeGr nur mit DNS-01 bekommt man Wildcard-Zertifikate und hält seine konkreten FQDN aus dem transparency log raus.
Quote from: Patrick M. Hausen on May 09, 2025, 12:41:27 PM@JeGr nur mit DNS-01 bekommt man Wildcard-Zertifikate und hält seine konkreten FQDN aus dem transparency log raus.
Ach das ist gemeint *kopfklatsch*
OK da stand ich grad auf der Leitung ;)
Wobei das auch nur "begrenzt" funktioniert, wenn du alles auf der Subdomain Ebene abwickelst. Sobald du auf 3rd Level kommst (x.y.abc.de) ist zumindest mit der 2nd Level Domain die Katze aus dem Sack (y.abc.de ist dann bekannt). Aber klar, für die meisten privaten Sachen bekommt man das sicher so hin. Es wird nur unschön, wenn an zu vielen Stellen dann das Zert gebraucht wird, da Multi-Ausstellung bei Wildcards meine ich ab irgendeiner Zahl zu Problemen führte? Mehr als 5x? das gleiche Zert war dann - nicht so gut.
Was heißt denn Multi-Ausstellung? Es wird ein Wildcard-Zertifikat ausgestellt und hundert mal deployed.
Aber nur wenn du es deployen kannst, Patrick :)
Geh doch nicht immer von den schönsten einfachsten Hardware Boxen aus ;) Das würde ich ja gern, aber den Luxus hat man leider nicht immer. Und wenn du in Geräte extern keine Zertifikate reinprügeln kannst/darfst, sondern die das selbst ausstellen müssen, kann(!) es eng werden - muss nicht. Ich wollte es nur mal in den Raum geworfen haben, dass es kein Panacea ist weil es Beschränkungen gibt: https://letsencrypt.org/docs/rate-limits/#new-certificates-per-exact-set-of-hostnames
Wissen nicht alle - darum der Hinweis. Gerade wenn du irgendwelche verkorkten Kisten hast die darauf bestehen, selbst Zertifikate auszustellen.
BTW: Wenn wir bei Beschränkungen sind: Der acme-dns Service hat auch eine, er kann nicht mehr als 2 SAN Einträge setzen. Also genau "domain.tld" und "www.domain.tld" oder "*.domain.tld" je nachdem was man macht. Wer damit aber bspw. ein Multi-SAN-Zert für nen Proxy o.ä. machen will, in welchem vllt. mehrere Domains drin sind (weil domain2.tld auch noch gebraucht wird) - hat da Probleme. Das ist in irgendeinem Support Ticket zu acme-dns verschüttet mal diskutiert worden, weil das hardcoded Werte sind. Klar, macht man halt die Domains einzeln, aber auch hier: weiß man vllt. nicht - sucht man stundenlang nach Nichts :)
Cheers :)
Jens, Du hast vollkommen recht. Mit den kommenden Verkürzungen müssten diese Beschränkungen aber heftig angepasst werden, zudem dann tatsächlich Verlängerungen ggf. sogar jeden Tag passieren müssten (mal ganz abgesehen von der höheren Last bei den ACME-CAs).
Ich habe da mal angefragt: https://community.letsencrypt.org/t/how-will-lets-encrypt-deal-with-the-effects-of-shorter-certificate-lifetimes/237293, bin gespannt...
Aha. Die 10 Tage waren eine Ente, die ich mal - vor der Korrektur auf 47 Tage - in diesem Heise-Artikel (https://www.heise.de/news/TLS-Zertifikate-Apple-schlaegt-maximale-Laufzeit-von-10-Tagen-vor-9991640.html) gelesen hatte. Die Verkürzung geht in Stufen nur auf 47 Tage, was immer noch genug Zeit bei Problemen in der Automation gibt und auch die Limits nicht unrealistisch niedrig erscheinen lässt...