Closed Bug 136920 Opened 22 years ago Closed 22 years ago

Can't see/edit trust on CA certs imported from P12. Can't install CA certs either after P12 import.

Categories

(Core Graveyard :: Security: UI, defect, P2)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
psm2.4

People

(Reporter: Marc.jadoul, Assigned: KaiE)

References

Details

Attachments

(1 file)

Demo P12 files. PWD = 1234abC!
67.49 KB, application/x-zip-compressed
Details 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
BuildID:    2002041016

I imported a P12 for which the root CA + CA chain is not in Mozilla by default. 
After that, my certs are untrusted and I can't edit trust because I do not see 
the CA certs in the Authorities TAB. But somehow the CA certs have been 
imported in the db and can't be installed again by downloading a P7C with the 
right mime type. I get the message 'The certificate already exist'.

Reproducible: Always
Steps to Reproduce:
1. Import a P12 for which CA is not in Mozilla.
2. Go in Authorities TAB: the CA cert isn't there.
3. Try to install the CA cert: you get an error.

Actual Results:  I got hungry and did go for dinner ;-)

Expected Results:  Propose to reinstall the CA certs or open the CA cert and 
permit editing trust on it.

Work around:
1/ Backup all certs
2/ Import CAs
3/ Reimport certs.
->PSM
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 2.3
Confirmed. A workaround appears to be - restart mozilla and the CA is there 
under the Authorities tab.
Status: UNCONFIRMED → NEW
Ever confirmed: true
nsbeta1
Severity: minor → normal
Keywords: nsbeta1
Priority: -- → P3
Just restarting does not resolve the problem for me on version 2002041016.

The work around I know is:
1/ Backup all certs
2/ delete key/cert db
3/ Import the CAs P7C file from a website.
4/ Reimport the certs from the backup.
Reporter, these are your steps - 
"Steps to Reproduce:
1. Import a P12 for which CA is not in Mozilla.
2. Go in Authorities TAB: the CA cert isn't there."

I still can't reproduce this bug. After restarting the browser, I find the new 
CA in the Authorities tab at the bottom of the list, not in alphabetical order. 
Can you check that please? If you still have a problem, can you zip up your cert 
and email it to me with the password to import it?
I can confirm I still have the problem (I just tested it again this)
I am using P12 also uploaded in bug report 133643. Some of these P12 can 
actually be imported, others not. Should I post them here?
* There is a chain: Do you test with a CA chain? |Cert|----|Prim CA|----|Root 
CA|. Root CA is NOT in PSM.
* There could be problems with
   - The netscape cert type of my CAs (Is it still needed/used in mozilla? How?)
   - The pathlen of one of the CA which is NOT WRONG but cause problems in 
communicator 4.79!!!
* Steps are:
   - Downloaded last nightly RPM build from latest-1.0.0: Build ID is 
2002041615. Filenames are mozilla-*-2002041612_1.0.0-0_rh7.i386.rpm
   - Installed rpms and deleted .mozilla directory for my test user (root)
   - Tried to import P12: some could be imported, others not.
   - For those I could import, CA NEVER SHOW UP, even after totally restarting 
mozilla in CA list.

To make it clear, I also meet 3 other problems during this test:
* When you want to import the P12 file, the 'file name to restore' dialog box 
does not show the PFX files, thought the 'Files of type' is 'PKCS12 Files 
(*.p12;*.pfx)'.
* Deleting a CA from the Authorities TAB of the Certificate Manager does not 
work (even after restarting).
* Some P12 couldn't be imported (Bug id 133643).
Same file as in Bug 133643. Some P12 are working, other not.
Bob, do you have an idea why new CA cert from a p12 file would not show up?


I can reproduce the problem, too, with one of my own p12 files from a test CA.

The workaround to restart Mozilla does not help for me.

The workaround to start with a fresh cert db and first import the CA cert
separately over the web, does work for me to.


(I had the suspicion that the patch from bug 125041 might have caused a
regression, because that sound very similar. But that's not true. I tested
backing that change out locally, and it did have any effect re this new problem.)
Status: NEW → ASSIGNED
taking
Assignee: ssaux → kaie
Status: ASSIGNED → NEW
*** Bug 139431 has been marked as a duplicate of this bug. ***
I am nominating this to get fixed as soon as possible.  I have tried the certs
in the zip file as well as a few of my own on the 20020501 Trunk builds, and for
the most part I have been unsuccessful.

I continue to see the error message "The PKCS #12 operation failed for unknown
reasons" when attempting the import.  It occurs in both the Software Security
Device in one profile and the ActivCard device in another profile.
Severity: normal → major
Keywords: adt1.0.0
Priority: P3 → P2
Keywords: adt1.0.0
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 RTM]
Target Milestone: --- → 2.3
Mark,

Please do not mix multiple problems into one defect. The issue is already 
complex enough. It is preferable to have one defect for each bug.

Please be more specific in your instructions. Your ZIP file contains many P12 
files. Telling us to import "a cert for which we don't have the CA" or "the CA 
cert" is not very helpful. Please restate your instructions with the exact file 
names at each step, and make sure that you start from a fresh profile (with a 
new cert7.db / key3.db) so that we can reproduce it exactly and resolve the 
problem. Thanks.

