Überlistet 
Hej Frank,
Ja, jetzt klappts… Hatte mich schon gewundert und den Link nochmal hinter einen Text gepackt. Hast Du das nun serverseitig zugelassen, oder warum tut’s nun?
Zurück zum Thema und zu einer Frage, die auch die anderen interessieren könnte: Benutzt Du die hook.sh?
Ein Apache-Neutstart ist doch nur notwendig, wenn die Konfig geändert wurde und nicht, wenn einfach ein neues Zertifikat geholt wurde…?
Grüße
Michael
Das unsichere Element war der Film selbst, der wurde auf er CCC-Seite von einem weiteren Server als http eingebunden. Ich habe die Film URL genommen und aus http https gemacht, drum ist Discourse jetzt zufrieden.
Ich glaube der apache liest beim Start die Zertifikate, drum restarte ich den bei erneuertem Zertifikat. So schlägt es auch die Doku von dehydrated vor. Ich vermute, dass es nicht wirklich schlimm wäre, wenn mans nicht tut, aber apache Prozesse die mit dem alten Zertifikat laufen würden wohl mosern. Keine Ahnung…
Hi.
Ich würde das auch gerne einsetzen, um intern ein gültiges Zertifikat zu haben – allerdings will ich den Server nicht wirklich 24/7 nach außen hin erreichbar machen; und schon gar nicht über Port 80.
[etwas später… Ah, ok! Habe gerade die Anleitung bis ganz unten gelesen. Scheint ja kein Problem zu sein!)
Also ich habe das jetzt installiert, und es hat wirklich reibungslos geklappt. In der Doku ist an einer Stelle noch ein Tippfehler ( /cert/ statt /certs/), aber das war es auch schon.
Ich bin jetzt gespannt, ob in 3 Monaten mit der automatischen Erneuerung - und vor allem mit der von mir in der hook.sh erstellten automatischen Übertragung auf einen anderen Server - alles glatt geht…
Bis hierhin also tausend Dank, wie immer konnte ich mich auf linuxmuster.net 100% verlassen!
LG Alex
1 „Gefällt mir“
Du musst ja deine Dienste nicht über 80 erreichbar machen. Wenn der apache oder deine WebApp ein Loch hat bist du über 443 genauso angekäst wie über 80, nur dass der Angriff dann über den verschlüsselten Draht kommt 
Wenn du ganz paranoid bist, kannst du natürlich den Cronjob anpassen, dafür ist das Skript /etc/cron.daily/linuxmuster-dehydrated zuständig. Du kannst dort die apache Konfiguration anpassen, so dass er auf 80 hört, dann den apachen restarten, das Zertifikat checken, den Port 80 wieder deaktivieren, apache neu starten. Ich halte das für sehr paranoid, aber wer weiß, die Russen 
und wenn du deinen Server sonst nach draußen gar nicht offen hast und nur ein Zertifikat für die Schulkonsole haben willst, why not. Wahrscheinlich muss noch das eine oder andere sleep 5 dazwischen, aber sonst sollte das gehen.
Die Ports des Apachen konfiguriert man in /etc/apache2/ports.conf , da kannst du den 80er rein und rausnehmen, dann ist die Portweiterleitung auf dem IPfire auch wurscht, weil auf deinem Server nichts mehr auf 80 hört.
VG
Frank
Gefixt, danke.
Hey,
ich habe es jetzt auch mal erfolgreich getestet und ein paar kleinigkeiten in github hochgeladen.
zum Testen kann man:
#CA="https://acme-staging.api.letsencrypt.org/directory"
#CA_TERMS="https://acme-staging.api.letsencrypt.org/terms"in die config einfügen, auskommentiert, allerdings muss man dafür extra --register aufrufen…
Noch den Vorschlag, von Dominik entnommen, der das mit Hilfe von cert-bot-auto: anwenderwiki:server:ssl-tls-letsencrypt [CommunityWiki] gemacht hat, „server.pem“ direkt zu schreiben, weil es dann gleich verwendet wird von slapd,cyrus und apache2
#!/bin/bash
if [ ${1} == "deploy_cert" ]; then
echo " + Hook: Deploying to Apache/slapd/cyrus... $1"
TARGETDIR=/etc/ssl/private
echo " + Sichere altes Zertifikat"
cp -a $TARGETDIR/server.pem $TARGETDIR/server.pem_$(date +%Y%m%d.%H:%M)
echo " + Kopiere neues Zertifikat nach $TARGETDIR"
cat "$3" > $TARGETDIR/server.pem
cat "$5" >> $TARGETDIR/server.pem
chmod 0640 $TARGETDIR/server.pem
chown root:ssl-cert $TARGETDIR/server.pem
echo " + Restart services"
service apache2 reload
service slapd restart
service cyrus-imapd reload
# Beispiel, um es auf einen anderen Webserver zu kopieren:
#echo " + Copy to cloudserver"
#rsync -avP $TARGETDIR/server.pem cloud:/etc/ssl/private/server.pem
#ssh cloud service apache2 reload
else
echo " + Hook: Nothing to do... $1"
fivG, Tobias
Hai,
Sieht nicht übel aus 
ich hab dich als Mitarbeiter für das Repo eingeladen, kannst du das bei Gelegenheit reinpushen, testen und mir Bescheid geben wenn es tut Dann bau ich ein aktualisierten Paket und leg das aus.
VG
Frank
Hi,
ich hab jetzt das mal umgesetzt, da ich den server selbst nicht als webserver nach draußen verwenden will. 443 geht auf einen anderen server, daher: port 80 auf, challenge → validation, port zu:
Ich hab jetzt die hook.sh der Vorlage vom entwickler genommen.
deploy_challenge() {
local DOMAIN="${1}" TOKEN_FILENAME="${2}" TOKEN_VALUE="${3}"
source $CONFIG
if [ "x$DEACTIVATE_PORT80" = "xyes" ]; then
if ! grep "^Listen 80" /etc/apache2/ports.conf >/dev/null 2>&1; then
echo " + Activating Apache on port 80"
echo "Listen 80" >> /etc/apache2/ports.conf
service apache2 reload
fi
fi
}
deploy_cert() {
local DOMAIN="${1}" KEYFILE="${2}" CERTFILE="${3}" FULLCHAINFILE="${4}" CHAINFILE="${5}" TIMESTAMP="${6}"
echo " + Deploying to Apache/slapd/cyrus..."
# TARGET in the standard linuxmuster.net-installation
TARGETDIR=/etc/ssl/private
echo " + Sichere altes Zertifikat"
cp -a $TARGETDIR/server.pem $TARGETDIR/server.pem_$TIMESTAMP
echo " + Kopiere neues Zertifikat nach $TARGETDIR"
## put all in one:
cat "$KEYFILE" > $TARGETDIR/server.pem
cat "$FULLCHAINFILE" >> $TARGETDIR/server.pem
chmod 0640 $TARGETDIR/server.pem
chown root:ssl-cert $TARGETDIR/server.pem
echo " + Restart services"
service apache2 reload
service slapd restart
service cyrus-imapd reload
}
exit_hook() {
source $CONFIG
if [ "x$DEACTIVATE_PORT80" = "xyes" ]; then
if grep "^Listen 80" /etc/apache2/ports.conf >/dev/null 2>&1; then
echo " + Deactivating Apache on port 80"
sed "/^Listen 80/d" -i /etc/apache2/ports.conf
service apache2 reload
fi
fi
}
HANDLER="$1"; shift
if [[ "${HANDLER}" =~ ^(deploy_challenge|clean_challenge|deploy_cert|unchanged_cert|invalid_challenge|request_failure|exit_hook)$ ]]; then
echo " + Hook $HANDLER..."
"$HANDLER" "$@"
fiDabei hab ich noch die /etc/linuxmuster-dehydrated/config aufgebohrt mit folgendem Switch:
DEACTIVATE_PORT80="yes"
Schien in meinen Tests erfolgreich zu laufen. Ich warte jetzt mal 60 Tage ab, bis cron die automatische Aktualisierung versucht…
VG, Tobias
Hallo Tobias,
Muss ich für die automatische Weiterleitung des (neuen) Zertifikats an einen anderen Server (z.B. cloudserver) noch irgendwelche zusätzlichen Einstellungen vornehmen? Oder reicht der Befehl, wie du ihn gepostet hast?
VG Daniel
Hallo Daniel,
das hängt natürlich von deiner Verbindung server -> cloud-server ab.
Bei mir im Beispiel wuerde der cloudserver “cloud” heissen und ein passwortloses einloggen von root zu root muss gewaehrleistet sein.
Dann: ja dann funktioniert der befehl (du musst aber die kommentarzeichen entfernen)…
tatsaechlich sieht es so aus bei mir:
…
chmod 0640 $TARGETDIR/server.pem
chown root:ssl-cert $TARGETDIR/server.pem
echo " + Restart services"
service apache2 reload
service slapd restart
service cyrus-imapd reload
echo " + Copy to cleese, restart apache2 there"
rsync -avP $TARGETDIR/server.pem cleese:/etc/ssl/private/server.pem
ssh cleese service apache2 reload
echo " + Copy to ipfire, restart pound there"
rsync -avP $TARGETDIR/server.pem ipfire:/etc/ssl/certs/server.pem
ssh ipfire /etc/init.d/pound restart
Hallo Tobias,
Einloggen von root nach root mit Passwort funktioniert bei mir. Wie schaffe ich das passwortlos?
VG Daniel
Hallo Daniel,
passwortlos funktioniert so: private/public-key (gibt es schon), dann wird der public-key auf den Ziel-rechner in die Datei “.ssh/authorized_keys” kopiert werden.
Es gibt ein Befehl der das macht:
cd /root
ssh-copy-id -i .ssh/id_ecdsa.pub target-rechner:
Now try logging into the machine, with "ssh 'target-rechner'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Dann sollte es funktionieren.
VG, Tobias
19 Beiträge wurden in ein neues Thema verschoben: Zertifikat für Subdomain mit linuxmuster-dehydrated klappt nicht?
Hi @Tobias
Ich habe gerade deine hook.sh benutzt, damit die Zertifikate direkt an die richtige Stelle kopiert werden und die entsprechenden Dienste neu gestartet werden. Dabei kam heraus:
linuxmuster-dehydrated --cron
# INFO: Using main config file /etc/linuxmuster-dehydrated/config
Processing server.intern.example.org
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Jun 27 18:27:20 2018 GMT (Longer than 30 days). Skipping renew!
+ Hook unchanged_cert...
/etc/linuxmuster-dehydrated/hook.sh: Zeile 63: unchanged_cert: Kommando nicht gefunden.Offenbar fehlt dieser (und weitere) Handler im Script noch, oder? Hast du das nochmal erweitert oder ist diese Version der Stand der Dinge?
Nachtrag: Wenn man unter /etc/linuxmuster-dehydrated/certs alles löscht und es nochmal anwirft, läuft es erfolgreich durch. ENDLICH auch intern ein gültiges Zertifikat. Super!
Ich habe an vielen Stellen einfach http(s)://10.16.1.1 verlinkt, was natürlich (weiterhin) dazu führt, dass das Zertifikat als “unsicher” eingestuft wird (self-signed). Für die IP 10.16.1.1 kann das man auf diesem Weg natürlich nicht hinbekommen, aber habt ihr bei euch evtl einen redirect wie
Redirect permanent / https://server.intern.example.org/in der apache-conf?? Oder spricht etwas dagegen?
Schöne Grüße,
Michael
Hi. Ich pushe die Frage nochmal nach oben … habe aber gleichzeitig eine kleine Ergänzung:
Es gibt evtl auch einfachere Lösungen für die ganzen LetsEncrypt-Zertifikate, die man holen/erneuern/verteilen muss. Ich bin über diese Seite gestolpert:
CaddyServer (ein „Webserver“ mit eingebautem ACME-Client) --> https://caddyserver.com/
Hat das mal jemand ausprobiert?
Schönen Gruß,
Michael
Hallo,
vielen Dank! Funktioniert mit Änderung wunderbar.
Was musste ich ändern?
Im Paket für lmn6.2 ist die hooks.sh nicht aktuell; enthält das umkopieren nicht.
Ich habe die von github genommen , das cert-Verzeichnis gelöscht/umbenannt und nochmal den Befehl linuxmuster-dehydrated --cron ausgeführt. Jetzt wurden die wieder neu erstellten Zertifikate nach /etc/ssl/private kopiert und alles ist paletti.
Viele Grüße ,
Helge
Hi Frank,
was ich noch nicht wusste: tls-sni-01 ist ja rausgeschmissen worden, aber es gibt einen Nachfolger: tls-apln-01 und dehydrated in einer neueren Version kann das:
VG, Tobias