# TLS requirements \[why not self-signed\]

**URL:** <https://forum.delta.chat/t/tls-requirements-why-not-self-signed/5077>\
**Category:** Chatmail Relays\
**Tags:** open-standards, security, chatmail\
**Created:** [April 16, 2026, 7:43pm UTC](https://forum.delta.chat/t/tls-requirements-why-not-self-signed/5077 "2026-04-16T19:43:21Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![link2xt](https://forum.delta.chat/letter_avatar_proxy/v4/letter/l/ee7513/32.png) [@link2xt](https://forum.delta.chat/u/link2xt)\
**Post date:** [April 16, 2026, 8:58pm UTC](https://forum.delta.chat/t/tls-requirements-why-not-self-signed/5077/3 "2026-04-16T20:58:20Z")

</div>

For the client2server connection TLS certificate is needed to make sure user credentials cannot be sniffed out. It is nearly trivial to setup a fake Wi-Fi access point with the same name and password and MITM connections there. Once you have login and password of the mailbox, you can monitor when user receives messages persistently even after the user has switched to another network. This could be mitigated with some cryptography e.g. by using SCRAM authentication like most XMPP server do (as long as user connection is not MITMed during the “registration”), or by using [OPAQUE](https://datatracker.ietf.org/doc/rfc9807/) which is not standardized or implemented by anyone for email, but we are not there yet.

> [@Lardier](#):
>
> For the server operator it’s one way less to keep anonymus.

I don’t get this, you only need a domain name to get a certificate, and your domain name is already known.

> [@Lardier](#):
>
> It also increses the monthly server costs if you buy the certificate.

Certificates are free, you don’t need to buy one.

> [@Lardier](#):
>
> On the other hand if many servers use certificates from Let’s Encrypt, big area of the network depends on one provider. This is automatically is a vunerablity.

Depending on certificate renewal is indeed a problem, e.g. during internet shutdowns they cannot be renewed. For client2server there is a work in progress to keep the server usable even if certificate expires: [feat: allow TLS connections with invalid certificate if the key is unchanged by link2xt · Pull Request #8086 · chatmail/core · GitHub](https://github.com/chatmail/core/pull/8086)

For server2server connections using not self-signed certificate is probably less important than for client2server connections, but you can still at least detect MITM if you use CAA records or monitor certificate transparency logs. We are anyway moving the code for connection between chatmail relays into Rust, so may eventually move similar logic that will allow using expired certificates: [feat(transport): Remote delivery over SMTP by j-g00da · Pull Request #104 · chatmail/filtermail · GitHub](https://github.com/chatmail/filtermail/pull/104) Currently chatmail relays lose federation when certificates expire.

---

_[View the full topic](https://forum.delta.chat/t/tls-requirements-why-not-self-signed/5077)._