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

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Mar 22 06:59:04 UTC 2013


On Thu 2013-03-21 10:28:31 -0400, Daniel Kahn Gillmor wrote:

> 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.

I've looked into this a bit further to try to understand what NSS is
doing.  I think icedove and modern versions of NSS will do the right
thing even with self-signed RSA+MD5 certs as long as the certificate is
loaded in the right section of the certificate manager (i.e. in
"Servers" and not in "Authorities").



I tried using OpenSSL to generate a self-signed key + cert that looks
like the example given by Erik, and running a simple web server with it
on port 2443:

echo test > test.txt
openssl req -x509 -nodes -subj '/CN=localhost/' -newkey rsa:4096 -md5 -keyout key.pem -out cert.pem
openssl s_server -accept 2443 -cert cert.pem -key key.pem -WWW


Then, as a separate client, i created two NSS certdb's and tried adding
the certificate to each of them.  In one NSS certdb, i added the
localhost certificate as a trusted CA; in the other, as a "trusted
peer":

mkdir clientC clientP
certutil -A -d clientC -n localhost -t C,, < cert.pem
certutil -A -d clientP -n localhost -t P,, < cert.pem

connecting with the cert marked as a "trusted peer" worked.  Connecting
with it as a "trusted CA" gives a failure authenticating the cert:

0 dkg at alice:~$ printf "GET /test.txt HTTP/1.1\r\nHost: localhost\r\n\r\n" | tstclnt -d clientC -h 127.0.0.1 -a localhost -p 2443  
tstclnt: authentication of server cert failed: Success
254 dkg at alice:~$ printf "GET /test.txt HTTP/1.1\r\nHost: localhost\r\n\r\n" | tstclnt -d clientP -h 127.0.0.1 -a localhost -p 2443  
subject DN: CN=localhost
issuer  DN: CN=localhost
0 cache hits; 1 cache misses, 0 cache not reusable
0 stateless resumes
HTTP/1.0 200 ok
Content-type: text/plain

test

(i have to hit Ctrl-C to terminate this for some reason, but i don't
think that's relevant to this bug report).


If i repeat the same tests using -sha1 instead of -md5 on the "openssl
req" command (and destroying and recreating the certdbs), then clientC
behaves the same way as clientP.

Maybe this is a relevant and acceptable distinction, but i'm not sure.

I note that with icedove, if i import cert.pem in the "Servers" tab of
the certificate management dialog box, and "Edit Trust..." to say that i
believe in the cert, certutil reflects it as trust P,p,p, and icedove
will connect to it.  But if i import it into the "Authorities" tab and
mark it as able to sign web sites, then certutil reflects it as CT,c,c,
and it does not work as a self-signed cert.

So i think the argument here is that icedove is doing the Right Thing,
even if it's a little bit silly.  If a user wants to treat a certificate
as a known peer, it should be in the "Servers" tab, not the
"Authorities" tab.  in fact, importing it into "Authorities" is a bad
idea, since that would mean that it could make other (non-md5)
certificates and the client would accept them.


As another sidenote, if i try to access this server with firefox, i
don't think certutil is willing or able to report the results of the
"Add permanent security exception" operation.  When i take the latter
action from a browser running as "iceweasel --no-remote -P testrun" and
then use "certutil -L -d ~/.mozilla/firefox/*.testrun" I get:

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
localhost                                                    ,,   

and even though iceweasel will connect without a warning, "tstclnt -d
~/.mozilla/firefox/*.testrun -h 127.0.0.1 -a localhost" fails with
"authentication of server cert failed: Success" -- this suggests that
iceweasel is storing these "permanent exceptions" somewhere outside of
the certdb, but i haven't dug up where or how yet.  If the information
is accessible, it would be nice to have it displayable by NSS's certutil
if possible.

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/attachments/20130322/5e920442/attachment.pgp>


More information about the pkg-mozilla-maintainers mailing list