🪲: Wrong certificate presented over SMTP TLS

[bjorne]

What happened?

I access stalwart over HTTPS and IMAP using an internal domain (mail.intra.domain). For this purpose I've configured a wildcard certificate (*.intra.domain) in Stalwart referencing a file (%{file:/etc/certs/wildcard.intra.domain.crt}%). This certificate is not set as default cert.

For external SMTP TLS I have set up an LetsEncrypt ACME provider with a subject name matching the external hostname of the server (x.domain). This hostname is also what is set under Network settings.

This setup has worked well and the right certificates are presented on both access paths.

Today, the internal wildcard cert (*.intra.domain) had expired giving warnings in my client. I assume this is to be expected, i.e. Stalwart does not automatically reload a %{file:...} config reference.

What wasn't expected though, was that when I did a TLS check (using checktls.com) on the external SMTP the internal wildcard cert (*.intra.domain) was presented instead of the external cert (x.domain). The check specifically complained that *.intra.domain != x.domain.

After restarting Stalwart, I am now seeing the right cert presented externally again. (The restart also fixed the expired cert, and I'm not sure if that has influenced this.) Since everything is back to working again, I am unfortunately unable to troubleshoot the issue further.

It seems like a bug that *.intra.domain cert would ever be presented on x.domain when a ACME provider for the latter is available. (It is unclear for me whether the expired status of the internal cert has contributed to this issue or whether this problem is instead an effect of some temporary problem with the ACME provider.)

External SMTP connections do have this warning logged with every connection (both before and after restart)

WARN Multiple TLS certificates available (tls.multiple-certificates-available) total = 2

How can we reproduce the problem?

Unable to reproduce after restart.

Version

v0.13.x

What database are you using?

RocksDB

What blob storage are you using?

RocksDB

Where is your directory located?

Internal

What operating system are you using?

Docker

Relevant log output

# Connection from check tls before restart - internal wildcard cert presented
2025-10-23T00:28:09Z INFO SMTP EHLO command (smtp.ehlo) listenerId = "smtp", localPort = 25, remoteIp = xxx, remotePort = 42806, domain = "xxx.checktls.co
m"
2025-10-23T00:28:09Z INFO SPF EHLO check failed (smtp.spf-ehlo-fail) listenerId = "smtp", localPort = 25, remoteIp = xxx, remotePort = 42806, domain = "xxx.checktls.com", result = No SPF record (spf.none), elapsed = 89ms
2025-10-23T00:28:09Z WARN Multiple TLS certificates available (tls.multiple-certificates-available) total = 2
2025-10-23T00:28:09Z INFO TLS handshake (tls.handshake) listenerId = "smtp", localPort = 25, remoteIp = xxx, remotePort = 42806, listenerId = "smtp", version = "T
LSv1_3", details = "TLS13_AES_256_GCM_SHA384"

# Restart stalwart
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "http", localIp = ::, localPort = 8080, tls = false
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "https", localIp = ::, localPort = 443, tls = true
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "imap", localIp = ::, localPort = 143, tls = false
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "imaptls", localIp = ::, localPort = 993, tls = true
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "pop3", localIp = ::, localPort = 110, tls = false
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "pop3s", localIp = ::, localPort = 995, tls = true
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "sieve", localIp = ::, localPort = 4190, tls = false
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "smtp", localIp = ::, localPort = 25, tls = false
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "submission", localIp = ::, localPort = 587, tls = false
2025-10-23T00:32:28Z INFO Network listener started (network.listen-start) listenerId = "submissions", localIp = ::, localPort = 465, tls = true
2025-10-23T00:32:28Z INFO Processing ACME certificate (acme.process-cert) id = "letsencrypt-xxx-http", hostname = ["x.domain"], validFrom = 2025-09-19T09:01:28Z, validTo = 2025-12-18T09:01:27Z, due = 2025-11-18T09:01:27Z

# Connection from check tls after restart - x.domain cert presented
2025-10-23T00:32:51Z INFO SMTP EHLO command (smtp.ehlo) listenerId = "smtp", localPort = 25, remoteIp = xxx, remotePort = 44242, domain = "xxx.checktls.com"
2025-10-23T00:32:51Z INFO SPF EHLO check failed (smtp.spf-ehlo-fail) listenerId = "smtp", localPort = 25, remoteIp = xxx, remotePort = 44242, domain = "xxx.checktls.com", result = No SPF record (spf.none), elapsed = 2ms
2025-10-23T00:32:51Z WARN Multiple TLS certificates available (tls.multiple-certificates-available) total = 2
2025-10-23T00:32:51Z INFO TLS handshake (tls.handshake) listenerId = "smtp", localPort = 25, remoteIp = xxx, remotePort = 44242, listenerId = "smtp", version = "TLSv1_3", details = "TLS13_AES_256_GCM_SHA384"

Code of Conduct

• I agree to follow this project's Code of Conduct

[mdecimus]

Two things to check:

Stalwart referencing a file (%{file:/etc/certs/wildcard.intra.domain.crt}%). This certificate is not set as default cert.

Macros are not evaluated for settings stored in the database. Make sure macros appear only in local settings defined in the TOML.

2025-10-23T00:32:51Z WARN Multiple TLS certificates available (tls.multiple-certificates-available) total = 2

This means that the client is not providing a hostname during the TLS handshake and, since you have multiple certificates, Stalwart does not know which one to choose.

[bjorne]

Hey, thanks for replying!

Macros are not evaluated for settings stored in the database. Make sure macros appear only in local settings defined in the TOML.

I set it in the config.toml (double checked now) and it's working well under normal circumstances.

This means that the client is not providing a hostname during the TLS handshake and, since you have multiple certificates, Stalwart does not know which one to choose.

OK, interesting! So there is a measure of non-determinism involved? In this case, wouldn't it make sense that Stalwart defaults to the cert with subject name matching the configured server.hostname? (This is what it regularly does for me, but suddenly not at the time of the incident.)

[mdecimus]

OK, interesting! So there is a measure of non-determinism involved? In this case, wouldn't it make sense that Stalwart defaults to the cert with subject name matching the configured server.hostname? (This is what it regularly does for me, but suddenly not at the time of the incident.)

I'm by no means a TLS expert but from my experience as a Stalwart maintainer, if a client does not provide a SNI during handshake then there is something broken in the client configuration. For this reason Stalwart does not assume any defaults.

[bjorne]

Got it!

I guess what I need to do to make sure the certificate selection is deterministic in this case is to set default for my acme provider:

default: If set to true, certificate obtained by this ACME provided will be used when the client does not provide an SNI server name.

I had missed this option before.

Thanks for your help (and for Stalwart!)