Re: [Exim-users-de] Lösung: exim.crt und key
MoinMoin
Die Letsencrypt client tools „dehydrated" oder „acme" würden diese Arbeit auch
machen. Ich persönlich bevorzuge acme.
Voraussetzung ist das Du einen Nameserver oder Webserver hast der korrekt auf
die letsencrypt Prüfungs-Anfrage antwortet. Aber das brauchst du ja immer. Nach
der Erstinstallation läuft dann alles vollautomatisch über einen cronjob. Die
LE Clients wissen wann ein Zertifikat zu erneuern ist und tun dies wenn das
Ablaufdatum unter eine 30 Tage Grenze sinkt. Auch das Problem mit dem
Eigentümer der Zertifikate/Keys läßt sich in den vorgesehenen
Konfigurationseinstellungen lösen.
Beispiele hier sind aus FreeBSD, die Pfade werden für Debian Linux vermutlich
nicht passen.
### Dehydrated: ###
Aus "config":
HOOK=/usr/local/etc/dehydrated/deploy.sh
PRIVATE_KEY_RENEW=„no"
Aus "domains.txt":
mail.meinedomain.de
Aus "deploy.sh":
deploy_cert() {
...
echo " + Hook: Change rights on
/usr/local/etc/dehydrated/certs/mail.meinedomain.de"
chown mailnull:mailnull
/usr/local/etc/dehydrated/certs/mail.meinedomain.de/*.*
service exim restart
}
Einmaliger erster Aufruf: /usr/local/bin/dehydrated --register --accept-terms
Dann "/usr/local/bin/dehydrated -c -g" ausführen
Exim: Symbolischer Link im Exim cert Verzeichnis:
mail.meinedomain.de.crt@ ->
/usr/local/etc/dehydrated/certs/mail.meinedomain.de/fullchain.pem
mail.meinedomain.de.key@ ->
/usr/local/etc/dehydrated/certs/mail.meinedomain.de/privkey.pem
Aus crontab:
/usr/local/bin/dehydrated -c -g 2>&1 >> /var/log/dehydrated.log
### Acme (mit LEtsencrypt Nameserver Prüfung): ###
Erstinstallation:
acme.sh -f --issue --home /var/db/acme/.acme.sh/ --dns dns_pdns
mail.meinedomain.de #(für Webserver Prüfung "--dns dns_pdns“ durch "--use-wget“
ersetzen)
acme.sh --home /var/db/acme/.acme.sh/ \
--install-cert -d mail.meinedomain.de \
--cert-file /usr/local/etc/exim/ssl/mail.meinedomain.de.crt \
--key-file /usr/local/etc/exim/ssl/mail.meinedomain.de.key \
--fullchain-file /usr/local/etc/exim/ssl/mail.meinedomain.de.pem \
--reloadcmd "chown mailnull:mailnull
/usr/local/etc/exim/ssl/mail.meinedomain.de.* & service exim restart"
Resultat: /var/db/acme/certs/mail.meinedomain.de/mail.meinedomain.de.conf:
Le_Domain='mail.meinedomain.de'
Le_Alt=‚no‘
...
Le_CertCreateTime='1622330797'
Le_CertCreateTimeStr='Sa. 29 Mai 2021 23:26:37 UTC'
Le_NextRenewTimeStr='Mi. 28 Juli 2021 23:26:37 UTC'
Le_NextRenewTime='1627428397'
Le_RealCertPath='/usr/local/etc/exim/ssl/mail.meinedomain.de.crt'
Le_RealKeyPath='/usr/local/etc/exim/ssl/mail.meinedomain.de.key'
Le_ReloadCmd='__ACME_BASE64__START_Y2hvd24gbWFpbG51bGw6bWFpbG51bGwgL3Vzci9sb2NhbC9ldGMvZXhpbS9zc2wvbWFpbGhvcC5zYWZlY29ubmVjdC5kZS4qICYgc2VydmljZSBleGltIHJlc3RhcnQ=__ACME_BASE64__END_‘
Le_RealFullChainPath='/usr/local/etc/exim/ssl/mail.meinedomain.de.pem‘
Aus Crontab:
/var/db/acme/.acme.sh/acme.sh --cron --home /var/db/acme/.acme.sh
Viele Grüße
Nicola
> Am 16.02.2020 um 15:32 schrieb Jutta Wrage via Exim-users-de
> :
>
> Hallo!
>
> Ich denke, es ist sinnvoll, zu schreiben, wie ich das Problem mit dem SSL-Key
> gelöst habe:
>
> Ein script in /usr/local/bin erstellt, daß im Letsencrypt-Verzeichnis auf
> einen neuen Key prüft und diesen bei Bedarf mit preserver-timestamps kopiert.
>
> Das ganze dann in cron.daily aufgerufen.
>
> Den Key ansehen kann man im Übrigen z. B. mit
>
> openssl x509 -text -noout -in /etc/exim4/exim.crt
>
> Da stehen dann unter anderem die Validity (von/bis) drin, der Herausgeber und
> die Namen der hosts, für die er gilt.
>
> Auf die Idee mit dem Script und dem Cronjob hat mich das Debian-Buch von
> Heike Jurzik gebracht.
>
> Wichtig: Der Eigentümer muß bei Debian Debian-exim sein. Und der private Key
> natürlich nicht weltweit lesbar.
>
> Etwas besseres ist mir ohne Veränderung der Rechte im Verzeichnisbaum von
> letscrypt nicht eingefallen.
>
> Gruß
>
> Jutta
>
>
> --
> http://www.witch.westfalen.de
>
>
> ___
> Exim-users-de mailing list
> Exim-users-de@exim.org
> https://lists.exim.org/mailman/listinfo/exim-users-de
signature.asc
Description: Message signed with OpenPGP
___
Exim-users-de mailing list
Exim-users-de@exim.org
https://lists.exim.org/mailman/listinfo/exim-users-de
Re: [Exim-users-de] Lösung: exim.crt und key
On Sun, Feb 16, 2020 at 07:19:00PM +0100, Heiko Schlittermann via Exim-users-de
wrote:
> Martin Reising via Exim-users-de (So 16 Feb 2020
> 17:00:12 CET):
> > In meinem /usr/local/sbin/dehydrated-renew benutze ich nur -enddate
> >
> ># get cert enddate Not After
> >endzert=$(openssl x509 -enddate -noout -in ${zert}/cert.pem | cut -d"="
> > -f2)
> ># convert to epoch -15 days
> >renew=$(date -d "${endzert} -15 days" "+%s")
>
> Kümmert sich dehydrated nicht von alleine nur um die Zertifikate, die es
> dringend nötig haben? Oder habe ich jetzt was nicht verstanden. Ich
> nutze dehydrated mit der domains.txt und rufe es einfach täglich auf. Es
> erneuert dann alles, was not tut.
Stimmt, aber ich will das nur Samstags Mittags und auch nur maximal 15
Tage vor dem Ablauf erneuern und nicht schon 30 Tage vorher.
> > In deploy_cert() sieht das dann so aus:
> >
> > # create new pem
> > cat "${KEYFILE}" "${FULLCHAINFILE}" > "${my_target_pem}"
> > # set owner & permissions
> > chown root:Debian-exim "${my_target_pem}" && chmod 640
> > "${my_target_pem}"
>
> … wobei das Eigentümerändern und Chmoden ja nicht jedesmal nötig ist,
> aber schaden tut es natürlich auch nicht.
>
> Es bleibt ein kurzer Moment, in dem das File vielleicht leer ist.
> Vermutlich kann man in den meisten Setups damit leben. Idealerweise
> würde aber erst das File gebaut mit einem temporären Namen und
> anschließend umbenannt, dann ist es nie leer, sondern *entweder* das
> alter *oder* das neue.
Danke für den Hinweis auf meinen peinlichen Fehler; werde ich so
abänderen.
signature.asc
Description: PGP signature
___
Exim-users-de mailing list
Exim-users-de@exim.org
https://lists.exim.org/mailman/listinfo/exim-users-de
Re: [Exim-users-de] Lösung: exim.crt und key
Martin Reising via Exim-users-de (So 16 Feb 2020
17:00:12 CET):
> In meinem /usr/local/sbin/dehydrated-renew benutze ich nur -enddate
>
># get cert enddate Not After
>endzert=$(openssl x509 -enddate -noout -in ${zert}/cert.pem | cut -d"="
> -f2)
># convert to epoch -15 days
>renew=$(date -d "${endzert} -15 days" "+%s")
Kümmert sich dehydrated nicht von alleine nur um die Zertifikate, die es
dringend nötig haben? Oder habe ich jetzt was nicht verstanden. Ich
nutze dehydrated mit der domains.txt und rufe es einfach täglich auf. Es
erneuert dann alles, was not tut.
Und deploy_cert macht dann den Rest, wie bei Dir.
> In deploy_cert() sieht das dann so aus:
>
> # create new pem
> cat "${KEYFILE}" "${FULLCHAINFILE}" > "${my_target_pem}"
> # set owner & permissions
> chown root:Debian-exim "${my_target_pem}" && chmod 640
> "${my_target_pem}"
… wobei das Eigentümerändern und Chmoden ja nicht jedesmal nötig ist,
aber schaden tut es natürlich auch nicht.
Es bleibt ein kurzer Moment, in dem das File vielleicht leer ist.
Vermutlich kann man in den meisten Setups damit leben. Idealerweise
würde aber erst das File gebaut mit einem temporären Namen und
anschließend umbenannt, dann ist es nie leer, sondern *entweder* das
alter *oder* das neue.
--
Heiko
signature.asc
Description: PGP signature
___
Exim-users-de mailing list
Exim-users-de@exim.org
https://lists.exim.org/mailman/listinfo/exim-users-de
Re: [Exim-users-de] Lösung: exim.crt und key
Jutta Wrage via Exim-users-de (So 16 Feb 2020 15:32:52
CET):
> Hallo!
>
> Ich denke, es ist sinnvoll, zu schreiben, wie ich das Problem mit dem SSL-Key
> gelöst habe:
>
> Ein script in /usr/local/bin erstellt, daß im Letsencrypt-Verzeichnis auf
> einen neuen Key prüft und diesen bei Bedarf mit preserver-timestamps kopiert.
Je nachdem, wie Du zu den LE Zertifikaten kommst, kann sicher ein Hook
verwendet werden, der unmittelbar nach dem Holen der Zertifikate
das macht, was notwendig ist.
Ungetestet - war gerade so eine Idee von mir, das über ein Makefile
zu lösen.
#!/usr/bin/make -f
/var/lib/exim4/ssl.pem: /var/lib/denhyrated/…/fullchain.pem …/privkey.pem
umask 0777 && cat "$^" >$@.tmp
chown root:Debian-exim $@.tmp
chmod u=rw,g=r $@
mv $@.tmp $@
Dem Exim genügt ein File für Key und Cert gemeinsam. (Das ist übrigens
bei der meisten
> Wichtig: Der Eigentümer muß bei Debian Debian-exim sein.
Diese Aussage ist nicht präzise. Und sogar gefährlich, weil es
impliziert, daß er Eigentümer mit dem File auch andere Dinge tun kann
(z.B. Rechte modifizieren, Inhalt ändern…)
Der Exim-Rumtime-User muss die Files lesen können.
-rw-r- root Debian-exim ssl.pem
wäre das, was ich hier empfehle.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 -
signature.asc
Description: PGP signature
___
Exim-users-de mailing list
Exim-users-de@exim.org
https://lists.exim.org/mailman/listinfo/exim-users-de
Re: [Exim-users-de] Lösung: exim.crt und key
On Sun, Feb 16, 2020 at 03:32:52PM +0100, Jutta Wrage via Exim-users-de wrote:
> Hallo!
>
> Ich denke, es ist sinnvoll, zu schreiben, wie ich das Problem mit dem SSL-Key
> gelöst habe:
>
> Ein script in /usr/local/bin erstellt, daß im Letsencrypt-Verzeichnis auf
> einen neuen Key prüft und diesen bei Bedarf mit preserver-timestamps kopiert.
>
> Das ganze dann in cron.daily aufgerufen.
>
> Den Key ansehen kann man im Übrigen z. B. mit
>
> openssl x509 -text -noout -in /etc/exim4/exim.crt
>
> Da stehen dann unter anderem die Validity (von/bis) drin, der Herausgeber und
> die Namen der hosts, für die er gilt.
In meinem /usr/local/sbin/dehydrated-renew benutze ich nur -enddate
# get cert enddate Not After
endzert=$(openssl x509 -enddate -noout -in ${zert}/cert.pem | cut -d"=" -f2)
# convert to epoch -15 days
renew=$(date -d "${endzert} -15 days" "+%s")
Ansonsten überprüfe ich einfach stumpf alle letscrypt Zertifikate:
MYDH_BASE="/var/lib/dehydrated/certs"
for zert in ${MYDH_BASE}/*
do
...
done
> Auf die Idee mit dem Script und dem Cronjob hat mich das Debian-Buch von
> Heike Jurzik gebracht.
>
> Wichtig: Der Eigentümer muß bei Debian Debian-exim sein. Und der private Key
> natürlich nicht weltweit lesbar.
>
> Etwas besseres ist mir ohne Veränderung der Rechte im Verzeichnisbaum von
> letscrypt nicht eingefallen.
Das und einiges mehr lasse ich dehydrated in der Shellfunction
deploy_cert() in /etc/dehydrated/hook.sh erledigen. Ich habe mich
dafür entschieden die Berechtigung von /etc/ssl/private/ zu ändern und
das Zertifikat dort für die Gruppe Debian-exim lesbar zu machen:
drwx--xr-x 2 root ssl-cert4096 Feb 4 21:20 /etc/ssl/private/
-rw-r- 1 root Debian-exim 7314 Feb 4 21:20
/etc/ssl/private/union-letsencrypt.pem
In deploy_cert() sieht das dann so aus:
# create new pem
cat "${KEYFILE}" "${FULLCHAINFILE}" > "${my_target_pem}"
# set owner & permissions
chown root:Debian-exim "${my_target_pem}" && chmod 640
"${my_target_pem}"
signature.asc
Description: PGP signature
___
Exim-users-de mailing list
Exim-users-de@exim.org
https://lists.exim.org/mailman/listinfo/exim-users-de
[Exim-users-de] Lösung: exim.crt und key
Hallo! Ich denke, es ist sinnvoll, zu schreiben, wie ich das Problem mit dem SSL-Key gelöst habe: Ein script in /usr/local/bin erstellt, daß im Letsencrypt-Verzeichnis auf einen neuen Key prüft und diesen bei Bedarf mit preserver-timestamps kopiert. Das ganze dann in cron.daily aufgerufen. Den Key ansehen kann man im Übrigen z. B. mit openssl x509 -text -noout -in /etc/exim4/exim.crt Da stehen dann unter anderem die Validity (von/bis) drin, der Herausgeber und die Namen der hosts, für die er gilt. Auf die Idee mit dem Script und dem Cronjob hat mich das Debian-Buch von Heike Jurzik gebracht. Wichtig: Der Eigentümer muß bei Debian Debian-exim sein. Und der private Key natürlich nicht weltweit lesbar. Etwas besseres ist mir ohne Veränderung der Rechte im Verzeichnisbaum von letscrypt nicht eingefallen. Gruß Jutta -- http://www.witch.westfalen.de ___ Exim-users-de mailing list Exim-users-de@exim.org https://lists.exim.org/mailman/listinfo/exim-users-de
