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