Personal certificates change into Server certificates unexpectedly

RESOLVED WORKSFORME

Status

()

Core
Security: PSM
RESOLVED WORKSFORME
7 years ago
2 years ago

People

(Reporter: Andrej Podzimek, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.2.13) Gecko/20110102 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.2.13) Gecko/20110102 Lightning/1.0b2 Lanikai/3.1.7 ThunderBrowse/3.3.4

The list of personal certificates makes it possible to "edit" each certificate and set whether it is trusted or not. There are two problems:

1) The dialog box that pops up when the "Edit..." button is pressed always reports a certificate as "untrusted" by default, although it is in fact trusted.
2) When pressing OK in the dialog box (no matter if the certificate has been set trustworthy or not), the certificate will appear on the list of *server* certifricates next time Thunderbird is started. Presumably, it will also be removed from the list of *personal* certificates at the same time.

This means that settings single certificates trustworthy/untrustworthy does not work. Furthermore, attempting to change these settings "migrates" the certificates from the "personal" list to the "servers" list. (This could be possibly risky in some special cases.)

Reproducible: Always

Steps to Reproduce:
1. Import a *personal* certificate (either explicitly or by accepting a signed message).
2. Select the certificate and click the "Edit..." button. It doesn't matter what you select, but press OK...
3. Close the dialogs and restart Thunderbird.
Actual Results:  
The *personal* certificate will be moved to the list of *server* certificates.

Expected Results:  
A personal certificate must stay on the list of personal certificates... Setting it (un)trustworthy must not transform it into a server certificate.

Perhaps this is only related to certificates signed by an authority trusted for all the three types of authentication (e-mail, server, software). I only tried this with two different authorities, both of them fully trusted.
Component: Security → Security: PSM
Product: Thunderbird → Core
QA Contact: thunderbird → psm
Could someone from the security team please look into this?  Thanks.

Comment 2

6 years ago
Thanks you for the bug report.  I believe problem 2
is caused by the inaccurate tests in the getCertType
function:
http://mxr.mozilla.org/mozilla-central/ident?i=getCertType

2239 PRUint32 
2240 getCertType(CERTCertificate *cert)
2241 {
2242   nsNSSCertTrust trust(cert->trust);
2243   if (cert->nickname && trust.HasAnyUser())
2244     return nsIX509Cert::USER_CERT;
2245   if (trust.HasAnyCA())
2246     return nsIX509Cert::CA_CERT;
2247   if (trust.HasPeer(PR_TRUE, PR_FALSE, PR_FALSE))
2248     return nsIX509Cert::SERVER_CERT;
2249   if (trust.HasPeer(PR_FALSE, PR_TRUE, PR_FALSE) && cert->emailAddr)
2250     return nsIX509Cert::EMAIL_CERT;
2251   if (CERT_IsCACert(cert,NULL))
2252     return nsIX509Cert::CA_CERT;
2253   if (cert->emailAddr)
2254     return nsIX509Cert::EMAIL_CERT;
2255   return nsIX509Cert::UNKNOWN_CERT;
2256 }

The problem is superficial -- under the hood the personal
certificate did not become a server certificate after you
marked it trusted or untrusted.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

3 years ago
Duplicate of this bug: 1128166

Comment 4

2 years ago
No offense guys, but you definitely should actually fix some bugs, instead of just marking duplicates. As it seems, especially the security / nss module code is in dire need of major improvements and bugfixes - loads of age-old ones around here in bugzilla, regarding the S/MIME certificate management, some are up to 10 years old!
Source is available, fixes are welcomed.

Comment 6

2 years ago
Well, even if my knowledge of C/C++ was sufficient for that task, from what I've seen in other bugs, contributions seem to not always be well received - see Bug 278689 as an examplary case - it took almost 11 (!!) years for someone to make a push forward and get it fixed. After at least 2 contributors have escaped fruitless discussions, that went on for years. The real problem would seem to be a lack of acknowledgement by the project management, that the whole certificate management / nss component area is aging and becoming increasingly unusable (maybe also unmaintainable) and obviously litte effort has been put into it for a quite some time now. If I could get in contact with some person leading maintenance and/or strategics at Mozilla, I'd be happy to compile a selection of examples with focus on prioritizing bug and usability fixes as well as change proposals for certificate handling in Mozilla and Thunderbird.
That button was removed in bug 1130418, so it isn't possible to cause this to happen by the same mechanism any longer.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.