SSL initialization error - Dovecot 2.4.1, Fedora 43 beta
I'm trying Dovecot 2.4.1 under Fedora 43 beta with all packages up to date. I've encountered several issues after attempting to update my configuration. The main problem is this: whenever a client attempts to connect, I get the following error
Error: Failed to initialize SSL connection: Couldn't initialize SSL server context: Can't load SSL certificate (ssl_server_cert_file setting): error:0A00018F:SSL routines::ee key too small:
I'm using a SECP384R1 key issued by letsencrypt.org, which should satisfy security checks. My Web searches have not identified a relevant bug report.
Have others encountered this issue? If it's distribution-specific, I can visit the relevant bug tracker.
Thank you for your consideration.
On Mon, 2025-10-06 at 12:23 -0400, Jason J.G. White via dovecot wrote:
I'm trying Dovecot 2.4.1 under Fedora 43 beta with all packages up to date. I've encountered several issues after attempting to update my configuration. The main problem is this: whenever a client attempts to connect, I get the following error
Error: Failed to initialize SSL connection: Couldn't initialize SSL server context: Can't load SSL certificate (ssl_server_cert_file setting): error:0A00018F:SSL routines::ee key too small:
There are some quirks in 2.4.1 where environment variables don't work for ssl cert specification (or in some other areas).
May be different issue to yours, as this might have been a problem using doveconf to check config, or at server start. But it was quite some time back now, so not sure at this point. It has been working quite well here.
But, in case it's relevant, you may want to avoid env things: i.e.
dont use the $ENV.xxx to specify cert dir stuff - it doesn't work.
Fill in the path explicitly.
ssl_server { # broken: cert_file = $ENV:cert_dir/fullchain.pem # broken: key_file = $ENV:cert_dir/privkey.pem cert_file = /path/to/fullchain.pem key_file = /path/to/privkey.pem prefer_ciphers = client }
-- Gene
Genes Lists via dovecot <dovecot@dovecot.org> wrote:
There are some quirks in 2.4.1 where environment variables don't work for ssl cert specification (or in some other areas).
May be different issue to yours, as this might have been a problem using doveconf to check config, or at server start. But it was quite some time back now, so not sure at this point. It has been working quite well here.
Thank you - that's useful to know. In my configuration, the full paths to certificate files are specified, so this isn't the issue here, but I'll bear it in mind elsewhere.
Error: Failed to initialize SSL connection: Couldn't initialize SSL server context: Can't load SSL certificate (ssl_server_cert_file setting): error:0A00018F:SSL routines::ee key too small:
not seeing your config, or your certs, here's one quick check. long ago, i saw your error as a result of weak too-weak DH param.
check,
$ cd /etc/dovecot/
$ grep -i dh_ dovecot.conf conf.d/*
conf.d/10-ssl.conf: dh_file = /etc/ssl/dh4096.pem
$ openssl dhparam -in /etc/ssl/dh4096.pem -text -noout | grep bit
DH Parameters: (4096 bit)
is that param _set_ in your config, and if so, what's the reported bit depth?
iirc(?), on current OpenSSL releases, min bit depth reqt's are
EC Keys: >= 224 bits
RSA keys: >= 2048 bits
DH params: >= 2048 bits
EdDSA: Ed25519 & Ed448 are good
& depths below, e.g. 1024b RSA or DH, are rejected
i.e., verify your cert bit depths. if only to rule them out.
EC Keys: >= 224 bits RSA keys: >= 2048 bits DH params: >= 2048 bits EdDSA: Ed25519 & Ed448 are good
& depths below, e.g. 1024b RSA or DH, are rejected
Hmm - when using elliptic curve algos like X25519 / x448 I don't think dh params are needed/used any longer - are they?
And if they were being used (with rsa or whatever), aren't finite field like ffde4096 (a la rfc 7919 [1]) the preferred choice?
If were me, I would completely eliminate any RSA certs anyway - there's no longer any need to use them at all.
[1] https://datatracker.ietf.org/doc/html/rfc7919
--
Gene
Hmm - when using elliptic curve algos like X25519 / x448 I don't think dh params are needed/used any longer - are they?
And if they were being used (with rsa or whatever), aren't finite field like ffde4096 (a la rfc 7919 [1]) the preferred choice?
If were me, I would completely eliminate any RSA certs anyway - there's no longer any need to use them at all. it depends on what usage is configured. true if using TLS v >=1.3 or EC only.
it's unclear 2 me what specific certs/configs are being used by the OP. if no, or a too weak, DH parameter is provided, and any DHE cipher suite is config as available for use, OpenSSL will refuse to perform any handshake that uses it.
i don't know atm what checks are IN Dovecot 2.4.1, and whether they exercise the config _options_ beyond the particular certs in use.
in any case, since it's a first guess, checking bit depths where the error is 'too weak', seems an easy check.
as for getting rid of RSA, that's an available choice. it's not "100%" viable. whether one cares is a different issue, depends on your use case
pgnd <pgnd@dev-mail.net> wrote:
not seeing your config, or your certs, here's one quick check. long ago, i saw your error as a result of weak too-weak DH param.
Thank you - that was it. 4096 bits were insufficient.
It's an old configuration that hadn't been changed significantly for years. The update to 2.4 is my opportunity to revisit it and to relearn the details.
On 07/10/2025 02:45 EEST Jason White via dovecot
<[1]dovecot@dovecot.org> wrote:
pgnd <[2]pgnd@dev-mail.net> wrote:
not seeing your config, or your certs, here's one quick check.
long ago, i saw your error as a result of weak too-weak DH param.
Thank you - that was it. 4096 bits were insufficient.
It's an old configuration that hadn't been changed significantly for
years. The update to 2.4 is my opportunity to revisit it and to relearn
the details.
_______________________________________________
dovecot mailing list -- [3]dovecot@dovecot.org
To unsubscribe send an email to [4]dovecot-leave@dovecot.org
You can also just drop dh parameters. It is unlikely you need them, and they have been optional for quite many versions now.
Aki
References
Visible links
- mailto:dovecot@dovecot.org
- mailto:pgnd@dev-mail.net
- mailto:dovecot@dovecot.org
- mailto:dovecot-leave@dovecot.org
participants (5)
-
Aki Tuomi
-
Genes Lists
-
Jason J.G. White
-
Jason White
-
pgnd