Re: SSL error after upgrading to 2.31
You forgot to cc the list. ssl_ca is used only for validating client certificates. ---Aki TuomiDovecot oy -------- Original message --------From: Marc Perkel <marc@perkel.com> Date: 21/05/2018 18:25 (GMT+02:00) To: Aki Tuomi <aki.tuomi@dovecot.fi> Subject: Re: SSL error after upgrading to 2.31
On 05/21/2018 07:54 AM, Aki Tuomi
wrote:
Does ssl_cert file contain intermediates?
No - but the ssl_ca does.
---
Aki Tuomi
Dovecot oy
-------- Original message --------
From: Marc Perkel <marc@perkel.com>
Date: 21/05/2018 16:32 (GMT+02:00)
To: dovecot@dovecot.org
Subject: SSL error after upgrading to 2.31
After upgrading to 2.31 I'm getting
this error. Not sure what I'm doing wrong.
No (No signatures could be verified because the chain contains
only one certificate and it is not self signed.)
ssl = yes
ssl_cert = </etc/exim/certs/ctyme.com.crt
ssl_key = </etc/exim/certs/ctyme.com.key
ssl_ca = </etc/exim/certs/ca.crt
local mail.ctyme.com {
protocol imap {
ssl_cert = </etc/exim/certs/ctyme.com.crt
ssl_key = </etc/exim/certs/ctyme.com.key
ssl_ca = </etc/exim/certs/ca.crt
}
protocol pop3 {
ssl_cert = </etc/exim/certs/ctyme.com.crt
ssl_key = </etc/exim/certs/ctyme.com.key
ssl_ca = </etc/exim/certs/ca.crt
}
}
local mail.junkemailfilter.com {
protocol imap {
ssl_cert = </etc/exim/certs/junkemailfilter.com.crt
ssl_key = </etc/exim/certs/junkemailfilter.com.key
ssl_ca = </etc/exim/certs/ca.crt
}
protocol pop3 {
ssl_cert = </etc/exim/certs/junkemailfilter.com.crt
ssl_key = </etc/exim/certs/junkemailfilter.com.key
ssl_ca = </etc/exim/certs/ca.crt
}
}On 05/21/18 17:55, Aki Tuomi wrote:
ssl_ca is used only for validating client certificates.
But it was used (though not documented, IIRC) for validating server certs, too. Since intermediate CA certs are usually valid a lot longer than the server certs, having to concat the certs is awkward, at best.
I would very much like to see the pre-2.3 behaviour of "ssl_ca" restored.
Cheerio, hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 28.05.2018 12:06, Hauke Fath wrote:
On 05/21/18 17:55, Aki Tuomi wrote:
ssl_ca is used only for validating client certificates.
But it was used (though not documented, IIRC) for validating server certs, too. Since intermediate CA certs are usually valid a lot longer than the server certs, having to concat the certs is awkward, at best.
I would very much like to see the pre-2.3 behaviour of "ssl_ca" restored.
Cheerio, hauke
As far as I know, it has never been working as replacement for adding the chain to cert file.
Aki
On 05/28/18 11:08, Aki Tuomi wrote:
On 28.05.2018 12:06, Hauke Fath wrote:
On 05/21/18 17:55, Aki Tuomi wrote:
ssl_ca is used only for validating client certificates.
But it was used (though not documented, IIRC) for validating server certs, too. Since intermediate CA certs are usually valid a lot longer than the server certs, having to concat the certs is awkward, at best.
As far as I know, it has never been working as replacement for adding the chain to cert file.
Well, you know your code better than I. ;)
But it has worked for us here pre-2.3 (see <https://www.dovecot.org/pipermail/dovecot/2018-January/110638.html> ff., and confirmed by <https://www.dovecot.org/pipermail/dovecot/2018-January/110720.html>).
And from an admin POV, it makes a lot of sense to keep the intermediate cert chain separate from the server cert.
Cheerio, hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 28.05.2018 13:05, Hauke Fath wrote:
On 05/28/18 11:08, Aki Tuomi wrote:
On 28.05.2018 12:06, Hauke Fath wrote:
On 05/21/18 17:55, Aki Tuomi wrote:
ssl_ca is used only for validating client certificates.
But it was used (though not documented, IIRC) for validating server certs, too. Since intermediate CA certs are usually valid a lot longer than the server certs, having to concat the certs is awkward, at best.
As far as I know, it has never been working as replacement for adding the chain to cert file.
Well, you know your code better than I. ;)
But it has worked for us here pre-2.3 (see <https://www.dovecot.org/pipermail/dovecot/2018-January/110638.html> ff., and confirmed by <https://www.dovecot.org/pipermail/dovecot/2018-January/110720.html>).
And from an admin POV, it makes a lot of sense to keep the intermediate cert chain separate from the server cert.
Cheerio, hauke
I'm sure. But putting it as ssl_ca makes no sense, since it becomes confused what it is for.
We can try restoring this as ssl_cert_chain setting in future release.
Aki
On Mon, 28 May 2018 13:52:01 +0300, Aki Tuomi wrote:
I'm sure. But putting it as ssl_ca makes no sense, since it becomes confused what it is for.
I guess - I haven't had a need for client certs, and only ever used ssl_ca for the server ca chain.
We can try restoring this as ssl_cert_chain setting in future release.
Sounds good. How about (re)naming them ssl-{client,server}_ca?
Cheerio, Hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 28.05.2018 14:30, Hauke Fath wrote:
On Mon, 28 May 2018 13:52:01 +0300, Aki Tuomi wrote:
I'm sure. But putting it as ssl_ca makes no sense, since it becomes confused what it is for. I guess - I haven't had a need for client certs, and only ever used ssl_ca for the server ca chain.
We can try restoring this as ssl_cert_chain setting in future release. Sounds good. How about (re)naming them ssl-{client,server}_ca?
Cheerio, Hauke
There is already ssl_client_ca, for verifying clients. ssl_ca verifies certs when dovecot is connecting somewhere.
Aki
On Mon, 28 May 2018 15:03:29 +0300, Aki Tuomi wrote:
Sounds good. How about (re)naming them ssl-{client,server}_ca?
There is already ssl_client_ca, for verifying clients. ssl_ca verifies certs when dovecot is connecting somewhere.
So there's three? I had no idea...
Cheerio, hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Aki Tuomi:
There is already ssl_client_ca, for verifying clients. ssl_ca verifies certs when dovecot is connecting somewhere.
For clarification:
there is a third use case an admin may need intermediate certificates:
And that's where dovecot act as server providing imap/pop3/lmtp/sieve
via TLS or STARTTLS
that's different semantic: ssl_client_ca and ssl_ca provide lists of CAs, dovecot should trust while in the third case an administrator has to define exactly one list of intermediate CAs used as chain to a root. Mixing them is wrong.
In the third case an administrator has to provide files with
certificates. And these files
are required (by best practice) to include any chain-certificates
excluding the self signed root.
There is no reason to only provide a certificate via ssl_cert = </path/to/file and an new/other place to provide intermediates.
/path/to/file has to be build from "cat cert intermediate > /path/to/file" No need for other options...
Andreas
On 05/30/18 10:41, A. Schulze wrote:
In the third case an administrator has to provide files with certificates. And these files are required (by best practice)
Do you have any pointers to support such a strong statement?
to include any chain-certificates excluding the self signed root.
Our upstream CA surely does not ship the signed certs that way. It could, and that would support your statement - but it doesn't.
There is no reason to only provide a certificate via ssl_cert = </path/to/file
and an new/other place to provide intermediates.
Yes, there is. It saves manipulating the signed server cert, and mirrors the fact that the intermediate CA certs have a longer lifetime than the server cert.
Cheerio, hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
participants (3)
-
A. Schulze
-
Aki Tuomi
-
Hauke Fath