Wie wäre es, wenn du die Ausgabe der Regeln einfach mal hier reinkopierst in CODE Tags? Dann können wir vielleicht selber sehen, woran es hakt.
Ich vermute, die before Rules sind gar nicht aktiv, weil die Commit Zeile fehlt.
Beiträge von frank_m
-
-
Ist der Syntax der before Rules richtig? Hast du an den Commit gedacht? Das ist ja ein iptables Aufruf, kein UFW Aufruf. Die Regeln sind dann später auch da und werden vor den anderen aufgerufen? Hast du das überprüft?
Ansonsten sind die Sperr-Regeln im UFW natürlich hinter den allgemeinen Freigaben. Heißt: Das Paket wurde durch die Port 22 Regel schon lange durchgelassen und wird die Sperr-Regel nie erreichen.
-
Die, wo man erkennen kann, welche Anfragen beim NPM ankommen und wie er darauf reagiert.
Das manuelle Hinzufügen hat sicher funktioniert? UIDs, Rechte, etc., alles ok? Bei Zertifikaten ist das heikel.
-
Gibt's denn nirgends aussagekräftige Logs? Das wundert mich.
Genau. Danach frage ich ja schon länger.
Das hat jetzt anscheinend geklappt,
Wie wurden die Zertifikate denn installiert?
-
Wie rufst du denn Zertifikate per nslookup ab? nslookup kommuniziert ja nur mit dem Nameserver, aber nicht mit deinem NPM.
Du verwechselst jetzt nicht gerade Zertifikat mit TXT Eintrag?
-
Ich hatte aus #47 verstanden, dass das LE Update und das Installieren der Zertifikate schon geklappt hat?
Ich hab immer noch den Verdacht, dass bei der Domain-Konfiguration im NPM was falsch ist, und er die Zuordnung zu den Domains nicht richtig erkennt. Die Weiterleitung klappt ja auch nicht, und offenbar wird ein falsches Zertifikat ausgeliefert.
-
Dass das Zertifikat als nicht gültig angegeben wird, hattest du schon geschrieben. Die Frage ist, warum. Und da kommen wieder meine Fragen von oben ins Spiel, die immer noch nicht beantwortet sind.
-
Anschlussfrage: Nutzt ihr rotierbare Monitorarme/-halter bzw. kennt Ihr ein paar belastbare Vergleiche/Webpräsenzen, die sich auf einschlägige Testberichte spezialisiert haben
Privat nicht. Im Büro haben einige Kollegen solche Dual-Monitor-Arme. Da muss ich das Fabrikat mal raussuchen, die sind recht zufrieden.
-
Gibt es hier Nutzer, die irgendwann zu dem Schluss gekommen sind, dass man trotz virtueller Bildschirme/mehrerer Eingänge zum flexiblen Umschalten gar nicht genug Bildschirmfläche vor sich haben kann?
Ich hab 2x 27" 4k Monitore ...
-
Was ist denn bei der Untersuchung infolge meiner Fragen von oben herausgekommen?
-
Werden die Domains per nslookup aufgelöst? Dann nicht.
-
Naja, ich kann beide Domains aufrufen.
Das war nicht meine Frage. Was erkennt der NPM beim Aufruf? Hat er überhaupt eine Chance, die Anfrage richtig weiterzuleiten? Das müsstest du aus den Logs entnehmen können. Ich vermute, da geht beim Aufruf der Domains was schief.
Wenn das Zertifikat für die Domain richtig ausgestellt ist und richtig eingebunden wurde, dann müsste es gültig sein. Der Umstand, dass es als ungültig eingestuft wird, ist für mich ein weiterer Hinweis, dass mit deinen Aufrufen auf die Domains etwas noch nicht stimmt.
-
Allerdings gibt es jetzt das Problem, dass für beide zum Test angelegte Proxy Hosts, trotz der richtigen Einstellungen immer "Heimdall" aufgerufen wird ...
Erkennt der NPM die aufgerufene Domain denn richtig?
... und außerdem die Browser über die Zertifikate meckern: "Warnung: Mögliches Sicherheitsrisiko erkannt"
Über welche URL beschweren sich die Browser denn?
Ich hab die Befürchtung, dass der Aufruf in deinem Browser nicht zu deinem Zertifikat und zur NPM Konfiguration passt.
-
Genau, du musst die Aufrufe machen, während das Lets Encrypt Script läuft. Mache den Aufruf am besten mehrfach, so einmal pro Minuten, und schaue, ob irgendwann der Text Eintrag auftaucht. Wo wir dabei sind: Du hast den Text Eintrag ja im Web-Portal von Netcup gesehen, wenn er vom Lets Encrypt Script eingetragen wurde. Wie war der Status des Eintrags? Gültig? Unbekannt? Ungültig? Das könnte auch noch Hinweise geben.
Wenn der Eintrag nicht auftaucht, dann hast du ein Timing Problem, oder die API Aufruf klappen doch nicht so, wie du glaubst. Wenn der Eintrag auftaucht, und das Zertifikat kommt trotzdem nicht zustande, dann ist vermutlich der eingetragene Wert für cie Challenge falsch. Das ist durchaus denkbar, da es auch bei DuckDNS schiefgeht. Dann müsstest du die Konfiguration deiner Scripte überprüfen.
-
nslookup kennst du? Mach eine txt query auf die acme Challenge, optional mit Angabe eines DNS Servers.
nslookup -type=txt _acme-challenge.<YOUR_DOMAIN> -
Womit? nslookup? Was genau ist das Problem.
-
Das halte ich für zu wenig. Es ist nahezu unmöglich, dass die Lets Encrypt Server nach so kurzer Zeit schon Ergebnisse bekommen. Neben der Aktualisierungszeit muss man ja auch TTL in Betracht ziehen.
Du kannst ja mal parallel zum Vorgang die DNS Challenge per nslookup aufrufen und schauen, ob sie aufgelöst wird.
-
Da es bei anderen funktioniert, wird es wohl ein individuelles Problem sein.
Wie lange dauert der gesamte Prozess? Und teste es auf jeden Fall mal manuell.
-
Was soll ich wo bei der ACME Challenge eintragen?
Na da, wo sie sonst automatisch eingetragen werden. Das hast du ja überprüft. Jedenfalls hast du das behauptet. Die Frage ist: Wurde das richtige eingetragen? Und was ist damit passiert, nachdem der Vorgang gescheitert ist?
Welche Skripte?
Die, die die Ausführung machen. Deren Output sieht man ja oben, auch die Voraussetzungen, die sie brauchen.
-
Viele nutzen den als Jump Host, um von da über VLANs auf die eigentliche Infrastruktur zuzugreifen. Ein kleiner Host mit viel Bandbreite.
Ich nutze übrigens SSH direkt, aber auf mystischen Ports und gut abgesichert (keine Passwort-Authentifizierung, kein Root Zugriff, Fail2Ban, etc,).
