Daniel Micay on Twitter: "@VDukhovni @internet_nl @drwetter It's easy to use certbot for this: certbot certonly --standalone --key-type rsa --rsa-key-size 3072 --reuse-key -d https://t.co/wHbHr9L4P6 This will reuse the same key each time and when you want to rotate the key you can request a second certificate with --cert-name to rotate." / Twitter

Was mich am meisten verwundert, dass der Bund kein "ordentliches" Zertifikat für SMTP verwendet.

Quote Tweet

Jan 25, 2021

Weiß jemand, warum beim bund.de die #krypto config beim genaueren Hinsehen kaputt ist: * DNSSEC: ok * SMTP, 25/tcp: Zertifikat Root-CA nicht allgem. trusted * SMTP, 25/tcp: TLSA record: ok * bund.de (Port 443): TLSA record kaputt cc @BSI_Bund

4

2

Replying to

What would be the advantage of using a certificate from a publicly trusted CA on a receiving mail server? Note that sending mail servers usually do not care for reasons. - en.internet.nl/mail/bund.de/4 - rfc-editor.org/rfc/rfc7672.ht - rfc-editor.org/rfc/rfc7672.ht

3

1

Replying to

and

There are pros and cons to ensuring a valid a cert from a public CA. The positives are: * A few brain-dead MTAs do opportunistic TLS wrong, they send in cleartext when TLS auth fails, instead of continuing anyway w/ STARTTLS. Given a valid cert they use TLS. ...

2

3

Replying to

and

* You can, if you wish, publish an MTA-STS policy, and maintain associated DNS TXT records to enable some senders to use MTA-STS. The negatives are: * You have to rotate the certificate in time to keep it valid. * This can increase the odds of a mismatch with any DANE TLSA RRs.

2

Replying to

and

It's easy to use certbot for this: certbot certonly --standalone --key-type rsa --rsa-key-size 3072 --reuse-key -d domain.com This will reuse the same key each time and when you want to rotate the key you can request a second certificate with --cert-name to rotate.

4:18 PM · Jan 26, 2021Twitter Web App

Replying to

and

You and I know this, but some users get it wrong. It is also easy to forget to ensure that the new key already matched by the TLSA RRset well *before* introducing into the Let's Encrypt configuration as the next key to (re)use.

Replying to

You add a TLSA record for the new certificate, then once enough time has passed switch over to it and tell certbot to delete the old certificate. MUAs usually expect a CA issued certificate for the submission ports and don't understand TLSA records so it's useful beyond MTA-STS.

1

Replying to

and

Yes, I neglected to mention the port 587 use-case, but one can use separate certs for port 25 and 587 and rotate just 587, if a stable cert on 25 is preferred.

Replying to

and

The same private key? Well, the whole point for a shortened certificate life time to me was to renew also the private key.

2

Replying to

and

Email server security depends on pinning the private key via a TLSA record. That means the regular certificate renewal process needs to reuse the same private key. Please read the next tweet in the thread. You're responding to this tweet out of context.

Quote Tweet

Daniel Micay

@DanielMicay

Jan 26, 2021

Replying to @DanielMicay @VDukhovni and 2 others

You add a TLSA record for the new certificate, then once enough time has passed switch over to it and tell certbot to delete the old certificate. MUAs usually expect a CA issued certificate for the submission ports and don't understand TLSA records so it's useful beyond MTA-STS.

1

Show replies

Conversation