On 03/21/2013 01:43 AM, Erik C.J. Laan wrote: > I upgraded libnss* from 2:3.13.6-2 (previously in wheezy) to 2:3.14.3-1 (new > in wheezy). > Suddenly Icedove cannot connect to my IMAP-mail server anymore. That > mail-server has > a self-signed certificate. > Thunderbird on other PCs (Win7) does not have the problem. > Mail-clients on other devices do nave the problem. > So it seems related to wheezy specifically. > * What exactly did you do (or not do) that was effective (or > ineffective)? > Restart Icedove. > * What was the outcome of this action? > * What outcome did you expect instead? > Downgraded libnss* to 2:3.13.6-2 to verify that libnss is the culprit. This > solves the issue. > Upgrading to 2:3.14.3-1 again makes the issue appear again. > I also read some bug-reports. One of them talked about cert8.db being the > problem. > So I moved ~/.icedove/<profile>/cert8.db to cert8.db.bak and stopped/started > Icedove to > re-created cert8.db. This does not solve the issue, so the issue is not > related to cert8.db and > thus not to #670882 and/or Mozilla bug 634074 . > > If you need any more information please specify. > > have added a dump of the certificate generated with > openssl s_client -connect imap.intranet:993 -showcerts > for you and attached it to this report. > > To resolve this issue I have to downgrade to 2:3.13.6-2 and am thus stuck > with a vulnerable > version. If using a different (non self-signed) certificate solves the issue, > please specify. > The imap.intranet server certificate is going to expire in a few months > anyway. I can generate > a certificate using a local PKI I've setup for OpenVPN after generating this > certiticate in 2005.
The self-signed certificate in question uses RSA-MD5 as a signature.
MD5 is deprecated in general, so I suspect this is the problem. You
could probably even re-generate the same self-signed certificate with
the same key using SHA1 as the message-signing digest and it would work.
However, this sounds to me like a bug in the logic of the upgraded
version of NSS. If a certificate is already explicitly known locally
and is marked as valid for the remote peer in cert8.db, then NSS should
be fine using it regardless of the digest algorithm used in the
certificate signature.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
