On Wed, Jul 14, 2010 at 10:43:02PM +0200, Frank Lin PIAT wrote: > On Wed, 2010-07-14 at 18:49 +0200, Mike Hommey wrote: > > On Wed, Jul 14, 2010 at 06:17:30PM +0200, Frank Lin PIAT wrote: > > > On Wed, 2010-07-14 at 13:43 +0200, Mike Hommey wrote: > > > > On Wed, Jul 14, 2010 at 01:27:12PM +0200, Frank Lin PIAT wrote: > > > > > > > > > > When I visit https://www.gandi.net, the certificate isn't > > > > > trusted/recognized. > > > > > Error title: "This Connection is Untrusted" > > > > > Error code: sec_error_unknown_issuer > > > > > > > [..] as it works properly here, I suspect something fishy with the > > > > certificate database in your user profile. > > > > > > > > Can you first check if that works better if you try with a new profile > > > > > > The new profile is OK (I should have tested that rather than make wrong > > > assumption). > > > > > > I investigated... In the OK profile, the "AddTrust External CA Root" > > > certificate is selfsigned, whereas the certificates are differents on > > > the KO profile (and they make a loop!): > > > > > > /usr/bin/certutil -L -d /home/fpiat/.mozilla/firefox/*.default/ -a -n > > > "AddTrust External CA Root" | openssl x509 -noout -issuer -subject > > > > issuer= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST > > > > Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC > > > > subject= /C=SE/O=AddTrust AB/OU=AddTrust External TTP > > > > Network/CN=AddTrust External CA Root > > > > > > /usr/bin/certutil -L -d /home/fpiat/.mozilla/firefox/*.default/ -a -n > > > "UTN - DATACorp SGC" | openssl x509 -noout -issuer -subject > > > > issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP > > > > Network/CN=AddTrust External CA Root > > > > subject= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST > > > > Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC > > > > > > I wonder where I got those certificates from, and if others could be > > > affected. > > > > > > <me thinking> > > > If I understand how NSS work properly, it means that NSS is "learning" > > > certificates chains (i.e adding certificates to it's database) as it is > > > receiving certificates from visited websites. > > > > > > This fuzzy / unpredictable behavior scares me. > > > </me thinking> > > > > AFAIK, it doesn't. > > > > The "AddTrust External CA Root" certificate is provided by the "builtin > > object token", so it shouldn't have been broken in the first place. Are > > you sure you never imported a broken certificate? > > I have no clue how that certificate ended up on my laptop. I am > extremely reluctant to add CA certificate to my laptop, I doubt I ever > did that (and when I see the amount of "Software Security Device", I am > pretty sure I didn't import them all myself :-/ ) > > The "AddTrust External CA Root" certificate I removed is the one under > "The USERTRUST Network", which type was "Software Security Device": > CN = AddTrust External CA Root > OU = AddTrust External TTP Network > O = AddTrust AB > C = SE
Basically, anything that is type "Software Security Device" is something that was added to the database. It looks like iceweasel does that for intermediate certificates, like, I believe, most if not all browsers. Now, there are 3 questions that should be answered: - where does your additional (broken) AddTrust External CA Root cert come from? - why is broken? - why does iceweasel/nss doesn't allows such broken situations, especially when there is another AddTrust External CA Root cert? The first is primordial, I think, because it would help understand how you got this certificate in the first place. The second might be related to the UTN - DATACorp SGC cert. In the builtin token, it is issued by AddTrust External CA Root, which introduces the loop. But there are chances that the UTN - DATACorp SGC key it was actually issued from had a different certificate associated with it by the time, not issued by AddTrust External CA Root. For the latter, I don't know what to think. It's apparently not going to be a security issue. Only a nuisance in that certificates issued by the half broken CA will be shown as invalid. I'll think a bit more about it and probably file a bug upstream. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
