Thank you very much, Aki! After wasting 3+ hrs on this today, I stepped over this thread - just in time. This workaround works perfectly and I appreciate you are going to fix it for good it in the next release.
Just for those who still struggle with it:
Use !include_try ssl.conf (not try_include as posted by Aki). And if you have your ssl_server_key_file already in conf.d/10-ssl.conf, you might already be using include_try in your dovecot.conf as provided by Debian packages:
!include_try conf.d/*.conf
So you just need to make sure only root can read it: $ chmod 640 conf.d/10-ssl.conf And the include_try will silently fail for dovecot-lda (invoked by Postfix and ideally running under user dovecot, or even a more restricted user vmail).
Cheers, Philip
On 18 Feb 2026, at 08:02, Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On February 18, 2026 8:05:58 AM GMT+02:00, Martin McClure via dovecot <dovecot@dovecot.org <mailto:dovecot@dovecot.org>> wrote:
Thanks, Ralph.
OK, that makes sense. Dovecot reads the config file (not a bug) and if it sees the name of the ssl key_file it tries to read /that/ file (yeah, that sounds very much like a bug) and when it can't it bails. It should only try to read the cert/key files if it is going to need to use them.
And wrapping the cert/key filenames in a config file that is itself unreadable is evil and clever and, well, useful in this case.
Regards,
-Martin
On 2/17/26 6:33 PM, Ralph Seichter via dovecot wrote:
- Martin McClure via dovecot:
Is this expected behavior in 2.4, or is it considered a bug? I'm not Aki, but since I ran into the same issue a while back: I'd like to repeat that I do consider this to be a bug. It also affects doveadm use, for example.
The problem occurs when a non-root process triggers evaluation of the Dovecot config and is unable to read the TLS key files. Protecting these files is of course important, and some random user invoking doveadm in their command shell should have no reason to access sensitive files. IMO, Dovecot should not even attempt to read TLS related files in this case. They are not needed at this time.
If it's expected behavior, why does this workaround work? The "!include_try foo.conf" succeeds when run as root, e.g. during Dovecot startup, but fails silently for non-root owned processes. That's why it works as a workaround.
-Ralph
dovecot mailing list --dovecot@dovecot.org <mailto:dovecot@dovecot.org> To unsubscribe send an email todovecot-leave@dovecot.org <mailto:todovecot-leave@dovecot.org> This is indeed a bug. It should get fixed in next release.
Aki
dovecot mailing list -- dovecot@dovecot.org <mailto:dovecot@dovecot.org> To unsubscribe send an email to dovecot-leave@dovecot.org <mailto:dovecot-leave@dovecot.org>
Thank you very much, Aki!
After wasting 3+ hrs on this today, I stepped over this thread - just in
time.
This workaround works perfectly and I appreciate you are going to fix it
for good it in the next release.
Just for those who still struggle with it:
Use !include_try ssl.conf (not try_include as posted by Aki). And if
you have your ssl_server_key_file already in conf.d/10-ssl.conf, you might
already be using include_try in your dovecot.conf as provided by Debian
packages:
!include_try conf.d/*.conf
So you just need to make sure only root can read it:
$ chmod 640 conf.d/10-ssl.conf
And the include_try will silently fail for dovecot-lda (invoked by Postfix
and ideally running under user dovecot, or even a more restricted user
vmail).
Cheers,
Philip
On 18 Feb 2026, at 08:02, Aki Tuomi via dovecot <dovecot@dovecot.org>
wrote:
On February 18, 2026 8:05:58 AM GMT+02:00, Martin McClure via dovecot
<[1]dovecot@dovecot.org> wrote:
Thanks, Ralph.
OK, that makes sense. Dovecot reads the config file (not a bug) and if
it sees the name of the ssl key_file it tries to read /that/ file
(yeah, that sounds very much like a bug) and when it can't it bails.
It should only try to read the cert/key files if it is going to need
to use them.
And wrapping the cert/key filenames in a config file that is itself
unreadable is evil and clever and, well, useful in this case.
Regards,
-Martin
On 2/17/26 6:33 PM, Ralph Seichter via dovecot wrote:
* Martin McClure via dovecot:
Is this expected behavior in 2.4, or is it considered a bug?
I'm not Aki, but since I ran into the same issue a while back: I'd
like
to repeat that I do consider this to be a bug. It also affects
doveadm
use, for example.
The problem occurs when a non-root process triggers evaluation of
the
Dovecot config and is unable to read the TLS key files. Protecting
these
files is of course important, and some random user invoking doveadm
in
their command shell should have no reason to access sensitive files.
IMO, Dovecot should not even attempt to read TLS related files in
this
case. They are not needed at this time.
If it's expected behavior, why does this workaround work?
The "!include_try foo.conf" succeeds when run as root, e.g. during
Dovecot startup, but fails silently for non-root owned processes.
That's
why it works as a workaround.
-Ralph
_______________________________________________
dovecot mailing list --[2]dovecot@dovecot.org
To unsubscribe send an email [3]todovecot-leave@dovecot.org
This is indeed a bug. It should get fixed in next release.
Aki
_______________________________________________
dovecot mailing list -- [4]dovecot@dovecot.org
To unsubscribe send an email to [5]dovecot-leave@dovecot.orgReferences
Visible links
- mailto:dovecot@dovecot.org
- mailto:dovecot@dovecot.org
- mailto:todovecot-leave@dovecot.org
- mailto:dovecot@dovecot.org
- mailto:dovecot-leave@dovecot.org