We use "password_algorithm = dovecot". Please make sure you have correct path to doveadm in parameter "password_dovecotpw".

debian 11
iRedMail 1.5.1 PGSQL

I'm getting the same error when a user tries to change their password. In /opt/www/roundcubemail/plugins/password/config.inc.php I'm seeing:

$config['password_algorithm'] = "dovecot";

and

$config['password_dovecotpw'] = "/usr/bin/doveadm pw";

The path in the second line is valid. I changed lines 49 and 53 as recommended by cavy and users can now change their password.

After much looking around I've found what the issue(s) are.

As a MariaDB install of Roundcube uses the SQL driver, there are a couple of entries in the config.inc.php for roundcube that need to be updated.

1.
Default entry - $config['password_algorithm'] = "dovecot";
Should be - $config['password_algorithm'] = "ssha512";

2.
Default entry - $config['password_algorithm_prefix'] = "dovecot";
Should be - $config['password_algorithm_prefix'] = "{SSHA512}";

Maybe devs this should be updated in the install process?

Hope this helps someone.

$salt = random_str(8);
$hashed_password = hash('sha512', $password . $salt, true);
$password = '{SSHA512}' . base64_encode($hashed_password . $salt);

does not rely on dovecot at all and works the same

This still appears to be an issue, I've just done a fresh install on Debian 11 with MariaDB.

Created a bunch of users via sql script.

First user logs in and get this error when trying to change their password.

I've turned on debugging in the config, as per https://docs.iredmail.org/debug.roundcubemail.html, but show very little helpful info on why this is failing.

Could we have a IRedMail dev respond please?

Thank you for your help.

Yes, its true. After solution problem with fullchain, there is second problem with private key of dovecot.

doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 50: ssl_key: Can't open file /etc/ssl/private/iRedMail.key: Permission denied

There is problem in key rights and in rights of private directory. But I am not so brave open this for all users.

I see two ways:
1. forget for dovecot generated passwords and generate passwords with other way
2. disable changing password over roundcube

Any other ways are security risk.

Nooo, its not possible to login into iredadmin for common users!!!

The problem is related to dovecot, since it runs with user priv, normally it runs as root but in this case, it gets called by php and thus runs as www-data, but the ssl certs are protected and not readable by www-data

doveadm should not try to read those certs when only generating a password, so this problem is more related to dovecot and/or roundcube (which handles the call to doveadm)

there are several workarounds for sure, it just depends on how you want to handle it

Yes, its true. After solution problem with fullchain, there is second problem with private key of dovecot.

doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 50: ssl_key: Can't open file /etc/ssl/private/iRedMail.key: Permission denied

There is problem in key rights and in rights of private directory. But I am not so brave open this for all users.

I see two ways:
1. forget for dovecot generated passwords and generate passwords with other way
2. disable changing password over roundcube

Any other ways are security risk.

doveadm should not try to read those certs when only generating a password, so this problem is more related to dovecot and/or roundcube (which handles the call to doveadm)

there are several workarounds for sure, it just depends on how you want to handle it

i dont know why doveadm should even consider reading a ssl cert when only generating a password, but you can for sure get around it:

$crypted = exec(escapeshellcmd("sudo /usr/bin/doveadm pw -s 'ssha512' -p " . $pass));

combined with giveing www-data root priv to run /usr/bin/doveadm, this should bypass the problems

BUT: it opens many possibilites to exploit, if you have webpages hosted that all run under www-data, you give all pages the possibility to run doveadm with root priv!

for that reason, i dun run nginx, i run apache with fcgid as wrapper and give every hosted page an own user/groupid where all php scripts are run under their own encapsulated environment

for myself, i really dont like nginx and the fpm approach, but i also use a very hardened and hardpatched php environment to avoid privilege escalation possibilities and only grant special rights to each user for certain php functions that otherwise could result in many possible php related security issues like basedir escaping or even privilegued shell access via web!

I finally found main problem, its letsencrypt. iRedMail.crt is linked to letsencrypt directory, which has 700. I am thinking about cron script for copying crt every day and set it correct rights.
Chm, still not working, but already not due crt rights. I am going investigate.

i dont know why doveadm should even consider reading a ssl cert when only generating a password, but you can for sure get around it:

$crypted = exec(escapeshellcmd("sudo /usr/bin/doveadm pw -s 'ssha512' -p " . $pass));

combined with giveing www-data root priv to run /usr/bin/doveadm, this should bypass the problems

BUT: it opens many possibilites to exploit, if you have webpages hosted that all run under www-data, you give all pages the possibility to run doveadm with root priv!

for that reason, i dun run nginx, i run apache with fcgid as wrapper and give every hosted page an own user/groupid where all php scripts are run under their own encapsulated environment

for myself, i really dont like nginx and the fpm approach, but i also use a very hardened and hardpatched php environment to avoid privilege escalation possibilities and only grant special rights to each user for certain php functions that otherwise could result in many possible php related security issues like basedir escaping or even privilegued shell access via web!

Thank you, on servers for company or customers, I have it in similar way. But this is small server for few domains for me and my friends - so its not critical for me and I dont want to spend much time for solution by myself and so I would be rather for official solution because of updates, eg.
I can tell users to change password over iredadmin and disable password plugin in roundcube, but it would be nice to repair it. This is standard iRedmail installation on Debian 11, hope it helps for solution.

$crypted = exec(escapeshellcmd("sudo /usr/bin/doveadm pw -s 'ssha512' -p " . $pass));

combined with giveing www-data root priv to run /usr/bin/doveadm, this should bypass the problems

BUT: it opens many possibilites to exploit, if you have webpages hosted that all run under www-data, you give all pages the possibility to run doveadm with root priv!

for that reason, i dun run nginx, i run apache with fcgid as wrapper and give every hosted page an own user/groupid where all php scripts are run under their own encapsulated environment

for myself, i really dont like nginx and the fpm approach, but i also use a very hardened and hardpatched php environment to avoid privilege escalation possibilities and only grant special rights to each user for certain php functions that otherwise could result in many possible php related security issues like basedir escaping or even privilegued shell access via web!

if this code snippet is not working:

give www-data access to execute /usr/bin/doveadm via visudo

I need sleeping, why I didnt try this at the first time - run doveadm from command line as a unprivileged user. And here is result.

doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 49: ssl_cert: Can't open file /etc/ssl/certs/iRedMail.crt: Permission denied

give www-data access to execute /usr/bin/doveadm via visudo

The solution is: in plugin/password/config.inc.php, set "password_algorithm" to "dovecot", then replace "%D" by "%P".

Sorry, this solution is not working, it looks, that main problem is in function proc_open as I reported in this thread today.

why so complicated?

$crypted = exec(escapeshellcmd("/usr/bin/doveadm pw -s 'ssha512' -p " . $pass));

Hello, I agree, it was part of password.php in roundcubemail.