Letsencrypt mit lmn7

Sven · 7. Juli 2021 um 09:23

Hallo,

für externe Abfragen des AD (z.B. für WebUntis) benötige ich ein offizielles Zertifikat, z.B. von letsencrypt.
Funktioniert dehydrated auf dem lmn7-Server, es gibt ja weder einen Apache noch einen nginx, oder?
Wie macht ihr das?

Viele Grüße
Sven

Michael · 7. Juli 2021 um 10:26

Ich lasse alle LE-Zertifikate auf der OPNSense-FW erstellen und hole sie mir per Cronjob von dort … das funktioniert seit längerer Zeit absolut fehlerfrei.
Viele Grüße,
Michael

Tobias · 7. Juli 2021 um 15:28

Hallo Michael, hallo Sven,

(schon extrem blöd, dass ich immer noch im Header stehe als Head of Doku und von mir diese Frage kommt:)

hat denn irgendwo mal jemand dokumentiert, wie er (oder man allgemein) das zur Zeit am besten mit der lmn7 macht?

Es gibt sicher mehrere Möglichkeiten (so auch wie beim freeradius und ich weiß z.B. auch immer noch nicht, wo ich mein AD-Zertifikat überhaupt reinpacke… Und dann gibt es ja noch die, die intern und extern unterschiedliche Domains verwenden (intern etwas Lokales, extern etwas offiziell anerkanntes)
VG, Tobias

Michael · 7. Juli 2021 um 15:57

Hallo Tobias,
bei mir ist das „aus der Not heraus“ so gekommen – vor allem gerade weil ich damals die Option „interner FQDN = externer FQDN“ gewählt hatte und es dann diverse Probleme mit fehlenden Zertifikaten gab.

Da musste ich mir etwas einfallen lassen, wie ich die LE-Zertfikate am besten auf den Server bekomme. Was lag da näher, als den schon vorhandenen Service auf der OPNSense zu verwenden? Anleitung dazu z.B. hier: https://schulnetzkonzept.de/opnsense → ab „Anlage eines Let’s-Encrypt-Kontos“

Da ja auf dem v7-Server per default alles unter /etc/linuxmuster/ssl/ liegt und das bundle dort server.cert.bundle.pem heißt, habe ich es bei diesen Namen belassen.

Unter /etc/samba/smb.conf habe ich zudem diese Einstellungen gewählt:

tls keyfile = /etc/linuxmuster/ssl/server.key.pem
tls certfile = /etc/linuxmuster/ssl/fullchain.pem
tls cafile = /etc/linuxmuster/ssl/cacert.pem

Seitdem ist Ruhe und ich bekomme sowohl mit
openssl s_client -connect server:636 als auch mit
openssl s_client -connect server:443 eine gültige Chain.

Ich hatte übrigens irgendwann das Script, mit dem ich die Zertifikate von der OPNSense hole, schon mal hier veröffentlicht … Sekunde … ja, gefunden … hier war das:

hth – viele Grüße,
Michael

sedding · 8. Juli 2021 um 07:59

Hej,
@Michael und wir haben ein ganz ähnliches Setting (auch „interner FQDN = externer FQDN“) aber wir holen unsere Zertifikate tatsächlich direkt auf dem pädagogischen Server.

Hier mal (ziemlich ungefiltert) meine Notizen von damals, als ich das eingerichtet habe.

Notizen: Let’s Encrypt auf/ für pädagogischem Server

Auf dem pädagogischen Server läuft nur noch ajenti, kein anderer Webserver wie nginx oder apache. Deshalb kann man sich nicht ein Zertifikat von dehydrated holen lassen.

Der certbot braucht aber keinen eigenen webserver, weshalb man den verwenden kann.

Voraussetzung: Portweiterleitung

Zumindest für Port 80 muss auf der OpenSense eine Portweiterleitung zum Server eingerichtet werden

Certbot installieren und einrichten

Es reicht die Version aus den Paketquellen : sudo apt install certbot
Mit dem Befehl sudo certbot certonly --standalone wird certbot eingerichtet, es werden einige Informationen (E-Mailadresse für Warnungen und natürlich servername für das Zertifikat) abgefragt
Zudem wird ein cronjob angelegt (in /etc/cron.d/certbot). Um zu überprüfen ob alles geklappt hat, kann man sudo certbot renew --dry-run ausführen

Zertifikate verschieben

Die Zertifikate werden /etc/letsencrypt/live/<servername> abgelegt.

Die WebUI benötigt ein Bundle aus privkey und fullchain. Deshalb:
cat fullchain.pem privkey.pem > server.le.cert.bundle.pem
(Reihenfolge stimmt so…)

Samba dagegen braucht die Einzeldateien. Siehe unten…

Zunächst müssen die Zertifikate an den richtigen Ort kopiert werden:

cd /etc/letsencrypt/live/server.MEINE-SCHULE.de/
cat fullchain.pem privkey.pem > /etc/linuxmuster/ssl/server.le.cert.bundle.pem
cp privkey.pem /etc/linuxmuster/ssl/server.le.privkey.pem
cp fullchain.pem /etc/linuxmuster/ssl/server.le.fullchain.pem
cp chain.pem /etc/linuxmuster/ssl/server.le.chain.pem

chown root:ssl-cert /etc/linuxmuster/ssl/server.le*
chmod 640 /etc/linuxmuster/ssl/server.le*
chmod 600 /etc/linuxmuster/ssl/server.le.privkey.pem

Das Ganze kann in einen Deploy-Hook für certbot: /etc/letsencrypt/renewal-hooks/deploy/copy_certs.sh. Angepasste Version von hier

Edit 2021-01: Es muss nach dem renewal nicht nur die WebUI sondern auch Samba neu gestartet werden:

# Restart WebUI && Samba
systemctl restart linuxmuster-webui
systemctl restart samba-ad-dc.service

Zertifikate scharfschalten.

In der WebUI als gobal-admin unter Einstellungen > globale Einstellungen das bundle eintragen (server.le.cert.bundle.pem). Das setzt einen Eintrag in /etc/ajenti/config.yml
Danach die WebUI neu starten: systemctl restart linuxmuster-webui
/etc/samba/smb.conf.admin editieren

  tls keyfile = /etc/linuxmuster/ssl/server.le.privkey.pem
  tls certfile = /etc/linuxmuster/ssl/server.le.fullchain.pem
  tls cafile = /etc/linuxmuster/ssl/server.le.chain.pem

chain.pem nach var/lib/samba/sysvol/[FQDN]/tls kopieren und in cacert.pem umbenennen
Linuxmuster-client-adsso funktioniert nicht (mehr) - #5 von foer
Danach
1. macct-Datei löschen
2. linuxmuster-client-adsso-setup auf dem Masterclient ausführen
3. Image schreiben

Der letzte Schritt bezieht sich auf den alten Linuxclient - Nicht mehr beachten…

Grüße
Michael

sedding · 8. Juli 2021 um 08:02

Achso und hier noch unsere angepasste Version des copy_certs-Skrips.

#!/bin/bash
#set -x

################################################
# Scriptname :    copy_certs.sh
# Author     :    Michael_Hagedorn, Michael Sedding
# Date       :    2020-09-05
# Category   :    geeignet für linuxmuster 7.x
# Version    :    VER='1.2'

# Dieses Script kopiert die vom certbot erstellten Zertifikatsdateien in das Standard-LMN-Verzeichnis für Zertifikate.
# Anschließend wird die WebUI neu gestartet, so dass eine gesicherte Verbindung zum Server mit gültigem Zertifikat möglich ist.
# Das Skript sollte beim von certbot als "deploy-hook" aufgerufen werden.
# Dafür sollte es reichen, das Script in /etc/letsencrypt/renewal-hooks/deploy/ abzulegen
# Altenativ kann man auch den Cronjob anpassen.  /etc/cron.d/certbot ist so anzupassen:
# 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew --deploy-hook /path/to/the/script/copy_certs.sh

################################################

#Variablen:
host="server.MEINE-SCHULE.de"
servername="server"
domain="MEINE-SCHULE.de"
lepath="/etc/letsencrypt/live/"
lmncertpath="/etc/linuxmuster/ssl"
filenameprefix="server.le"
#cloopname="lmn-bionic-200507"

# Let's go:
cd $lepath/$host/

# Make bundle for ajenti
cat fullchain.pem privkey.pem > $lmncertpath/$filenameprefix.cert.bundle.pem

# Make copies of the relevant files for samba
cp fullchain.pem $lmncertpath/$filenameprefix.fullchain.pem
cp chain.pem $lmncertpath/$filenameprefix.chain.pem
cp privkey.pem $lmncertpath/$filenameprefix.privkey.pem

# Make copies of the CA-certificate for the client
cp chain.pem /var/lib/samba/sysvol/$domain/tls/cacert.pem
#if [ ! -d "/srv/linbo/linuxmuster-client/$cloopname/common/var/lib/samba/private/tls/" ]; then
#  mkdir -p /srv/linbo/linuxmuster-client/$cloopname/common/var/lib/samba/private/tls/
#fi
#cp chain.pem /srv/linbo/linuxmuster-client/$cloopname/common/var/lib/samba/private/tls/$domain.pem

# Adjust group and filepermissions
chown root:ssl-cert $lmncertpath/$filenameprefix.*
chmod 640 $lmncertpath/$filenameprefix.cert.bundle.pem
chmod 640 $lmncertpath/$filenameprefix.fullchain.pem
chmod 640 $lmncertpath/$filenameprefix.chain.pem
chmod 600 $lmncertpath/$filenameprefix.privkey.pem

# Restart WebUI && Samba
systemctl restart linuxmuster-webui
systemctl restart samba-ad-dc.service


#EOF

Christoph · 11. Juli 2021 um 18:34

Hallo zusammen,

interessantes Thema. Bei uns steht der Umstieg auf die LMN7 in den Sommerferien an. Bislang entspricht bei unserer alten LMN6-Installation die interne der externen Domäne, was insbesondere hinsichtlich der Namensauflösung immer wieder Probleme mit sich gebracht hat. Allerdings benötigen wir für den LDAP ein gültiges SSL-Zertifikat, was sich aber über die OPNSense regeln lassen würde.

Jetzt steht eine Neuinstallation an und wir stehen vor genau dieser Frage: Interne = Externe Domäne oder nicht?!?

Was spricht aus eurer Sicht dafür, was dagegen?

Viele Grüße
Christoph