91403 - (unknownreason) expand the list of error codes for which the cert viewer gives a specific error description

Status: RESOLVED INVALID

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

Description

[thomask]

If the validation is not setup correctly, PSM will say
"Could not verify this certificate for unknown reasons".

This kind of message is not helpful enough. Can the
message be more specific on the problems. For example,

Could not verify this certificate because the OCSP responder cannot be reached

For advanced users, we may want to support a configuration parameter like
psm.debug.file=c:/temp/debug.log in prefs.js so that additional information
can be provided to users.

Comment 1

[John Unruh]

What build are you using? I have not seen "Could not verify this certificate for 
unknown reasons" since PSM 2.0 was added to the N6 builds on 4/10.

Comment 2

[thomask]

Using NS61PR1

Comment 3

[John Unruh]

Can you try it with the latest build, and also give the steps you went through 
to arrive at that error message?
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2001-07-19-05-0.9.2/

Comment 4

[Stephane Saux]

I agree this is confusing.  I'm trying to replicate this bug.  I decided to go
to pref->...-> validation and set the ocsp responder to some non-existent URL
for Thawte Server CA. I then pointed my browser to a site whose cert is signed
by Thawte Server CA, and I expected some kind of failure, but to no avail.
Thomas if you can elaborate on this that would be helpful.

setting to:
t->2.1 OCSP is an important feature for nsenterprise.
->ddrinan

Comment 5

[thomask]

Basically, saying "unknown reason" is not good enough. We need to
provide better tracing and debugging capability in PSM in general.

Please really consider this:

"For advanced users, we may want to support a configuration parameter like
psm.debug.file=c:/temp/debug.log in prefs.js so that additional information
can be provided to users."

Comment 6

[Stephane Saux]

->javi

Comment 7

[John Unruh]

Mass assigning QA to ckritzer.

Comment 8

[Stephane Saux]

future

Comment 9

[John Unruh]

OS > all

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Mass reassign Javi's old PSM bugs to nobody

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

5 year old PSM bug, still as much a problem as ever.
Adding bug reporter's new email address to cc list.

Comment 12

[Chandrasekar Kannan]

marking target mozilla 1.8.1. we will have a bug review t'row to see if we can address this.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Marking this P1, because bug 183371 is a duplicate of this, and it is P1.
Assigning to Kai for the same reason.

Comment 16

[Kai Engert [:KaiE:]]

I think this is no longer applicable.

If you know a code path that results in this general error message being shown, please provide steps-to-reproduce.

Hmmm. 

Here is a list of PSM-level verification failure classes:
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/public/nsIX509Cert.idl#177

Here is code that maps NSS-level error codes to the PSM-level error classes:
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSCertificate.cpp#1331

