Adding DNS (TLSA - Record) and match against SMTP-server public fingerprint #4040

New issue

Open

opened 2026-02-28 03:49:04 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-28 03:49:04 -05:00

Owner

Originally created by @DRieper on GitHub (Mar 17, 2025).

I realized that many smal and medium sized companies do not support DANE for their mailservers.
In fact the privacy of mail communication contains a lot of sensitive information, they are partly still vulnerable through man-in-the-middle 'downgrade attack'.

🏷️ Feature Request Type

New monitor

🔖 Feature description

Often I heard that they can not reliably monitor "DANE" and validate the TLSA DNS-record against the public-fingerprint of the SMTP servers certificate. Since some are using letsencrypt and are afraid to miss the renewal..without pinning the csr/key.

Since I love your lightweight smoth running uptime-kuma, I would suggest to expand it if possible with that feature.

I think it would already be sufficient just to enter the expected value of the TLSA record and check against openssl for the verification lines.

✔️ Solution

Example how to check it through dig:

:~$ dig +noall +answer _25._tcp.mail.protonmail.ch TLSA
_25._tcp.mail.protonmail.ch. 821 IN     TLSA    3 1 1 6111A5698D23C89E09C36FF833C1487EDC1B0C841F87C49DAE8F7A09 E11E979E
_25._tcp.mail.protonmail.ch. 821 IN     TLSA    3 1 1 76BB66711DA416433CA890A5B2E5A0533C6006478F7D10A4469A947A CC8399E1

And gathering the Information with:

openssl s_client -starttls smtp -connect mail.protonmail.ch:25 -dane_tlsa_domain mail.protonmail.ch -dane_tlsa_rrdata "3 1 1 76BB66711DA416433CA890A5B2E5A0533C6006478F7D10A4469A947ACC8399E1" </dev/null 2>/dev/null

Result:

SSL handshake has read 3951 bytes and written 433 bytes
Verification: OK
Verified peername: *.protonmail.ch
DANE TLSA 3 1 1 ...8f7d10a4469a947acc8399e1 matched EE certificate at depth 0

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @DRieper on GitHub (Mar 17, 2025). ### 📑 I have found these related issues/pull requests I realized that many smal and medium sized companies do not support DANE for their mailservers. In fact the privacy of mail communication contains a lot of sensitive information, they are partly still vulnerable through man-in-the-middle 'downgrade attack'. ### 🏷️ Feature Request Type New monitor ### 🔖 Feature description Often I heard that they can not reliably monitor "DANE" and validate the TLSA DNS-record against the public-fingerprint of the SMTP servers certificate. Since some are using letsencrypt and are afraid to miss the renewal..without pinning the csr/key. Since I love your lightweight smoth running uptime-kuma, I would suggest to expand it if possible with that feature. I think it would already be sufficient just to enter the expected value of the TLSA record and check against openssl for the verification lines. ### ✔️ Solution Example how to check it through dig: ``` :~$ dig +noall +answer _25._tcp.mail.protonmail.ch TLSA _25._tcp.mail.protonmail.ch. 821 IN TLSA 3 1 1 6111A5698D23C89E09C36FF833C1487EDC1B0C841F87C49DAE8F7A09 E11E979E _25._tcp.mail.protonmail.ch. 821 IN TLSA 3 1 1 76BB66711DA416433CA890A5B2E5A0533C6006478F7D10A4469A947A CC8399E1 ``` And gathering the Information with: ``` openssl s_client -starttls smtp -connect mail.protonmail.ch:25 -dane_tlsa_domain mail.protonmail.ch -dane_tlsa_rrdata "3 1 1 76BB66711DA416433CA890A5B2E5A0533C6006478F7D10A4469A947ACC8399E1" </dev/null 2>/dev/null ``` Result: ``` SSL handshake has read 3951 bytes and written 433 bytes Verification: OK Verified peername: *.protonmail.ch DANE TLSA 3 1 1 ...8f7d10a4469a947acc8399e1 matched EE certificate at depth 0 ``` ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman added the

feature-request

A:monitor

type:enhance-existing

labels

2026-02-28 03:49:04 -05:00

deekerman commented

2026-02-28 03:49:08 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Mar 24, 2025):

I have no idea who/what dane is, but we would love a PR assuming this is in the DNS spec.

The dns monitor is defined here:

For things like this, I would expect a testcase as well to ensure that we don't regress.

@CommanderStorm commented on GitHub (Mar 24, 2025): I have no idea who/what dane is, but we would love a PR assuming this is in the DNS spec. The dns monitor is defined here: - Backend: https://github.com/louislam/uptime-kuma/blob/master/server/monitor-types/dns.js - Frontend: https://github.com/louislam/uptime-kuma/blob/master/src/pages/EditMonitor.vue For things like this, I would expect a testcase as well to ensure that we don't regress.