Hallo.
Ich habe meine OPNSense-FW nun soweit, dass sie per LE gültige Zertifikate holen kann. Das funktioniert nun auch bereits soweit, dass in der DMZ alle Dienste (wie z.B. moodle, nextcloud … ) das Zertifikat vom Reverse Proxy verwenden. Man muss also nichts mehr hin- und herkopieren sondern lässt einfach alles direkt die FW bzw HAProxy erledigen. So hatte ich mir das vorgestellt…
Was noch nicht klappt: Die Anfragen an den Server im LAN laufen im Moment noch nicht über den RevProxy. Da überlege ich, ob ich das LE-Zertifikat nicht doch von der Firewall rüber kopieren sollte??
Ist es richtig, dass ajenti/python einfach das Zertifikat aus dem Ordner /etc/linuxmuster/ssl verwendet? Reicht es also, wenn man dort ein aktuelles, eigenes Zertifikat hinterlegt und die WebUI neu startet oder muss man weitere Schritte bedenken??
Das Zertifikatpfad soll in die Konfiguration von Ajenti geschrieben sein.
Hast du, als global-admin i ndie Webui, links unten einen Eintrag „Globale Einstellungen“ ?
Da kann man es eintragen.
Danach das übliche systemctl restart linuxmuster-webui
So verwende ich seit mindestens einem Jahr ein Wildcard LE-Zert. mit der Webui.
Hallo Arnaud.
Super – danke!
Da das so einfach ist, habe ich ein kleines Script geschrieben, das mir das Zertifkat von der OPNSense-FW holt. So geht es hier am schnellsten und ich muss den Reverse Proxy nicht weiter konfigurieren.
Vielleicht kann’s jemand gebrauchen (ich ändere daher den Betreff wie üblich zu „HowTo“):
#!/bin/bash
#set -x
#######################################################################################################
# Scriptname : LE_server_crt.sh
# Author : Michael Hagedorn
# Date : 2019-22-11
# Category : geeignet für linuxmuster 7.x
#Version :
VER='1.0'
# Dieses Script holt ein (gültiges) LE-Zertifikat per scp von der OPNSense-FW und legt es auf
# dem lmn.70-Server ab. Anschließend wird die WebUI neu gestartet, so dass eine gesicherte
# Verbindung zum Server mit gültigem Zertifikat möglich ist.
# Die hier verwendeten Pfade setzen voraus, dass die LE-Zertifikate von der OPNSense-FW
# selbst verwaltet werden.
# Voraussetzung ist zudem, dass der passwortlose Zugang vom Server zur Firewall funktioniert (default)
# Das Script muss auf dem lmn.70-Server laufen und kann per cronjob aufgerufen werden.
#########################################################################################################
#Variablen:
certs="/etc/linuxmuster/ssl"
hosts="server.<hier_deine_domain_eintragen.de>"
#Der Name ist in der WebUI eingetragen (Login als global-admin) --> Einstellungen --> Globale Einstellungen
bundlename="server.cert.bundle.pem"
#Scriptpfad (kann auskommentiert werden):
filename="${0##*/}"
scriptpath=`pwd -P`
echo "Script: $scriptpath/$filename "
echo
#Let's go:
cd $certs
#RSA-Key und Cert kopieren und zu einer Datei zusammenfügen.
#Anschließend Rechte aendern und Service neu starten
scp firewall:/var/etc/acme-client/home/$hosts/$hosts.key .
scp firewall:/var/etc/acme-client/home/$hosts/$hosts.cer .
chmod 600 $hosts.*
cp $bundlename $bundlename.old
cat $hosts.key $hosts.cer > $bundlename
chown root:ssl-cert $bundlename
systemctl restart linuxmuster-webui
# Die https:// Verbindung zum Server sollte jetzt ein gültiges Zertifkat haben
# und keine Warnung mehr ausgeben!
#EOF
(Ergänzung: Das Verfahren ist natürlich nur dann sinnvoll, wenn man für den Server einen FQDN gewählt hat…)
Du meinst das Setup, wie ich die LE-Zertifikate direkt von der OPNSense-FW erzeugen lasse? Das ist bereits gut dokumentiert. Ich bin der Anleitung unter https://schulnetzkonzept.de/opnsense gefolgt. Das hat mich zwar echt Nerven und Zeit gekostet – aber läuft jetzt Ein besonderer Dank geht an dieser Stelle auch nochmal an Thomas Mayer, der auf seiner Seite alles aufgeschrieben hat.
Wir haben die Diskussion warum welcher Service jetzt wo laufen soll, ja schon öfter geführt. Ich habe mich nun für uns so entschieden, dass die OPNSense FW direkt als RevProxy läuft und zudem auch für die LE-Zertifkate zuständig ist. Ich halte das für sinnvoll; lasse mich aber gerne eines besseren belehren. Wenn man das per docker macht, kommt wieder eine Schicht dazu, die uU unnötige Kompexität in die Sache bringt – jonny (liest er hier eigentlich noch mit?) würde graue Haare bekommen …
Dachte ich mir – habe es aber möglichst auf default gelassen, um keine Änderungen vorzunehmen, von denen man später nicht mehr weiß warum und wieso das jetzt anders heißt als zuvor.
Ja, ist schon richtig – ich bin mit dem Setup nun aber vom Standard abgewichen. Weiß nicht, ob andere da folgen wollen/sollten? Eigentlich wird weiterhin die docker-Lösung präferiert, oder?
Michael
Ja, richtig.
Andererseits seh ich zwei Knackpunkte: gegen RevProxy+LE auf opnSense spricht das one task-one tool prinzip. Je nach Szenario was hinter dem RevProxy kommt, kann der TRafik die OpnSense stark beanspruchen - wenn das auf einem extra docker läuft, dann wird die OpnSense für ihre anderen Aufgaben freier gehalten, sozusagen off-loading der RevProxy-Funktionalität.
Dafür spricht natürlich, dass sowieso schon mehrere tasks auf dem einen tool=opnsense laufen und dass die Firewall von überall erreichbar ist, genau so wie man es mit moodle, nextcloud etc. auch haben will…
Die LE-Frage kann man mal wieder diskutieren und einen Weg als STandard vorschlagen. Aber es ist klar, dass es ganz oft andere Wege geben wird.
Für mich persönlich ist es (wie immer) bequemer, ich skripte etwas auf einem altbekannten Linuxsystem, anstatt dass ich etwas über eine GUI auf einem weniger bekannten Unixsystem mache.
Was allerdings nicht heißt, dass die supportete STandardverfahren nicht doch besser die GUI-Variante sein sollte.
Letztenndes kann das Doku Team hier auch nur Empfehlungen abgeben.
Mit Letsencrypt hab ich bei vielen Hosts einfach immer das Problem, dass ich die Zertifikate verteilen muss, was hier der Ursprungsort ist, ist dann erst einmal egal.
Andere wiederum kaufen ein Wildcard Zertifikat und arbeiten damit.
Hi Tobias … ja, es hängt sehr vom Szenario ab. Wir haben ja bereits gehört, dass u.U. auch sophos die bessere Wahl sein kann, wenn man das nötige Kleingeld investieren möchte.
Bei mir ist regelt der HAProxy nun alle Zugriffe auf die DMZ: alle Zugriffe auf Port 80/443, die von außen kommen, werden (so wie in der o.g. Anleitung beschrieben) auf zwei virt. IP-Adressen umgeleitet, die dann an VMs/Services verteilen, die sich in der DMZ befinden. Alles, was unverschlüsselt auf Port 80 reinkommt, wird zudem auf 443 umgeleitet.
Was zusätzlich noch hinzukommt: Alle Zugriffe von innen gehen auch direkt auf den HAProxy – also ohne erst nach draußen geroutet werden zu müssen. Das funktioniert hier seit ein paar Tagen problemlos — und ich fand das Konzept durchdacht .
Zudem wird HAProxy bei diversen Vergleichen häufig als „der Mercedes unter den LoadBalancern/RevProxies“ bezeichnet, so dass ich mir gut vorstellen kann, dass der die „paar“ Zugriffe auf die DMZ schon wird verteilen können?!
Letztes Argument: Wenn du docker verwendest, musst du den docker-Container auch mit ordentlich Dampf unter der Haube ausstatten – kann man dann nicht auch gleich der FW selbst mehr Ressourcen spendieren?
Und noch ein Wort in Sachen Let’sEncrypt: Gerade da finde ich das Zusammenspiel von HAProxy mit LE sehr gut: Man muss überhaupt nichts mehr auf irgendwelche Server in der DMZ kopieren, da die Anfragen zunächst an die FW gehen und sie dann das Zertifikat ausliefert. Ist doch top!?
Ich habe das Script nochmal überarbeitet … hier die aktuelle Version.
#!/bin/bash
#set -x
#######################################################################################################
# Scriptname : LE_server_crt.sh
# Author : Michael Hagedorn
# Date : 2020-27-02
# Category : geeignet für linuxmuster 7.x
#Version :
VER='1.1'
# Dieses Script holt ein (gültiges) LE-Zertifikat per scp von der OPNSense-FW und legt es auf
# dem lmn.70-Server ab. Anschließend wird die WebUI neu gestartet, so dass eine gesicherte
# Verbindung zum Server mit gültigem Zertifikat möglich ist.
# Die hier verwendeten Pfade setzen voraus, dass die LE-Zertifikate von der OPNSense-FW
# selbst verwaltet werden.
# Voraussetzung ist zudem, dass der passwortlose Zugang vom Server zur Firewall funktioniert (default)
# Das Script muss auf dem lmn.70-Server laufen und kann per cronjob aufgerufen werden.
#########################################################################################################
#Variablen:
certs="/etc/linuxmuster/ssl"
hosts="server.<hier_deine_domain_eintragen.de>"
short="server"
#Der Name ist in der WebUI eingetragen (Login als global-admin) --> Einstellungen --> Globale Einstellungen
bundlename="server.cert.bundle.pem"
#Scriptpfad (kann auskommentiert werden):
filename="${0##*/}"
scriptpath=`pwd -P`
echo "Script: $scriptpath/$filename "
echo
#Let's go:
cd $certs
#Safety first:
mv $bundlename $bundlename.old
mv $short.* ./backup/
mv cacert.crt ./backup/
mv cacert.pem ./backup/
mv fullchain.cer ./backup/
#RSA-Key und Cert kopieren und zu einer Datei zusammenfügen.
#Anschließend Rechte aender und Service neu starten
scp firewall:/var/etc/acme-client/home/$hosts/$hosts.cer ./$short.cert.pem
scp firewall:/var/etc/acme-client/home/$hosts/$hosts.csr ./$short.csr
scp firewall:/var/etc/acme-client/home/$hosts/$hosts.key ./$short.key.pem
scp firewall:/var/etc/acme-client/home/$hosts/ca.cer ./cacert.crt
scp firewall:/var/etc/acme-client/home/$hosts/ca.cer ./cacert.pem
scp firewall:/var/etc/acme-client/home/$hosts/fullchain.cer .
chmod 600 $short.key.pem
chmod 640 cacert.crt cacert.pem $short.cert.pem $short.csr fullchain.cer
chown root:ssl-cert $short.* cacert.* fullchain.cer
# Reihenfolge entscheidend! Vgl.: https://blog.syseleven.de/zertifikate-und-zertifikatsketten/
cat fullchain.cer $short.key.pem> $bundlename
chown root:ssl-cert $bundlename
systemctl restart linuxmuster-webui
#EOF
vielen Dank für deine Anleitung und dein Skript. Mittlerweile hole ich auch das Zertifikat für den Server durch die OPNSense und kopiere es anschließend auf den Server. Dabei habe ich noch eine kleine Ergänzung vorgenommen, die das Erneuern des Zertifikats anstößt:
Hallo Steffen,
ich bin damals ziemlich genau nach der Anleitung unter OPNsense - Router - schulnetzkonzept.de → Installation und Konfiguration des HAProxy-Plugins vorgegangen. Der HAProxy ist nicht ganz ohne, da man super viele Einstellungsmöglichkeiten hat. Aber seitdem ich das nach Anleitung gemacht habe, läuft es hier zuverlässig und ich bin froh, dass es direkt auf der OPNSense funktioniert. Viele verwenden ja stattdessen einen (vermutlich leichter zu konfigurierenden) NGINX … aber ich würde es erstmal mit der Anleitung versuchen.
Viele Grüße,
Michael
Ach so – ok: ich habe die bei uns in die DMZ gepackt. Das „orange“ Netz hat hier die Maske 172.17.17.0/24
Da die OPNSense in diesem Netz die Adresse .254 besitzt, habe ich für die Aliase die beiden Adressen
HAProxy_DMZ 172.17.17.253
HAProxy_DMZ_WAN 172.17.17.252
gewählt.
Man muss bei der Anleitung dann entsprechend aufpassen, dass man das überall an diese Adressen anpasst… auf der Webseite werden andere Adressen verwendet.
Hilft das weiter?
Michael
Ich habe bis jetzt nur Lan WAN und opt1 für Wlan eingerichtet. Ist es sinnvoll noch eine DMZ einzurichten? Eigentlich wollte ich den haproxy nur für die Erzeugung der Letsencrypt Zertifikate nutzen.
Viele Grüße
Steffen
Das kann ich nicht pauschal beantworten, da ich Euer Netz nicht kenne … ich hatte das damals so gemacht, dass ich ein Extra-Netz für alle Dienste, die von außen erreichbar sein sollen, eingerichtet habe. Der Vorteil ist natürlich, dass man dieses Netz relativ restriktiv einstellen kann und dass alle Anfragen, die von außen kommen, dann gegen den HAProxy laufen. Nachteil ist die höhere Komplexität. Wir haben in „orange“ die Nextcloud, den Tabula-Server, den Mailcow-eMail-Dienst, das MDM, einen Webserver für div. kleinere Dienste. Von daher hat sich das eigene Netz bei uns schon gelohnt, meine ich…
… außerdem ist das in der OPNSense ja auch schnell eingerichtet, sofern Du noch genügend Netzwerkkarten frei hast. Oder ist die OPNSense eh virtualisiert? Dann hast Du ja freie Auswahl…
Ein besonderer Dank geht an dieser Stelle auch nochmal an Thomas Mayer, der auf seiner Seite alles aufgeschrieben hat.
.