Lets Encrypt ACMEv2 | RFC 2136 Update | Strato

[JeGr]

@alcamar said in Lets Encrypt ACMEv2 | RFC 2136 Update | Strato:

Nach der obigen Meldung habe ich das "*" entfernt und das Zertifikat lässt sich erstellen. Mein Ziel war zwar ein wildcard-Zertifikat für die SubDomain zu ertsellen, aber wenn ich pro Server ein Zertifikat erstellen muss, kann ich damit leben.

Das lässt sich auch machen, es kann nur sein, dass ggf. der Delegationseintrag nicht ganz korrekt ist oder man noch einen weiteren bei Strato setzen muss, das hab ich leider gerade nicht im Kopf, aber gehen sollte es.

Aber freut mich wenn es positive Fortschritte gab :)

[Alcamar]

@jegr Delegationseintrag ist sowas mit _acme-challenge?
Der Fehler beim Erstellen des Zertifikats lautet:
"Error add txt for domain:_acme-challenge.mysub.domain.de"

Die DNS-Namensauflösung ist das eine und das klappt auch. Aber HAProxy bekomme ich einfach nicht zum Laufen. Ich habe einige Anleitung im Netz genommen, aber sehe nicht wo das Problem sein könnte.

Da ich in diese Bereich neu bin, habe ich auch in einem anderen Forum, das HAProxy thematisiert einen Post geschrieben. Ich weiss nicht, ob das eine gute Vorgehensweise ist, oder es nicht bessere wäre in einem Forum zu bleiben. Dort schien mir HAProxy eine Thema zu sein. Eine Reaktion habe ich aber nicht bekommen.

Das Problem ist, dass beim Aufruf einer Servers hinter dem Proxy nach einer Weile ein Time-Out kommt. In den Diagnostics der pfsense bin ich verloren.

[Alcamar]

@alcamar meine Vermutung ist, dass meine FritzBox und die pfSense noch nicht perfekt konfiguriert sind. Auf der Fritz ist vermutlich alles richtig weitergeleitet, aber auf der PfSense fehlt vielleicht noch etwas.
Habe das Wochenende mit der Fehlersuche verbracht und es geht leider kein Reverse-Proxy. Auf der Synology war das mal eine relativ schnelle Einrichtung. Die Funktion nun auf die pfsense zu übertragen ist offensichtlich nicht so einfach.

[viragomann]

@alcamar
Möchtest du hier dein Leid loswerden oder erhoffst du dir auch Hilfe?
Wenn ersteres, ist das der falsche Ort. Wenn letzteres, müsstest du ein paar Details nachreichen. "Läuft nicht" oder "Bekomme Timeout" ist a bisserl zu wenig, um erkennen zu können, was du falsch gemacht hast.

Wie sieht die HAproxy Konfiguration aus?
Was ist das Backend? Worauf reagiert es?
Zeigt der Proxy die versuchte Verbindung in seinem Status an?

[Alcamar]

@viragomann sorry, Du hast Recht. Bin komplett im Wald. :-)

Im Frontend sind zwei Einträge:

1. alle http-Anfragen werden nach nach https umgelenkt
2. Ein Server(cam1) hört auch cam1.domain.de auf 443
   login-to-view

Im Backend ist unter Server List nur die web-Cam konfiguriert, die auf Port 443 (80 hatte ich auch schon) hört und auf eine IP-Adresse im LAN zeigt.
login-to-view

HA Stats sagt, dass ein L4Check erfolgreich ist.
login-to-view

Die web-Adresse der webcam wird über DynDNS richtig aufgelöst.

Deine letzte Frage würde ich auch gerne beantworten, wenn ich wüßte wo ich das sehen kann.

[Alcamar]

@alcamar Vermutlich beantwortet das Deine dritte Frage:
login-to-view
Ich denke, dass HAProxy nichts mitbekommt, weshalb ich mein Problem im Basis-Setup der pfSense vermute. Auf der Fritz!Box sind die Ports 80 und 443 weitergeleitet. Auf der pfSense selbst habe isch den 443-Port schon auf etwas anderes geändert.

[JeGr]

@alcamar said in Lets Encrypt ACMEv2 | RFC 2136 Update | Strato:

Deine letzte Frage würde ich auch gerne beantworten, wenn ich wüßte wo ich das sehen kann.

In den Spalten Queue und Sessions in der Ausgabe die du oben gepostet hast. Das Backend bekommt überhaupt kein Traffic - so sieht das für mich aus.
Dein Frontend für die Cam ist ein untergeordnetes shared frontend. Wie ist das parent konfiguriert? Wenn da schon alle Requests weggefressen werden, kommt der Kram beim cam1 frontend nie an.

Da hat @viragomann recht - ohne mehr Konfig sehen zu können kann da keiner sagen, warums nicht klappt :)

Cheers

[viragomann]

@alcamar said in Lets Encrypt ACMEv2 | RFC 2136 Update | Strato:

Ein Server(cam1) hört auch cam1.domain.de auf 443

Und was ist das "https-shared"?
Und wie sehen die Frontend Konfigurationen aus?

Etwas seltsam finde ich, dass "https-shared" das Primary-Frontend ist.

Ja, das Backend scheint online zu sein, jedenfalls soweit das der Healthcheck feststellen kann. Aber ein Problem mit dem Backend hätte eine andere Auswirkung im Browser, soweit ich weiß. HAproxy würde zumindest eine Antwort liefern.

Deine letzte Frage würde ich auch gerne beantworten, wenn ich wüßte wo ich das sehen kann.

Auch in den Stats, im Frontend > Session total.

Am Settings-Reiter kannst du dir ganz unten die gesamte Konfig anzeigen lassen. Die bietet tlw. eine bessere Übersicht.

