Failed to install ca signing certificate with NS3.6beta



17 years ago
17 years ago


(Reporter: thomask, Assigned: nelson)



Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



17 years ago
The NSS library fails to import the ca signing certificate into
the database.

Additional Info:
  - we are using just software token
  - this operation used to work with NSS3.4x
  - certificate is actually imported
  - this could be a JSS problem where it fails to recognize new error code

Log File:

2002/09/19 17:05:44:  [
  Version: V3
  Subject: CN=Certificate Manager,O=fsdfsdf343r3,C=US
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  algorithm = RSA, unparsed keybits =
30 81 89 02 81 81 00 CE 46 79 33 1D 47 5B 2B 84 07 9A 49 F9
AA 34 4A 57 5C 59 2B 7C 86 FC B0 B5 41 A4 BF 12 70 FF 33 39
04 B6 61 55 0A AD C0 97 6C 5E F9 9B 8B 4D 6A 58 38 54 43 27
C2 FD A1 6C 17 F3 69 6D 4D 60 2C CD BF 25 BE 03 94 EF E8 A4
FB F7 01 45 09 29 41 1C 9F 32 22 33 21 E2 2C BF 9E 88 E1 38
D1 99 F9 C6 E6 86 CB FC 0E 80 01 AF EE 00 50 62 51 40 F9 0D
9E C9 DA 73 BB 5D 98 DA 0D 59 4A 8B 73 30 B1 02 03 01 00 01

  Validity: [From: Thu Sep 19 00:00:00 PDT 2002,
               To: Sun Sep 19 00:00:00 PDT 2004]
  Issuer: CN=Certificate Manager,O=fsdfsdf343r3,C=US
  SerialNumber: [    01]
  Extension[0] = ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NSCertType [
   SSL CA   Email CA   Object Signing CA]
  Extension[1] = ObjectId: Criticality=true
PathLen: undefined
  Extension[2] = ObjectId: Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
25 14 37 BD F3 D3 E4 D9 A9 59 35 1E 52 BE 46 C2 44 9B B9 1E
  Extension[3] = ObjectId: Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
25 14 37 BD F3 D3 E4 D9 A9 59 35 1E 52 BE 46 C2 44 9B B9 1E
  Extension[4] = ObjectId: Criticality=true
KeyUsage [

  Algorithm: [SHA1withRSA]
83 93 96 0F CE 6B A3 E2 73 F3 13 84 84 1C 35 5F 2F 73 B2 D1
10 22 65 CF 36 E9 49 AE BC FC 7A DB 19 4E F5 96 41 85 48 25
76 A5 EC 59 35 67 5E E4 C7 7E F4 73 02 CB 9E 00 69 9A 98 EE
B3 E2 B3 A2 31 5D 0C F0 05 32 A4 53 E2 92 C6 9E 82 FE DE 4A
5B 99 DF DA F9 70 38 D2 7F 89 3D 50 DC B8 2A AC 5A D4 D7 09
A7 0B A8 27 0A 12 40 E3 B2 79 D8 D6 B1 A5 14 C8 FD 4D 84 88
DB 49 7C BC AA 32 52 58
2002/09/19 17:05:44: about to import cert for nickname: caSigningCert cert-x1
2002/09/19 17:05:44: error failure importing cert CERT_ImportCAChain returned an
Token Error: import CA cert failure
ion: CERT_ImportCAChain returned an error
        at com.netscape.certsetup.daemon.CreateCertificateProcessor.createCASign

certutil Log:

C:\netscape\Servers\alias>..\bin\cert\tools\certutil -d . -L -P cert-x1-pc614451
caSigningCert cert-x1                                        u,u,u

Comment 1

17 years ago
The complete JSS stack trace: CERT_ImportCAChain returned an
        at org.mozilla.jss.CryptoManager.importCertPackageNative(Native Method)
        at org.mozilla.jss.CryptoManager.importUserCACertPackage(CryptoManager.j
        at com.netscape.certsetup.daemon.CreateCertificateProcessor.createCASign
        at com.netscape.certsetup.daemon.CreateCertificateProcessor.processReque
        at com.netscape.certsetup.daemon.InstallWizardDaemon.processRequest(Inst
        at com.netscape.certsetup.daemon.InstallWizardDaemon.handleConn(InstallW
        at com.netscape.certsetup.daemon.InstallWizardDaemon.main(InstallWizardD

Comment 2

17 years ago
NSPR 4.2.2Beta
JSS  3.2

Comment 3

17 years ago
Bob, please take a look at this bug that Thomas reported.
This bug is preventing him from testing NSS 3.6 Beta1.
Severity: normal → blocker
Ever confirmed: true
Priority: -- → P1
Target Milestone: --- → 3.6

Comment 4

17 years ago
Assigned the bug to Nelson.
Assignee: relyea → nelsonb

Comment 5

17 years ago
We found that __CERT_AddTempCertToPerm is failing immediately because the cert's
crypto context is null. Here's where it happens:

context = c->object.cryptoContext;
if (!context) {
    return SECFailure; /* wasn't a temp cert */

Here's the stack trace:
=>[1] __CERT_AddTempCertToPerm(cert = 0x1a05d0, nickname = 0x12da68 "CA", trust
= 0xffbeeb30), line 148 in "stanpcertdb.c"
  [2] CERT_AddTempCertToPerm(cert = 0x1a05d0, nickname = 0x12da68 "CA", trust =
0xffbeeb30), line 200 in "stanpcertdb.c"
  [3] cert_ImportCAChain(certs = 0x196494, numcerts = 0, certUsage =
certUsageUserCertImport, trusted = 1), line 896 in "certhigh.c"
  [4] CERT_ImportCAChainTrusted(certs = 0x196488, numcerts = 1, certUsage =
certUsageUserCertImport), line 949 in "certhigh.c"
  [5] Java_org_mozilla_jss_CryptoManager_importCertPackageNative(env = 0x2c4cc,
this = 0xffbeed94, packageArray = 0xffbeed90, nickString = 0xffbeed8c, noUser =
'\0', leafIsCA = '\001'), line 974 in "PK11Finder.c"
  [6] 0xfa40bbc8(0xf2210c00, 0xb7, 0xffbeee2c, 0xffffffff, 0xfa4150c4,
0xffbeed28), at 0xfa40bbc7
  [7] 0xfa405b10(0xf2210c00, 0xb6, 0x8, 0xfa415238, 0xf61119b0, 0xffbeedb0), at
  [8] 0xfa405b10(0xffbeeee8, 0x0, 0x0, 0xfa415080, 0x3493c8, 0xffbeee88), at
  [9] 0xfa400118(0xffbeef74, 0xffbef170, 0xa, 0xf6112788, 0xfa40aae0,
0xffbef070), at 0xfa400117
  [10] JavaCalls::call_helper(0xffbef168, 0xffbef028, 0xffbef068, 0x2c440,
0x2c440, 0x5c00), at 0xfe0d4a10
  [11] jni_invoke_static(0x1, 0xffbef168, 0x0, 0x0, 0xbdf30, 0xffbef14c), at
  [12] jni_CallStaticVoidMethod(0x2c4cc, 0x2ce78, 0xbdf30, 0x2ce88, 0x2c4cc,
0xf20408b8), at 0xfe189ba0
  [13] main(0x2, 0x0, 0xbdf30, 0x2ce88, 0x0, 0x280), at 0x1237c

However, this cert had already been imported, probably by
PK11_ImportDERCertForKey, since it is a user cert AND a CA cert. This may be a
problem in the JSS import code.
This appears to be a bug in new stan code.  I suggest Ian take a look.

Apparently the sequence of events is that the JSS function 
Java_org_mozilla_jss_CryptoManager_importCertPackageNative in 
mozilla/security/jss/org/mozilla/jss/PK11Finder.c takes in a DER encoded
self-signed root CA cert for which the key pair was previously generated in
this same process, and the private key is in the local key DB.  That function 
calls PK11_ImportDERCertForKey to import the cert, and then calls 
CERT_ImportCAChainTrusted to import it again. (?)  cert_ImportCAChain calls 
CERT_DecodeDERCertificate to decode the cert, then calls CERT_IsCACert(), 
CERT_NewTempCertificate(), CERT_MakeCANickname(), and then calls 
CERT_AddTempCertToPerm() which calls STAN_GetNSSCertificate, and expects 
the NSSCertificate returned to have a non-null cryptoContext.  But the 
cryptoContext is null.  The stack trace shown above is of that call to 

While there is some question about whether that sequence of calls to NSS
functions by the JSS function is a reasonable sequence, it apparently worked 
with NSS 3.3 and NSS 3.4 but not with NSS 3.6.  

Another bug observed here is that __CERT_AddTempCertToPerm does not call
PORT_SetError (or its stan equivalent, if any) to set the error code before
returning SECFailure, so the error code returned to the caller is 
SEC_ERROR_BAD_DATABASE, which isn't helpful.  
As I look some more at __CERT_AddTempCertToPerm, it is apparent to me that
this code is not intended to succeed when the referenced cert is already
a perm cert.  It appears to me that this should have failed, beginning in 
NSS 3.4 RTM.    

Thomas wrote that it worked with "NSS3.4x", but I wonder ... was it 
perhaps only tested with a release candidate of NSS 3.4, and not with the

In any case, I now think that the right course of action is to change 
Java_org_mozilla_jss_CryptoManager_importCertPackageNative to not attempt
to "import" this cert twice.  
I think that rev 1.17 to nss/lib/certhigh/certhigh.c is probably the change
that caused CERT_ImportCAChainTrusted to fail when the cert has already
been imported by a call to PK11_ImportDERCertForKey.  

rev 1.17 changed cert_ImportCAChain() to call CERT_NewTempCertificate
where it had previously called CERT_DecodeDERCertificate(), and to call
CERT_AddTempCertToPerm where it had previously called PK11_ImportCert().

I think one consequence of those changes was that certs already in the cert 
DB (or other token) may now fail to be imported by cert_ImportCAChain().

Comment 9

17 years ago
Created attachment 100686 [details] [diff] [review]
don't fail when attempting to add cert that is already perm

Based on Nelson's comments, I believe there is an NSS bug to be fixed
(independent of possibly changing JSS).  We fail attempting to add a temp cert
to the perm db, when really the cert was already perm.	There are two ways to
fix this:

1) Detect that a cert return from CERT_NewTempCertificate() is perm, and don't
call CERT_AddTempCertToPerm().

2) Return SECSuccess from CERT_AddTempCertToPerm if the cert is already perm.

I suppose there is also (3) -- do both (1) and (2).

This patch does (1).  I believe it makes sense, we shouldn't be calling
CERT_AddTempCertToPerm if the cert is not temp.

Comment 10

17 years ago
Comment on attachment 100686 [details] [diff] [review]
don't fail when attempting to add cert that is already perm

This patch looks good.	r=wtc.

Thomas, I have debug and optimized builds
of the NSS tip with this patch applied for
Solaris 8 in /u/wtc/thomask/.  Could you
test it and see if Ian's patch fixes the
Attachment #100686 - Flags: review+

Comment 11

17 years ago
Sorry for adding my comment late. I think there is problem when we start with a 
brand new cert7.db. So the problem is not specific to duplicated certificate. I 
just tried the patch and it failed on the same spot with the same error message.

Comment 12

17 years ago
Created attachment 100763 [details] [diff] [review]
new patch

There was a problem with the last patch: it didn't set rv, and so after we
skipped the AddTempCertToPerm call, rv was uninitialized, which caused the
function to return an error.

This new patch alleviates this problem.

My test program now works without throwing an exception. However, the
newly-imported cert has no trust flags (certutil shows ",,").

Thomas, can you try your test case and see if trust gets set correctly later?


17 years ago
Attachment #100686 - Attachment is obsolete: true
I will do a test build for Thomas on Solaris 8
OS: Windows 2000 → Solaris
Hardware: PC → Sun

Comment 14

17 years ago

Debug build (for Solaris 8) with Jamie's new patch
is now available in /u/wtc/thomask.  Optimized
build will be there too in 10 minutes.

Comment 15

17 years ago
Much better, I can install CMS now with this version of NSS. I tested basic 
stuff such as certificate signing, SSL..etc

I did not test hardware token setup with CMS.

Comment 16

17 years ago
Mark this as fixed
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 17

17 years ago
Comment on attachment 100763 [details] [diff] [review]
new patch

r=wtc.	Jamie, please go ahead and check in your patch.
Attachment #100763 - Flags: review+

Comment 18

17 years ago
Fixed on trunk for NSS 3.6.

/cvsroot/mozilla/security/nss/lib/certhigh/certhigh.c,v  <--  certhigh.c
new revision: 1.27; previous revision: 1.26

Comment 19

17 years ago
There is still a patch to get checked in for hardware to work. Only part of the
NSS 3.4.1 fix is in the 3.6 Beta 1 tree. 
You need to log in before you can comment on or make changes to this bug.