Closed
Bug 444404
Opened 16 years ago
Closed 15 years ago
libpkix reports "unknown issuer" for nearly all certificate errors
Categories
(NSS :: Libraries, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
3.12.3
People
(Reporter: nelson, Assigned: alvolkov.bgs)
References
Details
(Whiteboard: PKIX SUN_MUST_HAVE)
Attachments
(2 files, 1 obsolete file)
5.25 KB,
patch
|
nelson
:
review+
|
Details | Diff | Splinter Review |
3.61 KB,
patch
|
nelson
:
review+
|
Details | Diff | Splinter Review |
For most errors in certificates, libPKIX reports the error code that means "unknown issuer" (a.k.a. "unrecognized issuer", "issuer not found"). This is very unhelpful, and we must fix it for 3.12.1, if possible. NSS's old cert library reports error codes that are generally quite diagnostic, helpful to people to figure out what's wrong with their certs. That's an absolute requirement for NSS. NSS must continue to provide error codes that tell the user what aspect of the cert chain to examine to find the problem that needs correction. This bug blocks our ability to generally replace the old code in applications that use the old cert path validation API (CERT_VerifyCert*), especially in Firefox, but also in other server applications. If those products would switch to using libPKIX while the problem remains, the NSS team would be overwhelmed with complaints, requesting help in finding problems in cert chains, because the real problems would no longer be apparent from the error codes. libPKIX's algorithm may be described as having an outer loop that is roughly: while (another cert path can be constructed) test the new cert path After every failure in the cert path test, it goes back and tries to construct another path. So, the last failure it experiences before returning is nearly always a failure to find another issuer certificate. This masks the potentially useful error code from the last path test by replacing it with the "issuer not found" error. Somehow we must make libPKIX return the most relevant error code possible. There are several ways we could use to attempt to do that. Here are some: 1. Rank the error codes from most important to least important, and have the rule that when going to set an error code, if the error code that is already set is more important than the new one, just leave it set as is, and don't set the new error code. The "unknown issuer" error would be last, or nearly last, in that ranking. 2. Change the code that attempts to set the "unknown issuer" error code, so that it checks for the existence of another error code, and only sets the "unknown issuer" error code if no other error code has already been set. This essentially changes the behavior of that single error code, and no others. The above two ideas assume that error codes are set as (in the order) they are experienced. However, IINM, libPKIX builds a tree of information about paths tested and errors experienced. Perhaps an algorithm is needed that searches that tree and decides what error is the most relevant from among the errors in the tree.
Reporter | ||
Comment 1•16 years ago
|
||
I think this must be P1 for 3.12.1
Priority: -- → P1
Whiteboard: PKIX
Assignee | ||
Comment 2•16 years ago
|
||
Need real chains(or ssl enabled servers) to make sure the fix works. Nelson, Christophe, please update the bug with chains that bogusly report "issue not found" error.
Assignee | ||
Comment 3•16 years ago
|
||
Tries to get info from verify node if error is not identified. But it actually does not improve error handling: if validation error was received it will be saved in finalError variable and in verify node tree as well. Does not make sense to search for errors in the verify node tree, unless we are looking for a highest priority error.
Assignee | ||
Comment 4•16 years ago
|
||
patch tries to recover an error, that occurred earlier and was logged in to the verify node tree. The error search will be done only if final error(the pointer to error that happen during last stage of chain build) still has NULL value.
Attachment #331217 -
Attachment is obsolete: true
Attachment #331646 -
Flags: review?(nelson)
Reporter | ||
Comment 5•16 years ago
|
||
Comment on attachment 331646 [details] [diff] [review] Patch v1 - find occurred error (checked in) This is probably a good first step in the right direction.
Attachment #331646 -
Attachment description: Patch v1 - find occured error → Patch v1 - find occurred error
Attachment #331646 -
Flags: review?(nelson) → review+
Assignee | ||
Comment 6•16 years ago
|
||
(In reply to comment #5) > (From update of attachment 331646 [details] [diff] [review]) commited
Assignee | ||
Updated•16 years ago
|
Target Milestone: 3.12.1 → 3.12.2
Assignee | ||
Updated•16 years ago
|
Whiteboard: PKIX → PKIX SUN_MUST_HAVE
Reporter | ||
Updated•16 years ago
|
Attachment #331646 -
Attachment description: Patch v1 - find occurred error → Patch v1 - find occurred error (checked in)
Reporter | ||
Updated•15 years ago
|
Target Milestone: 3.12.2 → 3.12.3
Assignee | ||
Comment 7•15 years ago
|
||
Returned log is empty for errors that occurred due to untrusted or unknown issuer. This patch fixes it by setting proper code into verify node.
Attachment #363348 -
Flags: review?(nelson)
Reporter | ||
Comment 8•15 years ago
|
||
Comment on attachment 363348 [details] [diff] [review] patch to pkix_build.c - update log with reported error(integrated) r=nelson
Attachment #363348 -
Flags: review?(nelson) → review+
Assignee | ||
Updated•15 years ago
|
Attachment #363348 -
Attachment description: patch to pkix_build.c - update log with reported error → patch to pkix_build.c - update log with reported error(integrated)
Reporter | ||
Comment 9•15 years ago
|
||
What is the status of this bug? Is it resolved?
Assignee | ||
Comment 10•15 years ago
|
||
I don't think we need to do anything else at this point. Closing the bug.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•