Issue Description
I am not sure if there’s something else not working with my Docker image, since I get a Temporary Server Failure when I want to login.But the Acme certificate retriever is not working for me. The docker is reachable over the internet, but still:
2026-05-08T18:45:11Z DEBUG TLS certificate not found (tls.certificate-not-found) hostname = “mail3.myserver.com”
On the logs it says it has requested too much, and the response for let’s encrypt is that it should try after some time.
The server is exposed on port 443, so I’m not sure why it is failing, since the logs don’t say much.
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
FoundationDB
Blob Storage
S3-compatible
Search Engine
Internal
Directory Backend
LDAP
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on
There are a few common causes for ACME/Let’s Encrypt certificate retrieval failures in Docker deployments. Based on what you’ve described, here are the most likely issues to investigate:
1. Rate-limiting by Let’s Encrypt
The logs mention “requested too much” — Let’s Encrypt enforces strict rate limits (e.g. 5 duplicate certificate requests per week). If you’ve already hit those limits, you must wait before it will succeed, regardless of any config fix. Check the exact retry-after time from the ACME response.
2. ACME challenge type vs. Docker port exposure
Stalwart supports multiple ACME challenge types: TLS-ALPN-01, HTTP-01, and DNS-01. In Docker:
- TLS-ALPN-01 requires port 443 to be reachable directly by Let’s Encrypt’s servers — no reverse proxy in front that terminates TLS before it reaches Stalwart.
- HTTP-01 requires port 80 to be reachable and requests to
/.well-known/acme-challenge/ to be forwarded to Stalwart.
- If a reverse proxy (nginx, Traefik, etc.) is in front of Stalwart and terminates TLS, the TLS-ALPN-01 challenge will fail because Let’s Encrypt never reaches Stalwart itself.
3. Port mapping in Docker
Confirm your docker run or docker-compose.yml correctly maps host port 443 → container port 443 (and 80 → 80 if using HTTP-01). Also confirm no other process on the host is binding those ports.
4. tls.certificate-not-found debug message
This log line (tls.certificate-not-found) indicates that at connection time no valid certificate exists for mail3.myserver.com yet — this is expected if ACME provisioning hasn’t completed. The root issue is the ACME provisioning failure, not the missing cert itself.
Suggested next steps:
- Review your ACME provider configuration in the WebUI under Settings → TLS and confirm the challenge type matches your network topology.
- Check for the exact Let’s Encrypt error code in your logs (it should report an
urn:ietf:params:acme:error:* code that names the specific failure).
- If you’re behind a reverse proxy, either switch to DNS-01 or ensure port 443 passes through to Stalwart without TLS termination at the proxy level.
- For the rate limit issue, you can temporarily switch to Let’s Encrypt’s staging environment to test without consuming quota.
The relevant docs are at stalw.art/docs/domains/tls-certificates and stalw.art/docs/server/tls/.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.
Let’s Encrypt paused certificate issuance earlier today, to investigate an incident
Stalwart does obtain the certificate but does not apply them to the running instance. In my case, I restarted the Docker container and the certificates finally got loaded!
Seems to be a bug currently (0.16.4).
I restarted a few times and no certificate was retrieved.
it got the certificate after a few attempts later.