289988 - Two UTN root CA certs can't be verified in Firefox 1.0.2

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect, P1)

Description

[Wan-Teh Chang]

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.

Comment 1

[Wan-Teh Chang]

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.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 3

[Wan-Teh Chang]

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.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 5

[Gervase Markham [:gerv]]

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

Comment 6

[Kai Engert (:KaiE:)]

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"?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 8

[Simon Fraser [no longer active]]

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

Comment 9

[Gervase Markham [:gerv]]

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

Comment 10

[Kai Engert (:KaiE:)]

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.

Comment 11

[Simon Fraser [no longer active]]

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

Comment 12

[Ulf Pietruschka]

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
> 

Comment 13

[Chandrasekar Kannan]

target cleanup

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 16

[Kai Engert (:KaiE:)]

reassign bug owner.
mass-update-kaie-20120918

Comment 17

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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.