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@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@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
pgp3OWGrydck7.pgp
Description: PGP signature