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



Core Graveyard
Security: UI
16 years ago
a year ago


(Reporter: Marc Jadoul, Assigned: kaie)


1.0 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)

67.49 KB, application/x-zip-compressed


16 years ago
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.
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 2.3

Comment 2

16 years ago
Confirmed. A workaround appears to be - restart mozilla and the CA is there 
under the Authorities tab.
Ever confirmed: true

Comment 3

16 years ago
Severity: minor → normal
Keywords: nsbeta1
Priority: -- → P3

Comment 4

16 years ago
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.

Comment 5

16 years ago
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?

Comment 6

16 years ago
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 
* 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).

Comment 7

16 years ago
Created attachment 79783 [details]
Demo P12 files. PWD = 1234abC!

Same file as in Bug 133643. Some P12 are working, other not.

Comment 8

16 years ago
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.)

Comment 9

16 years ago
Assignee: ssaux → kaie

Comment 10

16 years ago
*** Bug 139431 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
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


16 years ago
Keywords: adt1.0.0


16 years ago
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 RTM]
Target Milestone: --- → 2.3

Comment 12

16 years ago

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.

Comment 13

16 years ago
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 
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 
I will thus filter the P12 from the ZIP file. Is it OK?

Comment 14

16 years ago
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'.


Comment 15

16 years ago

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 
=>[5] convert_cert(c = 0x2ba018, arg = 0xffbef7e8), line 88 in "pk11cert.c"
  [6] convert_and_cache_cert(c = 0x2ba018, arg = 0xffbef7e8), line 115 in 
  [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 
  [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"

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

    subjectKeyID         = {
        type = siBuffer
        data = 0x2badd0 
E-Trust Primary CA for qualified certificates, OU=E-Trust TEST, O=Belgacom, 
        len  = 20U

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

Comment 16

16 years ago
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).

Comment 17

16 years ago
Bob, I opened/resolved bug 142658 for the certutil crash.
We should not generate such certs with null nickname and emailaddr though.

Comment 18

16 years ago
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.

Comment 19

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

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 */
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 ?

Comment 20

16 years ago
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


Comment 21

16 years ago
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?

Comment 22

16 years ago
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

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.

Comment 23

16 years ago

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.


Comment 24

16 years ago
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 .

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

142868 - CA certificates are imported with NULL nicknames
Depends on: 142868


16 years ago
No longer depends on: 142868

Comment 25

16 years ago
PK11_ImportCert will call the equivalent Stan function.  If you want to drop a
cert into a token, use it.

Comment 26

16 years ago
Ian - re. comment #25, see my response in bug 142866.

Comment 27

16 years ago
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.

Comment 28

16 years ago
Also added bug 142889 - slot semantics for P12U_ImportPKCS12Object
Depends on: 142868

Comment 29

16 years ago

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

Comment 30

16 years ago
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 

Comment 31

16 years ago
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]

Comment 32

16 years ago
Adding relnote keyword.
Keywords: relnote


16 years ago
Target Milestone: 2.3 → 2.4


16 years ago
Whiteboard: [adt3 RTM]

Comment 33

16 years ago
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.
Last Resolved: 16 years ago
Keywords: relnote
Resolution: --- → WORKSFORME

Comment 34

16 years ago


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core


10 years ago
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.