When clients via smtp doesn’t support ECDSA, they won’t have an TLS encrypted session cause of ACME is issuing only ECDSA certificate for TLS. We need that simultaneous or a way to choose which certificate. Otherwise there will be users send mails unencrypted when Stalwart is offering secure connections
Expected Behavior
Users (old clients) should be able to send secure messages via RSA encryption
Actual Behavior
Stalwart ACME is issuing only ECDSA certificate
Reproduction Steps
Use ACME on domain
lookup the issued certificate
Stalwart Version
v0.16.x
Installation Method
Binary (Windows)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
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.
This confirms it: the ACME implementation hard-codes ECDSA P-256 (PKCS_ECDSA_P256_SHA256) for certificate key generation, with no configuration option for RSA. This matches the reported behavior in the source code.
The AcmeProvider object’s documented fields (challengeType, renewBefore, maxRetries, contact, preferredChain, reuseKey) also confirm there’s no key-algorithm selector exposed.
For a client that truly cannot negotiate ECDSA cipher suites, the workaround today is to switch that domain to manual certificate management and install an RSA certificate from another CA (or a self-managed RSA cert) alongside/instead of the ACME-issued one, since Manual mode lets the TLS listener present whichever installed Certificate’s SAN matches the SNI.
Reply:
Confirmed: Stalwart’s ACME implementation currently issues only ECDSA (P-256) certificates and generation is hard-coded, there is no setting on the AcmeProvider object to request an RSA key or to issue both ECDSA and RSA certificates side by side for automatic (ACME) mode.
If you need RSA support for legacy clients that can’t negotiate ECDSA cipher suites, the current workaround is to switch that domain’s certificateManagement to Manual and install an RSA certificate (obtained separately, e.g. via certbot with --key-type rsa, or another CA) as a Certificate object. In Manual mode the TLS listener matches incoming SNI against the Subject Alternative Names of every installed certificate, so you can have both an ECDSA and an RSA certificate installed and it will pick a match, but there’s currently no way to have ACME automatically manage both key types for the same domain.
You have read it right: ACME certificates here are always ECDSA P-256, the key type is hardcoded and there is no setting for it.
The part that makes this more than a missing option is the certificate resolver. It stores one certificate per SNI name and does not select on the client’s advertised signature algorithms, so RSA and ECDSA cannot be served side by side even if you installed the RSA one by hand. The only thing that works today is switching that domain to manual certificate management and installing an RSA certificate, which then applies to every client rather than just the ones that need it.