dovecot - Feb 2015 - /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 at
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20150216/fbc85260/attachment.sig>

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