-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Folks, an ecosystem heads-up to anyone using Let's Encrypt certificates
in their mail-servers.
As of today, TLS certificates issued by the Let's Encrypt (LE)
certificate authority (CA) are using a new intermediate certificate.
The general plan was detailed at
https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html
with some broader view explanation and timeline at:
https://letsencrypt.org/2020/11/06/own-two-feet.html
While LE will start using their new _roots_ next year, the change today
is using a _variant_ of their "R3" certificate which is cross-signed
from IdenTrust, rather than chaining back to their "ISRG Root X1".
This will affect you if you're using DANE, TLSA records in DNS, signed
by DNSSEC, to advertise properties of the certificate chain which remote
systems should expect to see.
Exim docs on DANE are at:
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECDANE
If you are using DANE to pin your certificates in a way which assumes
their X3 or X4 intermediates and haven't already added support for their
new intermediates, you now have a problem: as soon as your systems renew
their certificates, DANE verifying remote mail-systems will reject
connections to your mail-servers, because an unauthorized CA is being
used.
If using CA pinning in DANE ("Usage 2"), I recommend:
* making sure that you handle at least the current and failover pair so
that emergency failover to the standby intermediate won't affect your
DNS; if using X3, you should ALWAYS advertise X3+X4 together.
* using Selector 1, to match the public key inside the certificate, not
the whole certificate, so that you don't need to care if you're using
R3/R4 signed by ISRG or signed by IdenTrust or anyone else
* Labelling your DNS records carefully :-)
* Using a CNAME, if not programmatically generating the records; this
will let you define your trust anchors once and then reference them
for various services
* Understand your TTLs and how long old records can live in caches.
Some example DNS records are below.
Gratuitous project pimping:
https://go.pennock.tech/smtpdane/
MIT license, written in Go, install with:
go get go.pennock.tech/smtpdane
Beware that the Let's Encrypt servers seem to be a little overloaded
today, and this will probably continue if lots of other people are
manually renewing their certs ahead of schedule so that they can babysit
and be sure nothing goes wrong.
Oh, and if you're using certs from LE, and can afford it, please do
donate to support their fine work:
https://letsencrypt.org/donate/
Regards,
- -Phil
Apologies for the long lines below:
- ---------------------------8< DNS Records >8----------------------------
; TLSA: Usage Selector Matching-Type CAdata
; Usage==2 : CA anchor, no PKIX requirement
; Selector==0 : match entire cert
; Selector==1 : match public key
; MT: 0=exact match, 1=sha256, 2=sha512
; RFCs: 6698 6394
; names in RFC 7218
; Each additional record is 2 octets for compressed name, 10 octets for
; RR overhead, 3 octets for usage/selector/type, and 32 octets for a
; SHA256 checksum, total 47 octets.
; 2 records at target of CNAME: 100 octets
; 6 records at target of CNAME: 288 octets
;
; We don't serve the root certs unless/until there's a period of
; uncertainty about what's coming next.
;_le-tlsa TLSA ( 02 01 01 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 ) ; ISRG Root X1 (RSA) ; EXPIRES: 2035-06-04
;_le-tlsa TLSA ( 02 01 01 762195c225586ee6c0237456e2107dc54f1efc21f61a792ebd515913cce68332 ) ; ISRG Root X2 (ECC) ; EXPIRES: 2040-09-17
;
_le-tlsa TLSA ( 02 01 01 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 ) ; X3 ; EXPIRES: 2021 (Mar vs Oct depending upon path)
_le-tlsa TLSA ( 02 01 01 b111dd8a1c2091a89bd4fd60c57f0716cce50feeff8137cdbee0326e02cf362b ) ; X4 ; EXPIRES: 2021 (Mar vs Oct depending upon path)
_le-tlsa TLSA ( 02 01 01 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ) ; R3 (RSA) ; EXPIRES: 2025-09-15
_le-tlsa TLSA ( 02 01 01 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ) ; R4 (RSA) ; EXPIRES: 2025-09-15
_le-tlsa TLSA ( 02 01 01 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ) ; E1 (ECC) ; EXPIRES: 2025-09-15
_le-tlsa TLSA ( 02 01 01 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ) ; E2 (ECC) ; EXPIRES: 2025-09-15
; Assuming that the MX server is called "mx" and your mail-sending box
; for clients to connect to is called "smtp":
_25._tcp.mx CNAME _le-tlsa
_465._tcp.smtp CNAME _le-tlsa
_587._tcp.smtp CNAME _le-tlsa
- ---------------------------8< DNS Records >8----------------------------
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQQ2vqQhJhxApU/JJhwudmURD4pW/wUCX8cmqwAKCRAudmURD4pW
/w1YAP91G5Y5SJp311ezZFcvijhpYw8PRI5o5t/v2oh/wYqESAEA/2gM0QZekoGq
woa0acaNtv2X7CBdrmRByxhLhQzQJgc=
=nha7
-----END PGP SIGNATURE-----
--
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at http://www.exim.org/ ##
Hash: SHA256
Folks, an ecosystem heads-up to anyone using Let's Encrypt certificates
in their mail-servers.
As of today, TLS certificates issued by the Let's Encrypt (LE)
certificate authority (CA) are using a new intermediate certificate.
The general plan was detailed at
https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html
with some broader view explanation and timeline at:
https://letsencrypt.org/2020/11/06/own-two-feet.html
While LE will start using their new _roots_ next year, the change today
is using a _variant_ of their "R3" certificate which is cross-signed
from IdenTrust, rather than chaining back to their "ISRG Root X1".
This will affect you if you're using DANE, TLSA records in DNS, signed
by DNSSEC, to advertise properties of the certificate chain which remote
systems should expect to see.
Exim docs on DANE are at:
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECDANE
If you are using DANE to pin your certificates in a way which assumes
their X3 or X4 intermediates and haven't already added support for their
new intermediates, you now have a problem: as soon as your systems renew
their certificates, DANE verifying remote mail-systems will reject
connections to your mail-servers, because an unauthorized CA is being
used.
If using CA pinning in DANE ("Usage 2"), I recommend:
* making sure that you handle at least the current and failover pair so
that emergency failover to the standby intermediate won't affect your
DNS; if using X3, you should ALWAYS advertise X3+X4 together.
* using Selector 1, to match the public key inside the certificate, not
the whole certificate, so that you don't need to care if you're using
R3/R4 signed by ISRG or signed by IdenTrust or anyone else
* Labelling your DNS records carefully :-)
* Using a CNAME, if not programmatically generating the records; this
will let you define your trust anchors once and then reference them
for various services
* Understand your TTLs and how long old records can live in caches.
Some example DNS records are below.
Gratuitous project pimping:
https://go.pennock.tech/smtpdane/
MIT license, written in Go, install with:
go get go.pennock.tech/smtpdane
Beware that the Let's Encrypt servers seem to be a little overloaded
today, and this will probably continue if lots of other people are
manually renewing their certs ahead of schedule so that they can babysit
and be sure nothing goes wrong.
Oh, and if you're using certs from LE, and can afford it, please do
donate to support their fine work:
https://letsencrypt.org/donate/
Regards,
- -Phil
Apologies for the long lines below:
- ---------------------------8< DNS Records >8----------------------------
; TLSA: Usage Selector Matching-Type CAdata
; Usage==2 : CA anchor, no PKIX requirement
; Selector==0 : match entire cert
; Selector==1 : match public key
; MT: 0=exact match, 1=sha256, 2=sha512
; RFCs: 6698 6394
; names in RFC 7218
; Each additional record is 2 octets for compressed name, 10 octets for
; RR overhead, 3 octets for usage/selector/type, and 32 octets for a
; SHA256 checksum, total 47 octets.
; 2 records at target of CNAME: 100 octets
; 6 records at target of CNAME: 288 octets
;
; We don't serve the root certs unless/until there's a period of
; uncertainty about what's coming next.
;_le-tlsa TLSA ( 02 01 01 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 ) ; ISRG Root X1 (RSA) ; EXPIRES: 2035-06-04
;_le-tlsa TLSA ( 02 01 01 762195c225586ee6c0237456e2107dc54f1efc21f61a792ebd515913cce68332 ) ; ISRG Root X2 (ECC) ; EXPIRES: 2040-09-17
;
_le-tlsa TLSA ( 02 01 01 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 ) ; X3 ; EXPIRES: 2021 (Mar vs Oct depending upon path)
_le-tlsa TLSA ( 02 01 01 b111dd8a1c2091a89bd4fd60c57f0716cce50feeff8137cdbee0326e02cf362b ) ; X4 ; EXPIRES: 2021 (Mar vs Oct depending upon path)
_le-tlsa TLSA ( 02 01 01 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ) ; R3 (RSA) ; EXPIRES: 2025-09-15
_le-tlsa TLSA ( 02 01 01 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ) ; R4 (RSA) ; EXPIRES: 2025-09-15
_le-tlsa TLSA ( 02 01 01 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ) ; E1 (ECC) ; EXPIRES: 2025-09-15
_le-tlsa TLSA ( 02 01 01 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ) ; E2 (ECC) ; EXPIRES: 2025-09-15
; Assuming that the MX server is called "mx" and your mail-sending box
; for clients to connect to is called "smtp":
_25._tcp.mx CNAME _le-tlsa
_465._tcp.smtp CNAME _le-tlsa
_587._tcp.smtp CNAME _le-tlsa
- ---------------------------8< DNS Records >8----------------------------
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQQ2vqQhJhxApU/JJhwudmURD4pW/wUCX8cmqwAKCRAudmURD4pW
/w1YAP91G5Y5SJp311ezZFcvijhpYw8PRI5o5t/v2oh/wYqESAEA/2gM0QZekoGq
woa0acaNtv2X7CBdrmRByxhLhQzQJgc=
=nha7
-----END PGP SIGNATURE-----
--
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at http://www.exim.org/ ##