dovecot as proxy and verification of the backends certificate
Hello,
I'm using a dovecot as proxy, connecting to one or more backends. The backends use X.509 certificates.
The proxy's passdb returns
extra fields:
user=foo
proxy
host=backend1.<domain>
ssl=yes
nopassword=yThus the proxy connects to the backend but can't verify the backends certificate.
The following comment suggests using ssl_client_ca_file for that.
# Directory and/or file for trusted SSL CA certificates. These are used only
# when Dovecot needs to act as an SSL client (e.g. imapc backend). The
# directory is usually /etc/ssl/certs in Debian-based systems and the file is
# /etc/pki/tls/cert.pem in RedHat-based systems.
#ssl_client_ca_dir =
#ssl_client_ca_file =
ssl_client_ca_file = /tmp/certs/ca-local.pemBut that does not work! Instead I've to use ssl_ca
# PEM encoded trusted certificate authority. Set this only if you intend to use
# ssl_verify_client_cert=yes. The file should contain the CA certificate(s)
# followed by the matching CRL(s). (e.g. ssl_ca = </etc/ssl/certs/ca.pem)
# ssl_ca =
ssl_ca = </tmp/certs/ca-local.pemBug or feature? Mainly I'm asking because the comments do not indicate that I should have used ssl_ca for this type of operation (dovecot as a SSL client)
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
On 11 Oct 2015, at 20:04, Heiko Schlittermann <hs@schlittermann.de> wrote:
Hello,
I'm using a dovecot as proxy, connecting to one or more backends. The backends use X.509 certificates.
The proxy's passdb returns
extra fields: user=foo proxy host=backend1.<domain> ssl=yes nopassword=y
Thus the proxy connects to the backend but can't verify the backends certificate.
The following comment suggests using ssl_client_ca_file for that.
# Directory and/or file for trusted SSL CA certificates. These are used only # when Dovecot needs to act as an SSL client (e.g. imapc backend). The # directory is usually /etc/ssl/certs in Debian-based systems and the file is # /etc/pki/tls/cert.pem in RedHat-based systems. #ssl_client_ca_dir = #ssl_client_ca_file = ssl_client_ca_file = /tmp/certs/ca-local.pem
But that does not work! Instead I've to use ssl_ca
# PEM encoded trusted certificate authority. Set this only if you intend to use # ssl_verify_client_cert=yes. The file should contain the CA certificate(s) # followed by the matching CRL(s). (e.g. ssl_ca = </etc/ssl/certs/ca.pem) # ssl_ca = ssl_ca = </tmp/certs/ca-local.pem
Bug or feature? Mainly I'm asking because the comments do not indicate that I should have used ssl_ca for this type of operation (dovecot as a SSL client)
It's a missing feature. I updated http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy about this. I'm thinking that once login-common code uses lib-ssl-iostream instead of the duplicated SSL code this gets fixed more or less automatically. Note sure if that'll happen for v2.3 or not.
Timo Sirainen <tss@iki.fi> (Di 13 Okt 2015 20:27:25 CEST): …
# followed by the matching CRL(s). (e.g. ssl_ca = </etc/ssl/certs/ca.pem) # ssl_ca = ssl_ca = </tmp/certs/ca-local.pem
Bug or feature? Mainly I'm asking because the comments do not indicate that I should have used ssl_ca for this type of operation (dovecot as a SSL client)
It's a missing feature. I updated http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy about this. I'm thinking that once login-common code uses lib-ssl-iostream instead of the duplicated SSL code this gets fixed more or less automatically. Note sure if that'll happen for v2.3 or not.
Thank you.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
participants (2)
-
Heiko Schlittermann
-
Timo Sirainen