IMAPS and SMTPS present rcgen certificate while HTTPS presents valid ACME certificate

Issues
1

Issue Description

Stalwart Server v0.16.9 (Docker)

Environment

  • Docker deployment
  • ACME configured using TLS-ALPN-01
  • Certificate hostname: mail.junk.frankpannier.online
  • Default hostname: mail.junk.frankpannier.online
  • Default certificate: mail.junk.frankpannier.online

Certificate Details

  • Issuer: Let’s Encrypt (YE1)
  • Valid From: 19 Jun 2026
  • Expires: 17 Sep 2026
  • SAN: mail.junk.frankpannier.online

Observed Behaviour

HTTPS presents the correct Let’s Encrypt certificate:

openssl s_client -connect localhost:443 -servername mail.junk.frankpannier.online </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

Result:

subject=CN = mail.junk.frankpannier.online
issuer=C = US, O = Let's Encrypt, CN = YE1

IMAPS presents the built-in rcgen certificate:

openssl s_client -connect localhost:993 -servername mail.junk.frankpannier.online </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

Result:

subject=CN = rcgen self signed cert
issuer=CN = rcgen self signed cert

SMTPS presents the built-in rcgen certificate:

openssl s_client -connect localhost:465 -servername mail.junk.frankpannier.online </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

Result:

subject=CN = rcgen self signed cert
issuer=CN = rcgen self signed cert

Additional Information

  • Mail services are functioning correctly.
  • SMTP sending works via SMTP2GO relay.
  • IMAP access works.
  • DNS is correct.
  • ACME certificate is valid and visible in the Stalwart UI.
  • The certificate is configured as the Default Certificate in Network Settings.
  • HTTPS uses the certificate correctly, but IMAPS and SMTPS continue to serve rcgen.

Question

Is there a separate certificate binding or listener configuration required for SMTP/IMAP listeners in v0.16.9, or is this a known issue?

Expected Behavior

A valid Let’s Encrypt certificate configured as the default certificate should be presented consistently across all TLS-enabled services, including HTTPS, IMAPS and SMTPS.

The certificate currently configured in Stalwart (mail.junk.frankpannier.online) should be served on ports 443, 993 and 465 when clients connect using SNI hostname mail.junk.frankpannier.online.

Actual Behavior

HTTPS (port 443) presents the correct Let’s Encrypt certificate:

CN = mail.junk.frankpannier.online
Issuer = Let’s Encrypt (YE1)

However, IMAPS (port 993) and SMTPS (port 465) present the built-in rcgen self-signed certificate:

CN = rcgen self signed cert
Issuer = rcgen self signed cert

Mail functionality itself appears normal. The issue is limited to certificate presentation on the mail listeners.

Reproduction Steps

  1. Deploy Stalwart Server v0.16.9 in Docker.
  2. Configure ACME using TLS-ALPN-01.
  3. Obtain a valid Let’s Encrypt certificate for mail.junk.frankpannier.online.
  4. Set the certificate as the Default Certificate in Network Settings.
  5. Verify HTTPS:

openssl s_client -connect localhost:443 -servername mail.junk.frankpannier.online

Result: Let’s Encrypt certificate presented.

  1. Verify IMAPS:

openssl s_client -connect localhost:993 -servername mail.junk.frankpannier.online

Result: rcgen self-signed certificate presented.

  1. Verify SMTPS:

openssl s_client -connect localhost:465 -servername mail.junk.frankpannier.online

Result: rcgen self-signed certificate presented.

Relevant Log Output

No relevant certificate-related messages are present in the container logs at the default logging level.

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

Docker deployment.

Certificate details:

  • Hostname: mail.junk.frankpannier.online
  • SAN: mail.junk.frankpannier.online
  • Issuer: Let’s Encrypt (YE1)
  • Valid until 17 September 2026

Network Settings:

  • Default Hostname: mail.junk.frankpannier.online
  • Default Domain: junk.frankpannier.online
  • Default Certificate: mail.junk.frankpannier.online

Localhost testing confirms:
443 → Let’s Encrypt certificate
993 → rcgen self-signed certificate
465 → rcgen self-signed certificate

The issue is reproducible both externally and from localhost, ruling out DNS, Cloudflare, firewall and reverse proxy configuration.
A localhost test confirms that the issue occurs entirely within Stalwart itself. HTTPS (443) presents the Let’s Encrypt certificate while IMAPS (993) and SMTPS (465) present the built-in rcgen certificate, despite the same default certificate being configured globally.

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

2

This is a well-documented area. Based on the docs, the key issue is likely that the Domain object for mail.junk.frankpannier.online (or junk.frankpannier.online) does not have certificateManagement set to Automatic with an acmeProviderId, so the ACME certificate is only being served on the HTTPS listener (which may have special handling for TLS-ALPN-01), while IMAP and SMTP listeners fall back to the built-in rcgen self-signed certificate because the domain isn’t wired to the ACME provider.

Here is what is happening and how to fix it:

The ACME certificate is visible in the UI and working on HTTPS because the TLS-ALPN-01 challenge itself runs over port 443. However, the IMAP (993) and SMTP (465) listeners select a certificate by matching the client’s SNI value against the Subject Alternative Names of certificates registered to Domain objects. If the Domain object for your hostname does not have certificateManagement set to Automatic (pointing at your ACME provider), those listeners have no ACME-issued certificate to present and fall back to the rcgen self-signed one.

Steps to fix:

  1. In the WebUI, go to Settings > Domains and open the domain entry for junk.frankpannier.online (or mail.junk.frankpannier.online if it exists as a separate domain).
  2. Check the certificateManagement field. It needs to be set to the Automatic variant, with acmeProviderId pointing to your Let’s Encrypt ACME provider.
  3. The subjectAlternativeNames list can be left empty to use the default SANs derived from the domain, or you can explicitly add mail.junk.frankpannier.online.
  4. Save the domain. The ACME renewal task will confirm the existing certificate or trigger re-issuance if needed, and the TLS listeners will then match the SNI mail.junk.frankpannier.online against that certificate’s SANs and present it correctly on all listeners (443, 993, 465).

Also verify in Settings > Network > System Settings that defaultCertificateId points to the correct certificate, which covers clients that connect without sending SNI.

From the docs:

“The TLS listener matches an incoming connection’s Server Name Indication against the Subject Alternative Names of every installed Certificate and presents the newest certificate that matches.”
“Each Domain that needs an automatically managed certificate sets its certificateManagement to the Automatic variant, which carries an acmeProviderId reference to the AcmeProvider.”

Reference: TLS Certificates - Domains and ACME Configuration

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

That’s great troubleshooting, I wonder what would happen if you tried Actions → Reload TLS. You shouldn’t have to, but it might point to a failure point.

4

Thanks a lot. Tried this. Update: upgraded from Stalwart 0.16.9 to 0.16.10. The issue persists.

IMAPS 993:
subject=CN = rcgen self signed cert
issuer=CN = rcgen self signed cert

SMTPS 465:
subject=CN = rcgen self signed cert
issuer=CN = rcgen self signed cert

The Let’s Encrypt certificate and private key on the host match. In Stalwart admin, the default certificate is set to mail.junk.frankpannier.online, and only that certificate is listed. However, editing the domain still shows “ACME provider not found”, and Reload TLS reports “Invalid certificate: No private keys found.”

5

Yeah, that’s a failure point for sure, reload should come back with No additional data returned.

A fresh install with broken ACME, there is something in your specific steps that is breaking, I can’t duplicate it. Hopefully the developer can suggest a test point.