Bug#703587: libnss3 update disables some (self signed) certs (with Icedove)

[Erik C.J. Laan]

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.