OPNsense Cluster und Let's Encrypt Zertifikate

Started by TheExpert, Today at 07:19:54 AM

Previous topic - Next topic
Hallo zusammen,

ich baue gerade einen OPNsense Cluster auf, auf dem ich auch ein Let's Encrypt Zertifikat einbinden möchte. Grundsätzlich weiß ich, wie das umgesetzt wird. Aber ich frage mich, wie man das auf einem Cluster umsetzt?

Die Zertifikate können im Rahmen der Synchronisation auf den Backup-Knoten kopiert werden, so dass die Einrichtung des ACME Clients nur auf dem primären Knoten ausreichend sein müsste, richtig? Was aber ist, wenn der primäre Knoten für längere Zeit nicht verfügbar ist und das Let's Encrypt Zertifikat genau in dieser Zeit abläuft und dann nicht automatisch erneuert wird? Es ist eine sehr theoretische Frage, weil das Zertifikat vermutlich sehr rechtzeitig erneuert wird - zumindest war das bei der Sophos UTM so. Der Fall des abgelaufenen Zertifikates sollte eigentlich nicht auftreten, aber wir wissen alle, dass es immer zu dummen Umständen kommt, die dann doch genau solche eigentlich unwahrscheinlichen Fälle hervorbringen.

Oder muss ich auf dem Backup-Knoten den ACME Client konfigurieren, um dort das Zertifikat auch automatisch regelmäßig zu erneuern? Dann aber stellt sich die Frage, ob man überhaupt 2 Zertifikate für den gleichen Domainnamen anfordern kann? Letztere Frage stellt sich mir außerdem, weil meine Sophos UTM noch läuft und ich in der Migrationsphase zu OPNsense bin.

Im Internet finde ich immer nur die grundsätzliche Beschreibung zur Einrichtung von Let's Encrypt in der OPNsense, aber nirgendwo wird auf die Einrichtung auf einem Cluster eingegangen - zumindest habe ich dazu bisher nichts gefunden.

Vielen Dank und viele Grüße

TheExpert

Du kannst ein Multidomain-Zertifikat mit mehreren SAN (Subject Alternate Names) per Letsencrypt ausstellen lassen. Dazu musst du allerdings für die Authentifizierung das DNS-Verfahren anstelle des HTTP-Verfahrens verwenden.

Und dann packst du in das Zertifikate z.B.

- node1.meincluster.com
- node2.meincluster.com
- carpaddr.meincluster.com

Oder gleich ein Wildcard-Cert für *.meincluster.com - geht auch.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Vielen Dank. Dann benötige ich für jede WAN-Adresse der OPNsense einen öffentlichen FQDN, richtig? Ich habe derzeit nur eine DynDNS-Domain, für die ich über die Sophos UTM ein Let's Encrypt Zertifikat verwalten lasse.

Du brauchst einen FQDN für jeden Namen, unter dem du die Firewalls ansprechen willst. Also wenn es nur "carp.mycluster.de" sein soll, dann ist auch gut. Wieso DynDNS? Du brauchst doch je eine feste und dann eine gemeinsame CARP-Adresse für einen Cluster?

Also - du kannst eintragen was du willst, und die Domain und die IP-Adresse müssen nicht miteinander verknüpft sein, so lange du die DNS- statt der HTTP-Challenge benutzt. Das ist der wesentliche Teil. Ob es nur ein Name wird oder drei ist wurst.

Für die DNS-Challenge musst du den ACME-Client benutzen und du brauchst einen unterstützten DNS-Dienst, damit die Challenge-Responses dynamisch im DNS eingetragen werden können. Ich verwende einen selbst gehosteten ACME-DNS-Server für sowas.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Today at 10:51:41 AM #4 Last Edit: Today at 11:26:30 AM by TheExpert
Ich nutze DynDNS, da ich keine feste öffentliche IP-Adresse habe (privater DSL-Anschluss). Der Anschluss terminiert an einer FritzBox, hinter der dann die Firewall als exposed Host steht. Die Firewall hat feste IP-Adressen im Transfernetzwerk zwischen Firewall und FritzBox.

Für einen Zugriff von außen benötige ich nur einen öffentlich erreichbaren FQDN und das Let's Encrypt Zertifikat, die ich auf die CARP-VIP binde.

Und mir ist immer noch nicht klar, wie ich das nun im Cluster konfiguriere: Auf beiden oder nur auf dem primären Knoten?

Mit DNS Challenge auf beiden. Oder mit HTTP Challenge nur auf dem Primary und dann Replikation der Zertifikate über XML-Sync per Cron Job.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

OK, danke. Ich teste das mal. Wie sehe ich denn, ob die eingerichtete Challenge funktioniert?

Ein Zertifikat wird ausgestellt ;-)

Details im Logfile vom ACME-Client.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

So, jetzt bin ich einen Schritt weiter, aber noch nicht am Ziel. Der TXT für die DNS-Challenge wird eingetragen: The TXT record has been successfully added. Aber dann kann der ACME-Client bisher nicht den TXT-Eintrag verifizieren und somit das Zertifikat nicht anfordern oder erneuern.

Dieser TXT-Eintrag dient ja nur zur Verifizierung der DNS-Challenge, richtig? D. h. der Backup-Firewall-Knoten kann die Challenge auf den gleichen TXT-Record machen, oder? Ich hatte nämlich ursprünglich 2 TXT-Records hinterlegt (_acme1, _acme2), aber der ACME-Client will immer den Record mit dem Namen "_acme-challenge" verwenden. Daher habe ich nun nur noch den TXT-Record "_acme-challenge" angelegt.

Genau, beide verifizieren denselben TXT-Eintrag. Bzw. Letsencrypt verifiziert, dass der da ist, und das richtige enthält.

Mit _acme-challenge.meinedomain.de kannst du ein Zertifikat für "*.meinedomain.de" ausstellen. Das läuft dann auf beiden Firewalls, egal wo "opnsense.meinedomain.de" gerade hin zeigt. Wildcard ist besser, weil alle ausgestellten Zertifikate ja in einer öffentlichen Datenbank landen. Den eigenen FQDN also nicht im Zertifikat zu haben verkleinert die Angriffsfläche.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)