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