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 <[email protected]>
wrote:
On February 18, 2026 8:05:58 AM GMT+02:00, Martin McClure via dovecot
<[1][email protected]> 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][email protected]
To unsubscribe send an email [3][email protected]
This is indeed a bug. It should get fixed in next release.
Aki
_______________________________________________
dovecot mailing list -- [4][email protected]
To unsubscribe send an email to [5][email protected]
References
Visible links
1. mailto:[email protected]
2. mailto:[email protected]
3. mailto:[email protected]
4. mailto:[email protected]
5. mailto:[email protected]
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
