Re: /etc/ssl/certs/dovecot.pem erased by OpenSuse's update mechanism
Why not /etc/dovecot/private? That's where I put my dovecot certs. Dovecot's needs are a bit different from other software, and so it is unclear whether the files won't be unique to it. For example, I haven't seen the following before I read it on the Dovecot wiki:
"The CA file should contain the certificate(s) followed by the matching CRL(s). Note that the CRLs are required to exist. For a multi-level CA place the certificates in this order:
Issuing CA cert
Issuing CA CRL
Intermediate CA cert
Intermediate CA CRL
Root CA cert
Root CA CRL"On 2015/2/16 06:42, Wolfgang Gross wrote:
On 16 Feb 2015 at 21:59, Nick Edwards wrote:
This directory in later times is where more and more distros are putting system wide server CA type certs, most distros are moving to this path, so the package maintainer should fix their script, maybe to /etc/ssl/private or such.
Maybe not in /etc/ssl/private for security reasons? 10-ssl.conf uses the same file name for certificate and private key; better change this, too.
On 2/16/15, Wolfgang Gross WGross@uni-hd.de wrote:
Hi,
this is not a genuine Dovecot bug, more a nuisance. It applies to OpenSuse 13.2 but maybe also to other Linux's.
The standard installation of Dovecot (especially 10-ssl.conf) places the certificate dovecot.pem in /etc/ssl/certs. Sometimes during updates does OpenSuse renew all certificates in /etc/ssl/certs and erases dovecot.pem. This blocks further access to the mailbox.
I found a similar report here: https://bbs.archlinux.de/viewtopic.php?id=27288
Am 16.02.2015 um 15:53 schrieb dovecot@lists.killian.com:
Why not /etc/dovecot/private? That's where I put my dovecot certs. Dovecot's needs are a bit different from other software, and so it is unclear whether the files won't be unique to it. For example, I haven't seen the following before I read it on the Dovecot wiki:
"The CA file should contain the certificate(s) followed by the matching CRL(s). Note that the CRLs are required to exist. For a multi-level CA place the certificates in this order:
Issuing CA cert Issuing CA CRL Intermediate CA cert Intermediate CA CRL Root CA cert Root CA CRL"
that is how you can and should build your PEM files for *every* SSL aware software, Apache and Postfix are happy with exactly that format
i go even so far and include the CDHE and DHE params there which means in case of a recent httpd you can make DHE compatible which most clients even if your RSA certificate is 4096 Bit (read the hint about 2.4.7 or later at http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile if you want to know why)
there is also no need to place that certs below /etc/dovecot at all nor have them readable for anybody but root, we have our wildcard certificate on a unique location synced to all servers offering SSL and again Dovecot, Postfix and Apache are happy to read the PEM root-only PEM files at startup and that's it
On 02/16/2015 04:23 PM, Reindl Harald wrote:
"The CA file should contain the certificate(s) followed by the matching CRL(s). Note that the CRLs are required to exist. For a multi-level CA place the certificates in this order:
Issuing CA cert Issuing CA CRL Intermediate CA cert Intermediate CA CRL Root CA cert Root CA CRL"that is how you can and should build your PEM files for *every* SSL ^^^^^^^ aware software
NACK. I have set up CentOS 6 servers a little more than two years ago with that format used for dovecot and OpenVPN, including verification that the functionality was there. Last month we had a need to revoke a client's certs and it turned out that OpenVPN had silently stopped honoring the CRLs somewhere along the update path (dovecot still enforces them). I had to QuickFix the OpenVPN config from the above monolithic file over to a CApath
https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html#notes
to successfully lock the disgraced client out.
Regards, J. Bern
*NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
participants (3)
-
dovecot＠lists.killian.com
-
Jochen Bern
-
Reindl Harald