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