Yes, that didn‘t work either (by removing inline: from the variable and setting it in the config). I discovered yesterday that you can set „crypt_private_key_file“ in userdb and that this sets the global private key file (note that there is no prefix/named filter).
I can live with that, but I guess the correct way should‘ve be „crypt_global_private_key/user/crypt_private_key_file“, but latter is non-functional, despite documented. (Named list filter „user“ is set with empty content in config, so it should exist, but isn‘t reachable from userdb…)
Am 07.04.2026 um 07:11 schrieb Aki Tuomi <aki.tuomi@open-xchange.com>:
On 05/04/2026 22:18 EEST Ömer Güven via dovecot <dovecot@dovecot.org> wrote:
Hi,
I’ve run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key.
I don‘t use per-folder user keys but a global encryption key per user.
Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it.
With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a „protocol imap“ scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+.
When using the following workaround to reach the scoped variables, Dovecot tries to load the file „inline:BASE64ENCODEDPEM“ as a literal filename (error open(inline:AB….C==) failed):
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } }
As a workaround, I now have to: • store the private key as a file (e.g. %{home}/privkey.pem) • pass only the password via userdb • inject the path indirectly via static config + userdb variables
This works, but is less elegant:
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } }
Again, with the new named filter mechanism, it’s no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory.
Ömer Hi, I've run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key. I don`t use per-folder user keys but a global encryption key per user. Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it. With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a "protocol imap" scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+. When using the following workaround to reach the scoped variables, Dovecot tries to load the file "inline:BASE64ENCODEDPEM" as a literal filename (error open(inline:AB....C==) failed):
}As a workaround, I now have to: o store the private key as a file (e.g. %{home}/privkey.pem) o pass only the password via userdb o inject the path indirectly via static config + userdb variables This works, but is less elegant:
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } }Again, with the new named filter mechanism, it's no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory. Oemer
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hi!
Did you try
protocol imap { crypt_global_private_key user { crypt_private_key_file = inline:%{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } }
See https://doc.dovecot.org/2.4.3/core/settings/types.html#file
Aki