search

internetstandards / Internet.nl

Internet standards compliance test suite
https://internet.nl
172 stars 35 forks source link

The color blue for DANE key rollover suggests that there is work to be done #1206

Closed janwillemstegink closed 8 months ago

janwillemstegink commented 9 months ago

Verdict in green: Each of your mailservers has at least one valid DANE fingerprint. This allows sending mail servers that support DANE verification to set up an authenticated encrypted transport connection with your receiving mail servers.

Verdict in BLUE: At least one of your mail server domains does not have an active DANE scheme for a reliable rollover of certificate keys. Technical details: Mail server (MX) DANE rollover scheme alma.hostfusion.nl. no

The color blue suggests that there is work to be done in such a stable situation. I would suggest some neutral color. However after rollover, a warning color to remove the previous key, is relevant.

bwbroersma commented 9 months ago

It's correct, it's advised to have either a 3 1 1-TLSA record for the next public key (rollover), or one or multiple 2 1 1-TLSA' s for the intermediate certificate authority (e.g. for Let's Encrypt that would currently be: R3, R4, E1 and E2). If one of those cases is detected, the test will turn green. This is to prevent the case that people setup a 3 1 1, then some ACME process does an auto-renewal, and DANE will fail.

janwillemstegink commented 9 months ago

My working Let's Encrypt R3 DANE value is: 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D I did not succeed to find the R4 value on the internet. This does not seem to be a well-known situation in discussions. If a second invalid key is entered, it shows up red on https://dane.sys4.de/. What does work in this case in order to fix the blue color on internet.nl?

bwbroersma commented 9 months ago

See Viktor Dukhovni's comment, it best to publish all 4 records if you use LE (although R3 / R4 will only be used for RSA keys and E1 / E2 will only be used if you use EC keys). For some (web) DANE records internet.nl now has some CNAME's to a record with all Let's Encrypt intermediate records (please publish your own and don't use this CNAME!). E.g. _443._tcp.dashboard.internet.nl is an alias for dashboard._dane.internet.nl. dashboard._dane.internet.nl is an alias for le-intermediate._dane.internet.nl.

$ dig +short TLSA le-intermediate._dane.internet.nl.
2 1 1 E5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77 990F2D03
2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B220407 1ED04F10
2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DC FBCF286D
2 1 1 BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422 E0C89270

You should ignore the space (it's a length issue in the DNS record).

How to generate these hashes:

$ for x in r3 r4 e1 e2; do \
    curl -sSfA '' "https://letsencrypt.org/certs/lets-encrypt-$x.pem" \
    | openssl x509 -pubkey -noout \
    | openssl $([ "${x:0:1}" == "r" ] && echo "rsa" || echo "ec") -pubin -pubout -outform DER 2>/dev/null \
    | openssl dgst -sha256 -binary \
    | xxd -c64 -p -u; \
done
8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D
E5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77990F2D03
276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10
BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270

So those are the SHA256 hashes of the Let's Encrypt intermediate public keys of respectively R3, R4, E1 and E2.

janwillemstegink commented 9 months ago

I have implemented the four 211 keys. Thanks.

RFC 6394 mentions: Simple Key Management: DANE should have a mode in which the domain holder only needs to maintain a single long-lived public/private key pair.

Edit by @bwbroersma - inlined images from docx: image1 image2

bwbroersma commented 8 months ago

Thanks, the 3 1 1 is not invalid, it is this manual certificate that was in place on the apex before the docker version 1.8, but it is still in place on the parts that are not in the docker container.

$ openssl s_client -connect emailveilig.internet.nl:443 -verify_quiet </dev/null 2>/dev/null \
| openssl x509 -pubkey -noout \
| openssl rsa -pubin -pubout -outform DER 2>/dev/null \
| openssl dgst -sha256 -binary \
| xxd -c64 -p -u

or 

$ curl -sSf \
  -A 'Mozilla/5.0 (compatible; HumanWithCurl/0.1; +https://github.com/internetstandards/Internet.nl/issues/1206)' \
   'https://crt.sh/?d=10799882636' \
| openssl x509 -pubkey -noout \
| openssl rsa -pubin -pubout -outform DER 2>/dev/null \
| openssl dgst -sha256 -binary \
| xxd -p -u -c64

Will both results in D6FEA64D4E68CAEAB7CBB2E0F905D7F3CA3308B12FD88C5B469F08AD7E05C7C7.

The corresponding 2 1 1 is E1AE9C3DE848ECE1BA72E0D991AE4D0D9EC547C6BAD1DDDAB9D6BEB0A7E0E0D8:

$ openssl s_client -showcerts -connect emailveilig.internet.nl:443 -verify_quiet </dev/null 2>/dev/null \
| awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{if(/BEGIN CERTIFICATE/){c++};if(c==2)print}' \
| openssl x509 -pubkey -noout \
| openssl rsa -pubin -pubout -outform DER 2>/dev/null \
| openssl dgst -sha256 -binary \
| xxd -c64 -p -u

For convenience and in the process of migration these two records are still up on the apex, but it could be removed from proloprod._dane.internet.nl and the current domains that are outside docker should have their own record with these two TLSA records.

bwbroersma commented 8 months ago

The internet.nl DNS zone is updated, the unused 3 1 1 (and corresponding 2 1 1) are removed. Thanks @janwillemstegink for noting this, closing the issue. It only has the 4 Let's Encrypt intermediate certificates now:

$ dig +noall +answer TLSA _443._tcp.internet.nl 
_443._tcp.internet.nl.  3600    IN  CNAME   proloprod._dane.internet.nl.
proloprod._dane.internet.nl. 3600 IN    CNAME   le-intermediate._dane.internet.nl.
le-intermediate._dane.internet.nl. 3600 IN TLSA 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DC FBCF286D
le-intermediate._dane.internet.nl. 3600 IN TLSA 2 1 1 BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422 E0C89270
le-intermediate._dane.internet.nl. 3600 IN TLSA 2 1 1 E5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77 990F2D03
le-intermediate._dane.internet.nl. 3600 IN TLSA 2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B220407 1ED04F10
bwbroersma commented 8 months ago

@janwillemstegink had the remaining question: isn't one 2 1 1 for mail not enough (would a 2 1 1 need a rollover?). Also: could you clarify your the following point you made earlier?

  • If using CNAME/DNAME for TLSA, a future remark may warn that a third party can use.

I have a few questions, can I trick the 'rollover':

https://github.com/internetstandards/Internet.nl/blob/7bb8f53b97ffe467080884250bc0a81f029a978c/checks/tasks/tls.py#L1159-L1186

janwillemstegink commented 7 months ago

About CNAME/DNAME for TLSA: In general, such a query can put an unexpected workload on someone else's name servers. I wouldn't encourage such a setup. Internet.nl may warn of bad behavior if CNAME/DNAME for TLSA is used on someone else's domain.

janwillemstegink commented 7 months ago

About indeed tricking the test: With an unvalid 311 record the rollover scheme turns green. https://internet.nl/mail/janwillemstegink.nl/1135479/#control-panel-29 (with 212 record) https://internet.nl/mail/janwillemstegink.nl/1135482/#control-panel-29 (without a 212 record)