Disable Client Certificate Authentication for Unencrypted Connections?
I’m using dovecot to provide encrypted IMAP e-mail support for remote clients and it’s working great. However, I also need to set up a webmail front-end (Roundcube), which I’m hoping to have use unencrypted IMAP on port 143 (as only port 993 is available externally).
The problem I’m running into is that I want to require client certificate authentication on port 993, but dovecot is apparently requiring a certificate on all connections, which is preventing Roundcube from connecting.
Since dovecot is also providing authentication to postfix I’ve already created an exemption from the client certificate requirement for SMTP connections by doing the following:
protocol !smtp { ssl_ca =
However, I’m not sure how to do the same thing for unencrypted IMAP connections. Is there a way that I can enable client certificate support for only IMAP port 993, leaving port 143 to handle regular unencrypted IMAP with a username and password? I’ve already added the local network to the trusted networks list, so that Roundcube can use plaintext authentication, can I limit client certificate support in a similar way?
Thanks, Haravikk
Le 25 janv. 2016 à 13:02, Haravikk a écrit :
[…]
Since dovecot is also providing authentication to postfix I’ve already created an exemption from the client certificate requirement for SMTP connections by doing the following:
protocol !smtp { ssl_ca =
However, I’m not sure how to do the same thing for unencrypted IMAP connections. Is there a way that I can enable client certificate support for only IMAP port 993, leaving port 143 to handle regular unencrypted IMAP with a username and password? I’ve already added the local network to the trusted networks list, so that Roundcube can use plaintext authentication, can I limit client certificate support in a similar way?
Hello Haravikk,
Perhaps could you try to devise an exception based on one (or more) "remote" section(s), as in:
remote ip.of.webmail.server {
ssl_verify_client_cert = no
[other settings, if needed]
}But I guess you would need to combine this with inner protocol blocks, and probably to replace the "protocol !smtp" block with less general settings.
HTH, Axel
On 27 Jan 2016, at 21:55, Axel Luttgens axel.luttgens@skynet.be wrote:
Hello Haravikk,
Perhaps could you try to devise an exception based on one (or more) "remote" section(s), as in:
remote ip.of.webmail.server { ssl_verify_client_cert = no [other settings, if needed] }
But I guess you would need to combine this with inner protocol blocks, and probably to replace the "protocol !smtp" block with less general settings.
HTH, Axel
Thanks for the suggestion!
Unfortunately the problem seems to be auth_ssl_require_client_cert; it can only be added to protocol blocks not to local or remote ones. Turning off ssl_verify_client_cert doesn’t seem to prevent dovecot from requiring a certificate if auth_ssl_require_client_cert is enabled (it may even force ssl_verify_client_cert to on implicitly, I’m not sure).
It’s annoying because at present it seems like my only option would be to limit client certificates to POP3 and use that in my mail clients, allowing me to disable client certificates for IMAP to keep it free for Roundcube to use exclusively, but that’s not really an option.
So I still haven’t found a way to require client certificates only for port 993/IMAPS while leaving unencrypted IMAP open for local, trusted, services.
Is there really no way to do this? I just found out how to do the same thing for postfix (turns out it’s fairly easy, just a matter of adding the settings in the right parts of master.cf instead of main.cf), allowing me to restrict client certificate verification to port 587 (I don’t accept port 465) without interfering with incoming mail server connections on port 25.
On 29 Jan 2016, at 13:00, Haravikk dovecot@haravikk.me wrote:
On 27 Jan 2016, at 21:55, Axel Luttgens axel.luttgens@skynet.be wrote:
Hello Haravikk,
Perhaps could you try to devise an exception based on one (or more) "remote" section(s), as in:
remote ip.of.webmail.server { ssl_verify_client_cert = no [other settings, if needed] }
But I guess you would need to combine this with inner protocol blocks, and probably to replace the "protocol !smtp" block with less general settings.
HTH, Axel
Thanks for the suggestion!
Unfortunately the problem seems to be auth_ssl_require_client_cert; it can only be added to protocol blocks not to local or remote ones. Turning off ssl_verify_client_cert doesn’t seem to prevent dovecot from requiring a certificate if auth_ssl_require_client_cert is enabled (it may even force ssl_verify_client_cert to on implicitly, I’m not sure).
It’s annoying because at present it seems like my only option would be to limit client certificates to POP3 and use that in my mail clients, allowing me to disable client certificates for IMAP to keep it free for Roundcube to use exclusively, but that’s not really an option.
On 02 Feb 2016, at 13:09, Haravikk dovecot@haravikk.me wrote:
So I still haven’t found a way to require client certificates only for port 993/IMAPS while leaving unencrypted IMAP open for local, trusted, services.
Is there really no way to do this? I just found out how to do the same thing for postfix (turns out it’s fairly easy, just a matter of adding the settings in the right parts of master.cf instead of main.cf), allowing me to restrict client certificate verification to port 587 (I don’t accept port 465) without interfering with incoming mail server connections on port 25.
If you really want to do it, you could do it something like this (not tested - probably needs some additions/changes):
# no 993 port for this imap-login service imap-login { inet_listener imaps { port = 0 } }
# create a duplicate 993 service service imap-login-ssl { executable = imap-login login-ssl chroot = login user = $default_login_user # add other settings similarly as to service imap-login inet_listener imaps { port = 993 } }
# create a separate auth master process for port 993 service auth-ssl { executable = auth -o auth_ssl_require_client_cert=yes # add other settings similarly as to service auth unix_listener login/login-ssl { mode = 0666 } }
On 02 Feb 2016, at 14:19, Timo Sirainen tss@iki.fi wrote:
On 02 Feb 2016, at 13:09, Haravikk dovecot@haravikk.me wrote:
So I still haven’t found a way to require client certificates only for port 993/IMAPS while leaving unencrypted IMAP open for local, trusted, services.
Is there really no way to do this? I just found out how to do the same thing for postfix (turns out it’s fairly easy, just a matter of adding the settings in the right parts of master.cf instead of main.cf), allowing me to restrict client certificate verification to port 587 (I don’t accept port 465) without interfering with incoming mail server connections on port 25.
If you really want to do it, you could do it something like this (not tested - probably needs some additions/changes):
Oh, except now you have two auth master processes, so the final userdb lookup would have to go to the right auth process. This requires the attached patch. After that you can do:
# no 993 port for this imap-login service imap-login { inet_listener imaps { port = 0 } }
# create a duplicate 993 service service imap-login-ssl { executable = imap-login -P imap-ssl login-ssl chroot = login user = $default_login_user # add other settings similarly as to service imap-login inet_listener imaps { port = 993 } }
service imap-ssl { executable = imap -S auth-master-ssl unix_listener login/imap-ssl { user = $default_login_user } }
# create a separate auth master process for port 993 service auth-ssl { executable = auth -o auth_ssl_require_client_cert=yes # add other settings similarly as to service auth unix_listener login/login-ssl { mode = 0666 } unix_listener auth-master-ssl { } }
That definitely seems promising! Though I’m a little uncomfortable about having to apply a patch to make it work.
However it’s got me curious; could I do something similar by defining a second IMAP protocol? Since the protocol !smtp option can enable client certificates for only some protocols, it seems like if I could copy (or symlink) the IMAP protocol into a second IMAPS protocol then I could possibly create the exception using protocol !imap !smtp, could something like that work? Of course I don’t know enough about how dovecot’s protocol modularity works, so I’m not sure what this would involve exactly, but if it could avoid the need for patching it might be a nice way to achieve the same goal.
On 2 Feb 2016, at 12:44, Timo Sirainen tss@iki.fi wrote:
On 02 Feb 2016, at 14:19, Timo Sirainen tss@iki.fi wrote:
On 02 Feb 2016, at 13:09, Haravikk dovecot@haravikk.me wrote:
So I still haven’t found a way to require client certificates only for port 993/IMAPS while leaving unencrypted IMAP open for local, trusted, services.
Is there really no way to do this? I just found out how to do the same thing for postfix (turns out it’s fairly easy, just a matter of adding the settings in the right parts of master.cf instead of main.cf), allowing me to restrict client certificate verification to port 587 (I don’t accept port 465) without interfering with incoming mail server connections on port 25.
If you really want to do it, you could do it something like this (not tested - probably needs some additions/changes):
Oh, except now you have two auth master processes, so the final userdb lookup would have to go to the right auth process. This requires the attached patch. After that you can do:
# no 993 port for this imap-login service imap-login { inet_listener imaps { port = 0 } }
# create a duplicate 993 service service imap-login-ssl { executable = imap-login -P imap-ssl login-ssl chroot = login user = $default_login_user # add other settings similarly as to service imap-login inet_listener imaps { port = 993 } }
service imap-ssl { executable = imap -S auth-master-ssl unix_listener login/imap-ssl { user = $default_login_user } }
# create a separate auth master process for port 993 service auth-ssl { executable = auth -o auth_ssl_require_client_cert=yes # add other settings similarly as to service auth unix_listener login/login-ssl { mode = 0666 } unix_listener auth-master-ssl { } }
On 02 Feb 2016, at 15:15, Haravikk dovecot@haravikk.me wrote:
That definitely seems promising! Though I’m a little uncomfortable about having to apply a patch to make it work.
I'll add those patches to future releases, at least once I verify that they work.
However it’s got me curious; could I do something similar by defining a second IMAP protocol? Since the protocol !smtp option can enable client certificates for only some protocols, it seems like if I could copy (or symlink) the IMAP protocol into a second IMAPS protocol then I could possibly create the exception using protocol !imap !smtp, could something like that work? Of course I don’t know enough about how dovecot’s protocol modularity works, so I’m not sure what this would involve exactly, but if it could avoid the need for patching it might be a nice way to achieve the same goal.
Interesting idea. I guess that could work, except that imap-login binary is hardcoded to send "imap" as the protocol to auth process. In theory you could write a wrapper service between imap-login and auth that changes the imap to imaps, but that's not trivial.. Maybe the protocol name could be made configurable via another command line parameter. It would at least simplify the service changes.
On 2 Feb 2016, at 12:44, Timo Sirainen tss@iki.fi wrote:
On 02 Feb 2016, at 14:19, Timo Sirainen tss@iki.fi wrote:
On 02 Feb 2016, at 13:09, Haravikk dovecot@haravikk.me wrote:
So I still haven’t found a way to require client certificates only for port 993/IMAPS while leaving unencrypted IMAP open for local, trusted, services.
Is there really no way to do this? I just found out how to do the same thing for postfix (turns out it’s fairly easy, just a matter of adding the settings in the right parts of master.cf instead of main.cf), allowing me to restrict client certificate verification to port 587 (I don’t accept port 465) without interfering with incoming mail server connections on port 25.
If you really want to do it, you could do it something like this (not tested - probably needs some additions/changes):
Oh, except now you have two auth master processes, so the final userdb lookup would have to go to the right auth process. This requires the attached patch. After that you can do:
# no 993 port for this imap-login service imap-login { inet_listener imaps { port = 0 } }
# create a duplicate 993 service service imap-login-ssl { executable = imap-login -P imap-ssl login-ssl chroot = login user = $default_login_user # add other settings similarly as to service imap-login inet_listener imaps { port = 993 } }
service imap-ssl { executable = imap -S auth-master-ssl unix_listener login/imap-ssl { user = $default_login_user } }
# create a separate auth master process for port 993 service auth-ssl { executable = auth -o auth_ssl_require_client_cert=yes # add other settings similarly as to service auth unix_listener login/login-ssl { mode = 0666 } unix_listener auth-master-ssl { } }
participants (3)
-
Axel Luttgens
-
Haravikk
-
Timo Sirainen