I just installed Firefox 1.0.2 on Windows. Firefox 1.0.2 uses NSS 3.9.3 + nssckbi 1.42. I found that two UTN root CA certs that Nelson added in bug 271585 cannot be verified. Since that bug is very long, I decided to open a new bug rather than reopening that bug. UTN-USERFirst-Client Authentication and Email: Could not verify this certificate because the issuer is not trusted. UTN-USERFirst-Object: Could not verify this certificate for unknown reasons.

Changed product to Core:Security: PSM. Bob Relyea explained to me why this is a PSM bug. The trust flags specified in NSS's certdata.txt file can be examined by clicking on the "Edit" button (as opposed to the "View" button) in PSM's Certificate Manager.

Is this a bug? Perhaps an RFE? What alternative behavior is requested here? IIRC, PSM's cert viewer reports whether the cert is valid for just one usage, and IIRC that usage is email. I believe that is by design. Perhaps it could be enhanced to report whether the cert is valid for any of NSS's supported uses, or to report validity for each of the 3 uses separately.

See bug 289475 for another person who's also confused by this UI. The desired behavior is that PSM's View button needs to be context sensitive. When I browse the builtin root CA list and want to view a cert on the list, I expect to see the trust settings. It is not obvious that I need to click on the Edit button to see the trust settings.

*** Bug 289475 has been marked as a duplicate of this bug. ***

*** Bug 293154 has been marked as a duplicate of this bug. ***

If I understand correctly, there are two problems here. 1.) When clicking "view", the information shown gives summarized information. The summary is strange for those certificates, that are not trusted as web site CAs, but are email/object CAs. For both it says, the CA certificate can not be verified. If we want to fix this, without changing the whole UI, we should provide more intelligent output for those special CAs. 2) You say it's not obvious where to view the trust settings. Would it make it obvious if we simply change the "edit" button text to "edit trust"?

Kai, I suggest changing the button to read View/Edit or "View/Edit Trust". I think people who just want to view something are reluctant to click a button that says Edit, unless it also gives them a clue that this is also how one views the material.

(In reply to comment #6) > If I understand correctly, there are two problems here. > > 1.) When clicking "view", the information shown gives summarized information. > The summary is strange for those certificates, that are not trusted as web site > CAs, but are email/object CAs. For both it says, the CA certificate can not be > verified. If this is the same issue as bug 307144, then it's not just the UI that has to change; nsIX509Cert::GetUsagesArray() will also have to be fixed to return a different verified status.

*** Bug 275043 has been marked as a duplicate of this bug. ***

Regarding comment 6 2) there is now bug 315880 that requests an enhancement, allow editing trust settings from within (or be reachable from) cert viewer.

Here are the certs that we ship with Camino/FF/etc that are bad out of the box: Sonera Class1 CA -- issuer not trusted UTN-USERFirst-Object -- cannot be verified (this bug!) UTN-USERFirst-Client Authentication and Email -- issuer not trusted Class 3 Public Primary OCSP Responder -- expired Class 1 Public Primary OCSP Responder -- expired Class 2 Public Primary OCSP Responder -- expired Secure Server OCSP Responder -- expired

UTN-USERFirst-Object also describes the issuer as not trusted (see bug# 300071), which is the more problematic behaviour than the UI problem, since using this certificate for object signing has not the desired effect. (In reply to comment #11) > Here are the certs that we ship with Camino/FF/etc that are bad out of the box: > > Sonera Class1 CA -- issuer not trusted > UTN-USERFirst-Object -- cannot be verified (this bug!) > UTN-USERFirst-Client Authentication and Email -- issuer not trusted > Class 3 Public Primary OCSP Responder -- expired > Class 1 Public Primary OCSP Responder -- expired > Class 2 Public Primary OCSP Responder -- expired > Secure Server OCSP Responder -- expired >

target cleanup

As far as I am concerned, the fact that PSM says "Could not verify this certificate because the issuer is not trusted" rather than listed the purposes for which the cert *is* trusted, is a P1 bug in PSM and has been since this bug was opened. The last time I worked on adding root CA certs to NSS, a LOT of users (and at least a few mozilla developers) accused me of incompetence because of this. I had added a root cert that was NOT trusted for SSL use, and PSM said it was not trusted. PSM should have said "was not trusted for issuing SSL server certs" and "is trusted for email certs". Anyway, I refuse to be insulted over PSM's lousy error messages again. Julien developed CERT_VerifyCertificate (the one call that returns information about ALL the usages for which a cert might be trusted) specifically for this case, IIRC, and I think it is still unused by PSM for that. Until PSM fixes this, I don't work on root CA certs.

reassign bug owner. mass-update-kaie-20120918

If I'm understanding the original issue (that a root certificate trusted not to issue web site certificate but to issue email certificates would have a "could not verify this certificate" string in the certificate viewer), this appears to have been fixed.