Hi Julien Pierre,
Sorry, my goal was not to mix up things.
To make it clear, I filled this bug about the fact that when importing some 
working P12, if the user certificate in the P12 was signed by a CA for which 
the certificate was not already present in mozilla, himself signed by a self 
signed root CA for wich the self signed certificate was not in mozilla, I 
couldn't edit the trust on the top root CA.
All the cert in the ZIP file are signed by a chained CA for wich the root CA is 
not yet in mozilla, but some of them have a problem due to an other bug (id 
133643).
I want to test it again if you like but could you say to me against wich build? 
Trunk or latest-1.0.0? Until now I was testing against latest-1.0.0 nightly 
build. 
I will thus filter the P12 from the ZIP file. Is it OK?
I think the problem is these certs are being loaded into the database with NULL
nicknames when imported from .p12 files. This is different from 3.3, and we
should fix it. Julien, you can reproduce this part with pk12util.

Once this is fixed, we should also fix the problem of displaying CA certs when
they have a NULL nickname. I'm not sure if this is an NSS problem or a PSM
problem, but we shouldn't have a case where certs can suddenly become 'invisible'.

bob
Bob,

You are correct. I imported one of the certs with pk12util, TESTQCLIENT_RAO.p12 
. The import was successful. I then tried to display the certs with certutil, 
and got a SEGV in SECU_PrintCertNickname. The nickname was NULL. 

(dbx) where
current thread: t@1
  [1] strlen(0x0, 0x0, 0x73, 0x7efefeff, 0x81010100, 0x2b2608), at 0xff0b29ec
  [2] _doprnt(0x0, 0xffbef3d4, 0x4, 0xff139731, 0x0, 0x234415), at 0xff1012b8
  [3] _fprintf(0xff13a264, 0x234410, 0xff13d99c, 0xff139c48, 0x23440a, 
0xffbef415), at 0xff102d60
  [4] SECU_PrintCertNickname(cert = 0x2bb050, data = 0xff13a264), line 1600 in 
"secutil.c"
=>[5] convert_cert(c = 0x2ba018, arg = 0xffbef7e8), line 88 in "pk11cert.c"
  [6] convert_and_cache_cert(c = 0x2ba018, arg = 0xffbef7e8), line 115 in 
