ajenti-Server / WebUI gültiges LE-Zertifikat geben (HowTo)

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… :+1:

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??

Schöne Grüße,
Michael

Hallo MIchael,

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.

Gruß

Arnaud

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…)

Schöne Grüße,
Michael

Hallo Michael!

Hast Du dein Setup dokumentiert oder noch besser würdest du dem D-Team (Dokumentation) eine Anleitung mit Screenshots schreiben?

Besten Dank und liebe Grüße

Thorsten

Hallo Michael,

Gut, dass es geklappt hat. Der Name server.cert.bundle.pem ist nicht pflicht, das kann auch /opt/mybesondersSSL/Pythagoras.pem sein :wink:

Gruß

Arnaud

Hallo zusammen.

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 :+1: 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.

Die Anspielung

habe ich natürlich verstanden :slight_smile: :slight_smile:

Schöne Grüße,
Michael

Hallo Michael!

Genau das ist das, was mich antreibt mit meiner Anfrage. Wenn einer schon über die Steine gestolpert ist, warum diese nicht gleich aus dem Weg räumen?

Habe gerade ein Déjà-vu. Hatten wir diese Diskussion nicht schon einmal.

Liebe Grüße

Thorsten

Hi Thorsten.

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

Hi Michael und Thorsten,

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.

weiterhin open for diskussion

VG, Tobias

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 :thinking:.

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!? :thinking:

Schöne Grüße,
Michael