(with a duplicate source location at http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsUsageArrayHelper.cpp#123 )

And here is the code that maps the PSM-level verification error classes to UI strings used by cert viewer:
http://mxr.mozilla.org/mozilla-central/source/security/manager/pki/resources/content/viewCertDetails.js?mark=252-252#213

The strings are defined here:
http://mxr.mozilla.org/mozilla-central/source/security/manager/locales/en-US/chrome/pippki/pippki.properties#86

Comment 17

[Kai Engert [:KaiE:]]

In order to display less errors as "unknown reason", the mapping code that maps NSS-level codes to PSM-level classes should be enhanced to include additional NSS error codes; either adding them to existing PSM-level classes, or even introducing additional PSM-level classes with their own wording.

Maybe this mapping from NSS-codes to PSM-classes should be considered obsolete?

In the previous 1-2 years we made all the NSS error code strings available to PSM, so maybe PSM should stop using a transformation, and display the direct NSS error code string?

Comment 18

[Craig Arno]

I receive the subject error using certificates generated by my OpenSUSE 10.3 server CA Manager and used under Windows Thunderbird 2.0.0.21, Linux Thunderbird x64 2.0.0.19.

The user certificate (P12 with authority chain included) generated work fine for Microsoft Outlook 2003 and 2007 email digital signing and encryption.

With Thunderbird and Firefox I tried importing "Your Certificates" (.P12) and separately "Authorities" certificates (.DER).  I also carefully read "Guide to using S/MIME" and bugs 101616, 100386 (which I didn't understand). http://www.mozilla.org/projects/security/pki/psm/smime_guide.html

For home and small business use I'm making an effort to use Firefox, Thunderbird, Sunbird, Open-Xchange, Linux, and a licensed Windows machine.  One job required encryption security for all communication, so I'd really like this to work under Thunderbird, interchangeably with Outlook, and so far, no luck with Thunderbird clients for encrypted email and digital signing.  For SSL/TLS communication with my UW-IMAP SSL/TLS server, these same certificates work fine on my server/clients. i.e. no "certificate mismatch" messages.

With everything I've tried, I think it is fair to say Digital signing and certificate private/public key encryption isn't there yet.  So I won't be able to use these tools for contracts requiring security.  When someone thinks they have this fixed, I'll be happy to test under Windows Thunderbird (I'm a little more nervous fiddling with the Linux x64 Thunderbird installation where many Add-On's don't want to work with the x64 client).

Other features (Common {shared} Signature files, HTML, fonts, picture embedding, etc) look good to me interchangeably under OpenSUSE Linux and Windows XP!

Comment 19

[Martin Sch]

I have created a self signed CA certificate with OpenSSL and imported it into FF 21.0
Worked ok.
I then created a user certificate and imported it and I get ""Could not verify this certificate for an unknown reason".
I have done this a lot of times in the last year but now I cannot find out what is wrong. Pls. provide a way to debug this.

Comment 20

[Rich Rauenzahn]

I'm still getting this in Thunderbird 24.6.0 and it makes it very difficult to communicate to the IT folks configuring IMAP what exactly is wrong with their certificate...

Comment 21

[Wim Lewis]

The following more-informative underlying error codes all currently map to the NOT_VERIFIED_UNKNOWN / USAGE_NOT_ALLOWED values (both of which are displayed as certNotVerified_Unknown, presumably because USAGE_NOT_ALLOWED is also used as a catch-all):

    SEC_ERROR_INADEQUATE_KEY_USAGE
    SEC_ERROR_INADEQUATE_CERT_TYPE
    SEC_ERROR_CA_CERT_INVALID
    mozilla::pkix::MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY
    mozilla::pkix::MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE
    mozilla::pkix::MOZILLA_PKIX_ERROR_V1_CERT_USED_AS_CA

Several of those are misconfigurations that are common aggravations when setting up a local PKI. 

I think it would make sense to do some or all of the following to make the error more useful:
   1) map SEC_ERROR_CA_CERT_INVALID and V1_CERT_USED_AS_CA to the existing error code INVALID_CA
   2) rename the existing error code SIGNATURE_ALGORITHM_DISABLED to something like "inadequate / insecure / disabled algorithm" (not just signature algorithms) and map INADEQUATE_KEY_SIZE to it
   3) stop using USAGE_NOT_ALLOWED as a catchall; give it a useful error message (a la "certificate is not applicable to this purpose") and map SEC_ERROR_INADEQUATE_KEY_USAGE and CA_CERT_USED_AS_END_ENTITY to it.
   4) Map SEC_ERROR_INADEQUATE_CERT_TYPE to USAGE_NOT_ALLOWED as well: an insufficient KU produces INADEQUATE_KEY_USAGE, and an insufficient EKU produces INADEQUATE_CERT_TYPE, as far as I can tell that is the difference between the two.


For #3, in nsUsageArrayHelper.cpp the "let all other errors override USAGE_NOT_ALLOWED" logic could be moved into verifyFailed() (pass in the previous error, and simply return it if the new error is "weaker" than the previous one). verifyFailed() is not referenced anywhere else in the codebase so it could be made static to clarify that.

Comment 24

[Dana Keeler (she/her) [:keeler]]

The implementation producing this message changed somewhat - it should be much easier to expand on the reasons why a certificate couldn't be verified. See https://dxr.mozilla.org/mozilla-central/rev/91c2b9d5c1354ca79e5b174591dbb03b32b15bbf/security/manager/pki/resources/content/viewCertDetails.js#197

Comment 25

[Dana Keeler (she/her) [:keeler]]

This is moot as of the new certificate viewer.