[ FYI, based on text from a recent post to the dane-us...@sys4.de list ]
> Something else to keep in mind with the Let's Encrypt certificates is
> that they have a 90-day lifetime with the automatic renewal process
> starting at sixty days.
Automated replacement might make them entirely unfit for DANE-EE(3).
That is, assuming the automation neglects the necessary DNS update
precondition.
One of the most important features of DANE-EE(3) is that certificates
DO NOT EXPIRE with DANE-EE(3). You replace it when you are ready
to do it, not when the certificate goes up in smoke. The expiration
is in the RRSIG end time, not in the certificate.
If you lose that with Let's Encrypt (LE), DO NOT switch to LE.
For port 25 SMTP it'll do more harm than good. By all means use
LE certificates for port 587 (by configuring different certs for
the MTA and MSA):
master.cf:
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=$mua_client_restrictions
-o smtpd_helo_restrictions=$mua_helo_restrictions
-o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_cert_file=$mua_tls_cert_file
-o smtpd_tls_key_file=$mua_tls_key_file
main.cf:
mua_tls_cert_file = ... let's encrypt certificate chain + key file name ...
On port 25, go with self-signed certificates "expiring" in the
distant future (20 or more years from now). One DANE domain whose
administrator "got the memo" has a certificate good for a 1000
years:
Inception = 2014-07-27T14:59:59Z
Expiration = 3013-11-27T14:59:59Z
One way LE for port 25 with DANE can work is if renewal retains
the same private key, and the TLSA records are "3 1 1", making
certificate replacement a non-event, as the key stays the same.
An alternative, is to publish "2 0 1" records for the LE root CA
(which MUST then appear in the server's chain) or "2 1 1" records
for the LE intermediate CA (which must appear in the server's chain,
but that's more typically true anyway). The reason that I am
suggesting "2 1 1" for intermediates, is that these are often
re-issued with the same key and tend to have lifetimes shorter than
the issuing root.
Using "3 0 1" TLSA records with LE 90 day certificates that are
rotated automatically, sounds like a recipe for disaster, unless
deployment of the new certificate can be delayed (after it is
obtained) and the required DNS updates automated, with the certificate
deployed only once the DNS records have been fielded sufficiently
long.
> Using a Let's Encrypt certificate with DANE TLSA will require an alert
> sysadmin.
>
> https://community.letsencrypt.org/t/maximum-and-minimum-certificate-lifetimes/264/9
This does not discuss whether a new key is used for each renewal.
Can anyone using LE automated rotation check whether the key stays
the same or not?
--
Viktor.
