On 03/21/2013 07:46 PM, Erik C.J. Laan wrote:
On 03/21/13 15:28, Daniel Kahn Gillmor wrote:
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
Thanks for the suggestion. I will generate a new certificate and avoid
md5.
I will report back today or tomorrow whether that solved the issue.
-- Met vriendelijke groeten/With kind regards, Erik Laan.
I have just generated a new certificate (not self-signed). This
certificate uses sha1. I did not manage to load the CA certificate into
Icedove, so I did accept the server's certificate into cert8.db just as
before ("Permanently store security exception").
After that stopped/started courier-imapd, upgraded libnss3 on the client
and now Icedove does connect. So the issue seems indeed to have been md5
vs sha1.
--
Met vriendelijke groeten/With kind regards, Erik Laan.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