Auf der pfSense selbst habe isch den 443-Port schon auf etwas anderes geändert.

Du meinst, den WebGUI Port?
Weitergeleitet darf 443 auf der pfSense natürlich auch nicht werden.

[JeGr]

@viragomann said in Lets Encrypt ACMEv2 | RFC 2136 Update | Strato:

Und was ist das "https-shared"?

Das kommt aus dem HAproxy Template das man einfach per klick als dummy einrichten kann, das hat aber normalerweise in sich auch nochmals ACLs und Regeln. Das ist nur als Beispiel für "kann man in einem - oder mehreren - Frontends einrichten" gedacht, je nachdem was man machen möchte. Ich mutmaße wie du, dass das falsch eingerichtet ist

[Alcamar]

@jegr ich kann versuchen alles, zu zeigen, was hilft. Das ist die Konfiguration für https-shared
login-to-view

[Alcamar]

@jegr https-shared ist aus Verzweiflung und ein Tutorial entstanden. Zuvor hatte ich nur einen Eintrag und dann war alles enthalten, was aber auch nicht funktionierte und deshalb deaktiviert:
login-to-view
login-to-view

[viragomann]

@alcamar
Der Screenshot zeigt "https-frontend". Das ist deaktiviert und kann nichts anstellen.
Wir hatten aber von https-shared gespochen. Das ist das Primary-Frontend für des cam1 und kann damit nicht deaktiviert werden.

Grundsätzlich braucht man kein Shared-Frontend und kann alles im Primary konfigurieren.
Shared dient meiner Ansicht nur der besseren Übersichtlichkeit, damit man die ACLs verschiedener Zwecke klar ordnen kann.
Du hat aber nur die Cam.

[Alcamar]

@viragomann so hatte ich das auch verstanden. Da noch einige Server hinzukommen sollen, dachte ich, dass die https-shared zwar oversized im Moment, aber später übersichtlicher ist. Ich habe eben probeweise https-shared deaktiviert und das ursprüngliche https-fontend aktiviert. Aber das Ergebnis ist unverändert.

[viragomann]

@alcamar
Wir kennen immer noch nur einen Teil der Konfiguration. Ist diesem Frontend auch das SSL-Zertifikat zugewiesen?

Die Frage, ob die Paket überhaupt am Frontend ankommen, ist bislang auch noch unbeantwortet.

Versuchst du die Zugriffe vom Internet aus oder vom LAN?
Vom LAN aus wird das wahrscheinlich nicht funktionieren, es sei dem, du hast einen DNS Override, der auf die pfSense WAN IP zeigt.

[Alcamar]

@viragomann den webGUI Port meinte ich. Um auf die pfsense zu kommen, gebe ich deshalb den Namen der pfsense:neuerport ein, sonst klappt es nicht.

Bin noch auf der Suche der gesamten Konfiguration. In den Stats finde ich Session Total nicht. :-(

[Alcamar]

@viragomann
Im Frontend ist auch das eigens dafür erstellt Zertifikat zugewiesen.
Das kann man auch über die Konsole mit openssl testen. Ich glaube, dass der Test auch nicht sauber war. Aber müsste nicht wenigstens ein Zertifikatsfehler kommen, wenn das fehlerhaft wäre?

Die Zugriffe sind sowohl aus dem LAN als auch aus dem Internet gleich.
Rufe ich im LAN die IP-Adresse der cam auf, meldet die sich auch. Also die cam lässt sich ansprechen, nur nicht über das Internet

[Alcamar]

@alcamar openssl s_client -servername cam1.domain.de -host 192.168.1.247 -port 443 | grep subject
depth=0 O = Axis Communications AB, CN = axis-b8a56f07cd45
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Axis Communications AB, CN = axis-b8a56f07cd45
verify return:1
subject=/O=Axis Communications AB/CN=axis-b8a56f07cd45

[viragomann]

@alcamar
Wenn du keinen DNS Host Override eingerichtet hat, gehen Anfragen auf den öffentlichen Hostnamen auf die public IP, also auf die FritzBox.
Die leitet diese aber nicht zwingend auf die pfSense. Kenne deren Verhalten aber nicht.

openssl s_client -servername cam1.domain.de -host 192.168.1.247 -port 443 | grep subject
depth=0 O = Axis Communications AB, CN = axis-b8a56f07cd45
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Axis Communications AB, CN = axis-b8a56f07cd45
verify return:1
subject=/O=Axis Communications AB/CN=axis-b8a56f07cd45

Schön. Aber dass das Backend funktioniert, wissen wir schon.
Versuch es mal mit der Frontend IP.

[Alcamar]

@viragomann DSN Override such ich noch. Vermutlich habe ich diese nicht eingerichtet, weil es mir nichts sagt.

Mit Frontend-IP meinst Du die von der Fritz!Box, denke ich. Das ist das Ergebnis:
read:errno=0

Nur, damit ich nicht etwas falsches sage. Das ist nun die statische IP, die die Fritz!Box der pfSense verpasst hat, die ich auch als WAN -Adresse bezeichnen würde.

[viragomann]

@alcamar
Mit Frontend meine ich pfSense WAN IP, das HAproxy Frontend.

Nur, damit ich nicht etwas falsches sage. Das ist nun die statische IP, die die Fritz!Box der pfSense verpasst hat, die ich auch als WAN -Adresse bezeichnen würde

Von welcher sprichst du hier?
Ich hatte mich auf die openssl Abfrage bezogen, die sich offensichtlich auf das Backend richtet und damit nichts neues verrät.
Daher mal bitte diesen Befehl auf die pfSense WAN IP.