"pk11cert.c"
  [7] retrieve_cert(t = 0x29da70, session = 0x29dab8, h = 4157083049U, arg = 
0xffbef7d0), line 573 in "devobject.c"
  [8] traverse_objects_by_template(tok = 0x29da70, sessionOpt = (nil), 
obj_template = 0xffbef744, otsize = 2U, callback = 0x159968 = 
&`certutil`devobject.c`retrieve_cert(struct NSSTokenStr *t, struct nssSessionStr 
*session, CK_OBJECT_HANDLE h, void *arg), arg = 0xffbef7d0), line 275 in 
"devobject.c"
  [9] nssToken_TraverseCertificates(token = 0x29da70, sessionOpt = (nil), search 
= 0xffbef7d0), line 610 in "devobject.c"
  [10] PK11_TraverseCertsInSlot(slot = 0x29b5d8, callback = 0x993e8 = 
&SECU_PrintCertNickname(struct CERTCertificateStr *cert, void *data), arg = 
0xff13a264), line 2887 in "pk11cert.c"
  [11] listCerts(handle = 0x29d8e0, name = (nil), slot = 0x29b5d8, raw = 0, 
ascii = 0, outfile = 0x273620, pwarg = 0xffbef9ec), line 671 in "certutil.c"
  [12] ListCerts(handle = 0x29d8e0, name = (nil), slot = 0x29b5d8, raw = 0, 
ascii = 0, outfile = 0x273620, pwdata = 0xffbef9ec), line 703 in "certutil.c"
  [13] main(argc = 6, argv = 0xffbefaa4), line 2680 in "certutil.c"
(dbx) 

The cert passed to SECU_PrintCertNickname has the following property, among 
others :

    subjectKeyID         = {
        type = siBuffer
        data = 0x2badd0 
"\xe9\x9e\xddL6}?^P\\xc0Q:\xe5r)\x8f\xc0^P\xdd:\xda\xda\xda\xdaCN=Belgacom 
E-Trust Primary CA for qualified certificates, OU=E-Trust TEST, O=Belgacom, 
C=BE"
        len  = 20U
    }

This is a CA cert that was imported along with the cert/key in the p12 import 
phase.

We should fix certutil so it doesn't crash. On NT it display's (NULL). I suspect
that it's a difference in the stdio libraries. (of course certutil should just
reframe from passing NULL to the stdio libraries).
Bob, I opened/resolved bug 142658 for the certutil crash.
We should not generate such certs with null nickname and emailaddr though.

I confirmed that this is an NSS 3.4 regression. The NSS 3.3.2 tree does not 
cause the null nicknames after import, but NSS 3.4.2 and the tip (NSS 3.5) do. I 
am looking into why now.

I nailed it after some tough debugging of both 3.3 and 3.5. The difference is in 
CERT_SaveImportedCert.

In 3.3 it does, among other things :

    if ( isCA && !nickname ) {
	nickname = CERT_MakeCANickname(cert);
	if ( nickname != NULL ) {
	    freeNickname = PR_TRUE;
	}
    }

In 3.4 and up, there is a comment that says :

/* in 3.4, this will only set trust */
SECStatus
CERT_SaveImportedCert(CERTCertificate *cert, SECCertUsage usage,
		      PRBool caOnly, char *nickname)


The code that sets the nickname is gone for 3.4 and up.

After discussing this with Bob Relyea, it appears that both implementations are 
wrong. 3.3 is wrong because it will only set the nickname properly when 
importing a CA certificate into the internal database. 3.4 and up are wrong 
because they don't generate a nickname for CA certificates, regardless of which 
token one is trying to import it to.

The fix is to add the code back at an upper layer. However, it is not clear what 
is the proper layer to do so right now. CERT_ImportCerts takes a 
CERTCertDBHandle rather than a PK11Slot or NSSTrustDomain . So there is actually 
no way to import a CA cert anywhere but in the internal database currently.
Indeed, this limitation is reflected in the PKCS#12 import code in 
nss/lib/pkcs12/p12d.c .

Bob, can you suggest the best way to go short and long term ?

NULL emailaddr's are a characteristic of the cert. Any cert without an email
address (which used to be most certs, but that's been changing) will have a NULL
emailaddr.

bob
Bob, when you say no email address in the cert do you mean no E= in the subject
or neither E= nor altsubject names?

What when there are multiple email addresses? What does NSS do?

Julien, just to clarify something you said in comment #19 -- in NSS 3.4+ there
is only only one NSSTrustDomain.  CERTCertDBHandle has been defined as being of
this type, so a call to CERT_GetDefaultCertDB() will return the default
NSSTrustDomain.

That doesn't reveal a solution to this problem, though.  There is currently no
method to import a cert into a trust domain, there is only a method for
importing into an NSSToken.  So you still must know which token you want it to
land in.
Yes, 

If there is more than one NSS uses the first (first from the subject, then from
the Subject Alt Name).

The 3.x API's do not handle multiple email addresses for the same cert well.

bob
Ian - replying to comment #22 : is that API that imports into the NSSToken 
exposed, or is that a Stan-only API ? It sounds like that's we would need.

This bug is getting somewhat heavy with all the different issues, so I'm going 
to open additional bugs for the individual NSS problems :

142866 - NSS is missing APIs to import CA certs into hardware tokens . 
http://bugzilla.mozilla.org/show_bug.cgi?id=142866

142867 - tracks the limitation in pk12util to softoken for CA certs

142868 - CA certificates are imported with NULL nicknames
Depends on: 142868
No longer depends on: 142868
PK11_ImportCert will call the equivalent Stan function.  If you want to drop a
cert into a token, use it.
Ian - re. comment #25, see my response in bug 142866.

Okay, I guess what I meant is that there is an API function for importing CA
certs into tokens, just not one that correlates to CERT_ImportCerts.  If you
know what token you want to stick the certs in, there is a method to do it.

One thing to note -- the token won't handle trust, so if you want the CA certs
to have trust (I think they get valid ca by default), they're going to end up on
the softoken anyway.  So at the same level where you're calling
CERT_ImportCerts, you could follow up with a call to PK11_ImportCert for each of
the certs, passing the target token.  It would be redundant for untrusted certs,
but it gets the job done.  If you don't know what token is the target at that
level, then that is a bug in the PKCS#12 library.
Also added bug 142889 - slot semantics for P12U_ImportPKCS12Object
Depends on: 142868
ian,

There are reasons to put the intermediate CA's on your token, even untrusted.
You can take your token to machines which don't have those intermediates, but
which chain to a common trusted root.

We used to do this with fortezza all the time (OK we also stored the 'trust' on
the fortezza device using a hack...).
I fixed 142868 which was the problem causing NULL nicknames for the CA certs.
I retested using Marc's test case with PSM. The 2 Belgacom CA certs didn't show 
up the first time around under the "authorities" tab. However, after closing the 
"certificates" window and then closing "preferences", then coming back, they 
showed up, under "Software security device", as expected. I think there may be a 
remaining bug in PSM for this problem. At least the import is working correctly 
now.

john, this is something that can go in the point release. Don't you think. The
underlying NSS issue if fixed, and the workaround is to close and reopen the
cert manager.

Let me know what you think.  Marking adt3 rather than adt2.
Whiteboard: [adt2 RTM] → [adt3 RTM]
Adding relnote keyword.
Keywords: relnote
Target Milestone: 2.3 → 2.4
Whiteboard: [adt3 RTM]
Marking works for me. There are certs in *.zip form in comment #7. I can import
all of them, and edit the CA, and verify that they are trusted, without closing
the Cert Manager. Nov 5, 2002 commercial trunk Win2000 build.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: relnote
Resolution: --- → WORKSFORME
V
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.3 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: