Schlüsselnachbestellung

Auch wenn junge, moderne Admins ihre SSL-Zertifikate natürlich längst automatisiert erhalten, lade ich sie bisher noch von Hand bei meinem Provider herunter und schicke sie dann in unterschiedlicher Bündelung auf meinen Server:

cat eden_personal.cer eden_intermediate.cer > eden.one_public.cer cat eden_private.key eden_personal.cer eden_intermediate.cer > eden.one_chain.pem scp eden_private.key root@server:/etc/ssl/private/eden.one_private.key scp eden.one_chain.pem root@server:/etc/ssl/private/eden.one_chain.pem scp eden.one_public.cer root@server:/etc/ssl/certs/eden.one_public.cer

Während eden.one_private.key und eden.one_public.cer von nginx und Dovecot genutzt werden, empfiehlt Postfix die Bündelung in eden.one_chain.pem:

Storing a key and its associated certificate chain in separate files is not recommended, because this is prone to race conditions during key rollover, as there is no way to update multiple files atomically.

Wenn ich nicht gerade meinen privaten Schlüssel zwischen Download und Upload verschludere

Ihr persönlicher Private Key (Privater Schlüssel) wird aus Sicherheitsgründen nicht in Ihrem IONOS-Konto hinterlegt. Wenn Sie nicht mehr im Besitz Ihres Private Keys sind, müssen Sie das Zertifikat neu ausstellen lassen. Damit erhalten Sie dann einen neuen Private Key.

– erzeugt die jährliche Schlüsselnachbestellung keinen erwähnenswerten Aufwand. Aber nachdem mittlerweile sämtliche Tutorials mit SSL/TLS-Bezug die Verwendung von Let's Encrypt unterstellen/voraussetzen/nahelegen, sehe ich mir den Certbot doch einmal an.

Die Installation erfolgt über die alternative Paketverwaltung Snap, die ihrerseits erst installiert werden muss:

apt-get install snap snap install core; snap refresh core snap install --classic certbot ln -s /snap/bin/certbot /usr/bin/certbot

Weil ich keine Anpassung meiner ausgefeilten nginx-Konfiguration wünsche, lasse ich mir nur die Zertifikate ausstellen:

certbot certonly --nginx

Nach diesem unscheinbaren Befehl wird mir die Ausstellung von Zertifikaten für alle in nginx konfigurierten Domains angeboten, oder jedenfalls würde sie mir angeboten, wenn ich in der Direktive server_name nicht willkürlich und grundlos Kommata zwischen einige der Domainnamen gesetzt hätte:

# Do NOT do this! server_name www.domain1.de domain1.de domain2.org, www.domain2.org, domain3.net www.domain3.net www.domain5.net, domain5.net, www.eden.one eden.one;

Der Certbot geht kreativ mit dieser fehlerhaften Anweisung um und verschweigt einfach die zwischen zwei Kommata befindlichen Domains. Nach erfolgter Korrektur und Auswahl der gewünschten Domains erzeugt er eine angemessen restriktive Verzeichnisstruktur unter /etc/letsencrypt, in der Zertifikate und Schlüssel wie folgt abgelegt werden:

Certificate is saved at: /etc/letsencrypt/live/[domain]/fullchain.pem Key is saved at: /etc/letsencrypt/live/[domain]/privkey.pem

Außerdem wird eine tägliche Timer Unit angelegt, die die Zertifikate rechtzeitig vor Ablauf ihrer dreimonatigen Gültigkeit erneuert. Ich muss lediglich die entsprechenden Dateipfade in /etc/nginx/nginx.conf, /etc/dovecot/conf.d/10-ssl.conf und /etc/postfix/main.cf eintragen und kann alles weitere dem Certbot überlassen. Da Let's Encrypt in der Regel keine Wildcard-Zertifikate ausstellt und iOS den MX-Eintrag und die Zertifikatsdomäne abgleicht, verwende ich für Dovecot und Postfix die Domäne mail.eden.one, für nginx eden.one.

Allerdings weiche ich mit der Konfiguration –

# /etc/postfix/main.cf smtpd_tls_chain_files = /etc/letsencrypt/live/mail.eden.one/privkey.pem, /etc/letsencrypt/live/mail.eden.one/fullchain.pem

– von der oben genannten Empfehlung ab und riskiere race conditions mit möglicherweise dauerhaften Folgen:

Storing the private key in the same file as the corresponding certificate is more reliable. With the key and certificate in separate files, there is a chance that during key rollover a Postfix process might load a private key and certificate from separate files that don't match. Various operational errors may even result in a persistent broken configuration in which the certificate does not match the private key.

Einerseits klingt das beunruhigend, andererseits ist Postfix derart sicherheitsorientiert, dass auch die unvermeidliche Einbindung von OpenSSL kritisch kommentiert wird:

NOTE: By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on hundreds of thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduces one additional bug into Postfix.

Ich entscheide mich für das Risiko und eine langfristig wartungsarme SSL/TLS-Konfiguration. Lediglich für meinen lokalen Mailstack muss ich im Abstand von drei Monaten die Fingerprints der frischen Zertifikate erzeugen

openssl x509 -noout -fingerprint -sha256 -in /etc/letsencrypt/live/mail.eden.one/fullchain.pem

– und in .offlineimaprc bzw. .msmtprc eintragen.

Für mein Sicherungsskript sind die Zugriffsrechte einiger Dateien unter /etc/letsencrypt übrigens zu restriktiv. Die privaten Schlüssel zur Kommunikation mit der Let's Encrypt-API sind auch für root nur lesbar, so dass gesicherte Kopien nicht mehr aktualisiert werden können. Ich hoffe, dass mein Workaround (chmod 600 private_key.json) nicht mit der Certbot-Funktionsweise kollidiert. Jedenfalls habe ich nicht vor, die Schlüssel zu löschen oder zu modifizieren.