Dovecot proxy ignores trusted root certificate store
Dovecot v2.2.18 OS: FreeBSD 10.1/amd64
Dovecot in proxy mode ignores the root certificate store and can't verify the backend's SSL certificate.
I've pointed ssl_client_ca_file to my root certificate store, but I suspect ssl_client_ca_file is only used in imapc context. It seems to be ignored in proxy context.
doveconf -n ssl_client_ca_file: ssl_client_ca_file = /usr/local/share/certs/ca-root-nss.crt
In my password_query I return host set to the backend's IP address, starttls='yes', proxy='y'.
The backend's certificate chain is correct and it verifies successfully with "openssl s_client -connect x.x.x.x:110 -starttls pop3 -CAfile /usr/local/share/certs/ca-root-nss.crt".
But the Dovecot proxy fails to verify the intermediate certificate it receives from the backend. The inode atime of ca-root-nss.crt is never updated, either at Dovecot start or when it connects to the backend, so Dovecot (via the openssl library) never reads the file.
Sep 20 19:59:48 dovecot: pop3-login: Invalid certificate: unable to get local issuer certificate: /C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G4 Sep 20 19:59:48 dovecot: pop3-login: Invalid certificate: certificate not trusted: /C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G4 Sep 20 19:59:48 dovecot: pop3-login: Error: proxy: Received invalid SSL certificate from x.x.x.x:110: unable to get local issuer certificate: /C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G4: user=<xxx>, method=PLAIN, rip=x.x.x.x, lip=x.x.x.x, session=<lz9YjzYgIADYyWAp>
On Monday 21 September 2015 01:53:53 Alex Bulan wrote:
Dovecot v2.2.18 OS: FreeBSD 10.1/amd64
Dovecot in proxy mode ignores the root certificate store and can't verify the backend's SSL certificate.
I've pointed ssl_client_ca_file to my root certificate store, but I suspect ssl_client_ca_file is only used in imapc context. It seems to be ignored in proxy context.
doveconf -n ssl_client_ca_file: ssl_client_ca_file = /usr/local/share/certs/ca-root-nss.crt
I think the correct syntax is :
ssl_ca = < /etc/ssl/certs/cacert.pem For all kind of ssl_xyz files
Mihai Badici[1]
Hi
I've pointed ssl_client_ca_file to my root certificate store, but I suspect ssl_client_ca_file is only used in imapc context. It seems to be ignored in proxy context.
doveconf -n ssl_client_ca_file: ssl_client_ca_file = /usr/local/share/certs/ca-root-nss.crt
You are missing the "<" before the file path
Try ssl_client_ca_file =
See http://wiki2.dovecot.org/SSL/DovecotConfiguration
Regards Christian
The result is the same with or without "<" before the file path. With "<" the inode atime is updated at Dovecot startup, so the file is at least opened, but Dovecot still can't verify the cert.
The only place in the Wiki that shows an example of ssl_client_ca_file is on this page, and there's no "<" in front of the file path:
http://wiki2.dovecot.org/Replication
(quote) The client must be able to verify that the SSL certificate is valid, so you need to specify the directory containing valid SSL CA roots:
ssl_client_ca_dir = /etc/ssl/certs # Debian/Ubuntu ssl_client_ca_file = /etc/pki/tls/cert.pem # RedHat (end quote)
On Mon, 21 Sep 2015, Christian Kivalo wrote:
Hi
I've pointed ssl_client_ca_file to my root certificate store, but I suspect ssl_client_ca_file is only used in imapc context. It seems to be ignored in proxy context.
doveconf -n ssl_client_ca_file: ssl_client_ca_file = /usr/local/share/certs/ca-root-nss.crt
You are missing the "<" before the file path
Try ssl_client_ca_file =
See http://wiki2.dovecot.org/SSL/DovecotConfiguration
Regards Christian
On 2015-09-21 09:28, Alex Bulan wrote:
The result is the same with or without "<" before the file path. With "<" the inode atime is updated at Dovecot startup, so the file is at least opened, but Dovecot still can't verify the cert.
The only place in the Wiki that shows an example of ssl_client_ca_file is on this page, and there's no "<" in front of the file path:
http://wiki2.dovecot.org/Replication
(quote) The client must be able to verify that the SSL certificate is valid, so you need to specify the directory containing valid SSL CA roots:
ssl_client_ca_dir = /etc/ssl/certs # Debian/Ubuntu ssl_client_ca_file = /etc/pki/tls/cert.pem # RedHat (end quote)
For replication only settings? I can only guess as i currently don't use proxy nor replication.
Haven't found much about proxying and ssl but found a configuration parameter ssl_ca =
http://wiki2.dovecot.org/SSL/DovecotConfiguration section Client certificate verification/authentication
On Mon, 21 Sep 2015, Christian Kivalo wrote:
Hi
I've pointed ssl_client_ca_file to my root certificate store, but I suspect ssl_client_ca_file is only used in imapc context. It seems to be ignored in proxy context.
doveconf -n ssl_client_ca_file: ssl_client_ca_file = /usr/local/share/certs/ca-root-nss.crt
You are missing the "<" before the file path
Try ssl_client_ca_file =
See http://wiki2.dovecot.org/SSL/DovecotConfiguration
Regards Christian
- Christian
On Mon, 21 Sep 2015, Christian Kivalo wrote:
Haven't found much about proxying and ssl but found a configuration parameter ssl_ca =
http://wiki2.dovecot.org/SSL/DovecotConfiguration section Client certificate verification/authentication
ssl_ca serves a different purpose, it's for setting your certificate authority in order to verify client certs you've issued.
Setting "ssl_ca =
The correct setting to use is ssl_client_ca_file. It's just not being applied in proxy mode.
The patchset that implemented ssl_client_ca_file is here:
http://www.dovecot.org/list/dovecot-cvs/2013-April/023089.html
Dovecot calls the OpenSSL function SSL_CTX_load_verify_locations() to set the CAfile path, as it should, but apparently only when it's talking to an imapc storage backend, not when it's acting as a simple proxy.
See http://dovecot.org/pipermail/dovecot/2013-June/090884.html
On 21/09/15 17:28, Alex Bulan wrote:
The result is the same with or without "<" before the file path. With "<" the inode atime is updated at Dovecot startup, so the file is at least opened, but Dovecot still can't verify the cert.
The only place in the Wiki that shows an example of ssl_client_ca_file is on this page, and there's no "<" in front of the file path:
http://wiki2.dovecot.org/Replication
(quote) The client must be able to verify that the SSL certificate is valid, so you need to specify the directory containing valid SSL CA roots:
ssl_client_ca_dir = /etc/ssl/certs # Debian/Ubuntu ssl_client_ca_file = /etc/pki/tls/cert.pem # RedHat (end quote)
Suggesting that on Redhat you should specify "the directory containing valid SSL CA roots" by setting ssl_client_ca_file sounds kinda crazy. Sounds like setting a file instead. So that bit of documentation should be treated as rather suspect.
Regards, Andrew
On Mon, 21 Sep 2015, Andrew McN wrote:
http://wiki2.dovecot.org/Replication
(quote) The client must be able to verify that the SSL certificate is valid, so you need to specify the directory containing valid SSL CA roots:
ssl_client_ca_dir = /etc/ssl/certs # Debian/Ubuntu ssl_client_ca_file = /etc/pki/tls/cert.pem # RedHat (end quote)
Suggesting that on Redhat you should specify "the directory containing valid SSL CA roots" by setting ssl_client_ca_file sounds kinda crazy. Sounds like setting a file instead. So that bit of documentation should be treated as rather suspect.
Regards, Andrew
In some environments, root certs are stored in a hashed directory, in other environments they're stored in one file. One would typically use one setting or the other.
I think ssl_client_ca_file was implemented later than ssl_client_ca_dir. The comment just needs to be updated.
doveconf -n?
On 09/21/2015 12:45 PM, Alex Bulan wrote:
On Mon, 21 Sep 2015, Andrew McN wrote:
http://wiki2.dovecot.org/Replication
(quote) The client must be able to verify that the SSL certificate is valid, so you need to specify the directory containing valid SSL CA roots:
ssl_client_ca_dir = /etc/ssl/certs # Debian/Ubuntu ssl_client_ca_file = /etc/pki/tls/cert.pem # RedHat (end quote)
Suggesting that on Redhat you should specify "the directory containing valid SSL CA roots" by setting ssl_client_ca_file sounds kinda crazy. Sounds like setting a file instead. So that bit of documentation should be treated as rather suspect.
Regards, Andrew
In some environments, root certs are stored in a hashed directory, in other environments they're stored in one file. One would typically use one setting or the other.
I think ssl_client_ca_file was implemented later than ssl_client_ca_dir. The comment just needs to be updated.
On Mon, 21 Sep 2015, Edgar Pettijohn wrote:
doveconf -n?
doveconf -n|grep ssl should suffice:
ssl = required ssl_ca =
I'm using "ssl_ca =
ssl_client_ca_file should be used instead, but it has no effect in proxy mode:
ssl_client_ca_file = /usr/local/share/certs/ca-root-nss.crt
This doesn't work either (and the Dovecot Wiki shows it used without "<"):
ssl_client_ca_file =
And "ssl_require_crl = no" to silence "unable to get certificate CRL" log messages. I don't need it to check CRLs on the backend's certificate chain.
On 09/21/2015 05:11 PM, Alex Bulan wrote:
On Mon, 21 Sep 2015, Edgar Pettijohn wrote:
doveconf -n?
doveconf -n|grep ssl should suffice:
ssl = required
shouldn't it be:
ssl = yes
I was only aware of the choice of yes or no here, but I could be wrong.
ssl_ca =
I'm using "ssl_ca =
ssl_client_ca_file should be used instead, but it has no effect in proxy mode:
ssl_client_ca_file = /usr/local/share/certs/ca-root-nss.crt
This doesn't work either (and the Dovecot Wiki shows it used without "<"):
ssl_client_ca_file =
And "ssl_require_crl = no" to silence "unable to get certificate CRL" log messages. I don't need it to check CRLs on the backend's certificate chain.
On Mon, 21 Sep 2015, Edgar Pettijohn wrote:
ssl = required
shouldn't it be:
ssl = yes
I was only aware of the choice of yes or no here, but I could be wrong.
On 22 Sep 2015, at 01:11, Alex Bulan avb@korax.net wrote:
On Mon, 21 Sep 2015, Edgar Pettijohn wrote:
doveconf -n?
doveconf -n|grep ssl should suffice:
ssl = required ssl_ca =
I'm using "ssl_ca =
ssl_client_ca_file should be used instead, but it has no effect in proxy mode:
Yeah. The ssl_client_ca_file was implemented later than the SSL proxying code. I think this may be something that needs to wait for v2.3 to get fixed. v2.3 hopefully removes the duplicated ssl code and uses lib-ssl-iostream for proxying also, which makes this easier to implement.
On Tue, 22 Sep 2015, Timo Sirainen wrote:
Yeah. The ssl_client_ca_file was implemented later than the SSL proxying code. I think this may be something that needs to wait for v2.3 to get fixed. v2.3 hopefully removes the duplicated ssl code and uses lib-ssl-iostream for proxying also, which makes this easier to implement.
Thanks, Timo. I'll use the ssl_ca workaround for now.
participants (6)
-
Alex Bulan
-
Andrew McN
-
Christian Kivalo
-
Edgar Pettijohn
-
Mihai Badici
-
Timo Sirainen