Closed Bug 121487 Opened 23 years ago Closed 22 years ago

NSS3.4 / isolated root imported using p12 not shown in cert manager

Categories

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

Other Branch
x86
Linux
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME
psm2.2

People

(Reporter: KaiE, Assigned: ssaux)

References

Details

Attachments

(2 files)

I have my own little CA, managed using command line tools.
I generated and signed a cert using my own root CA cert, and created a p12 file
which includes key, cert and issuer cert.

I created a fresh profile and imported the p12 file using cert manager. This
works. The cert is not trusted (as expected).

I closed and reopened cert manager to allow it to refresh its list of CAs. But
my own CA does not show up in the list.

However, when I view the details of the imported user cert, I do see the full chain.

When I import the same p12 file into a NSS 3.3 build, the CA shows up.

I think the bug happens during import, because: When I start the NSS 3.4 build,
using the cert database created with the NSS 3.3 build, the CA cert shows up.

You can fetch my root CA cert at:
  http://www.kuix.de/ca/ns.php

Let me know if I should generate a certificate for you.
The function CERT_SaveImportedCert, which set trust bits during cert import, was
removed.  I'm adding it back in order to have the CA trust bits set correctly
during import.

rev 1.23 of certdb/certdb.c
I just retested, the bug seems not to be fixed, I still see the same behaviour.
adding dependency for tracking
Blocks: 116334
I was able to load a P12 file and see the resulting CA in my CA tab. In fact it
has a Root and an Intermediate, and both show up.  Of course the both CA are not
trusted.

These root and intermediate were created with CMS 4.5 instances.

I'm not sure we should keep this open, or make it block 116334.


Priority: -- → P2
Target Milestone: --- → 2.2
Depends on: 122720
Created corresponding NSS bug 122720.  The certs do get loaded, but they do not
show up in the cert manager.

They may show up when one restart the application.
will test further.
No longer depends on: 122720
Some more testing:
Create a new profile.
Get a sectest cert, and back it up.
Note that this profile shows the new certs are verified, but I can't get the
intermediate cert to show up in the CA tab, regardless of whether I restart the
application. The cert is there, but can't be manipulated.

Now I start a new profile.
I import the p12 file created in the previous step.
If I close the certManager and reopen it, I can see the intermediate. I also see
two GTE Cybertrust Root both claiming to be in the built-in token.

I don't think this should block 116334.
It should remain a P1.

Another behavior which loads, but hides the intermediate is:
create a new profile.
setup your imap account.
Read a signed email from a sender with a cert issued by the intranet CA.
The intermediate cert is loaded as part of signature verification, but the
intermediate doesn't show up.
No longer blocks: 116334
The intermediate cert is not showing up because it doesn't have a nickname.

The question is: 1) does the pkcs 12 code implicitly add a nickname, 2) are we
calling a different import api which addes a nickname, or 3) does PSM add the
nickname in one case but not the other?

I suspect 1 or 2 right now.
The basic problem is both NSS and PMS are relying on the IS_CA trust bits. They
are not universally set. I have a patch for NSS that will probably make this
completely go away. I know with the suggessted patch here for PSM, it will.

BTW, PMS can decrease the startup time of the CERT Dialog by 1/3 by rearranging
it's code a bit. Currently PMS calls PK11_ListCerts to extract all the certs
from the token, then filters these lists for the certs it wants. In the course
of creating the CERT Dialog it calls PK11_ListCerts 3 separate times. If the
code called PK11_ListCerts once, then sorted the certificates it would reduce
it's bringup time by about 1/3 (assuming PK11_ListCerts is a significant part of
the bringup of the dialog).

bob
The patch doesn't work for me. I wonder if something is wrong with my CA cert.
After importing the p12 file, my CA cert shows up in the other people's tab.
Clicking details says "this cert has been verified for: Status Responder (only)".

When I edit the cert, then click on "edit ca trust", and trust it manually for
web sites / mail users, has another strange effect. After closing and reopening
cert manager, the CA cert does no longer show up in the other's tab, nor does it
show up in the CA tab or any other tab.

It doesn't matter whether I have your patch applied or not. Below is a text dump
of the CA cert, maybe it is missing some extensions and confuses NSS? It seems
to have only a CA attribute bit set.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=DE, ST=Hessen, L=Frankfurt am Main, O=Kais Ultimate
Information Exchange, OU=Certificate Authority, CN=Kai Engert - personal
CA/Email=kai.engert@gmx.de
        Validity
            Not Before: Feb 15 07:40:31 2001 GMT
            Not After : Feb 15 07:40:31 2003 GMT
        Subject: C=DE, ST=Hessen, L=Frankfurt am Main, O=Kais Ultimate
Information Exchange, OU=Certificate Authority, CN=Kai Engert - personal
CA/Email=kai.engert@gmx.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:9b:a6:74:17:2b:a1:03:dd:fc:27:61:39:a2:e2:
                    5a:ad:4a:38:c5:7c:41:c0:e2:d5:d7:de:25:64:97:
                    17:ca:a3:6a:fa:ea:75:ed:4c:5b:81:e9:b4:2d:d5:
                    dd:08:4c:cd:24:71:7d:0d:ad:68:ec:46:f2:19:3b:
                    d7:4b:9d:45:26:45:d5:30:75:b6:56:21:86:66:cb:
                    44:53:4e:49:da:3f:84:9b:ac:a5:49:5f:94:bc:08:
                    53:69:ef:b6:0c:92:79:8a:b1:b1:68:19:0a:d1:17:
                    6a:72:04:87:9b:52:74:e5:34:0c:93:46:0d:11:ad:
                    9d:a3:6d:3f:60:7f:14:9a:e9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                E7:C6:63:20:5E:7D:62:CD:FA:D3:B3:01:92:8F:49:F7:D0:65:DB:49
            X509v3 Authority Key Identifier:
                keyid:E7:C6:63:20:5E:7D:62:CD:FA:D3:B3:01:92:8F:49:F7:D0:65:DB:49
                DirName:/C=DE/ST=Hessen/L=Frankfurt am Main/O=Kais Ultimate
Information Exchange/OU=Certificate Authority/CN=Kai Engert - personal
CA/Email=kai.engert@gmx.de
                serial:00

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: md5WithRSAEncryption
        5c:c6:31:58:f4:4f:1c:39:3e:e8:3b:b0:35:f3:c9:bd:2c:2e:
        a0:4c:1a:b9:b2:8c:58:46:70:dc:2b:02:30:5d:e0:d0:16:ac:
        90:31:ac:44:a9:3d:bd:a2:d4:9e:98:98:d2:cb:08:37:70:4f:
        38:9e:13:ca:96:38:4c:4d:60:84:52:57:48:13:ae:e6:56:c5:
        ac:de:24:62:34:20:af:10:17:12:f9:6d:24:52:db:66:7e:59:
        af:6f:f8:1e:5a:ab:09:c2:77:8b:34:22:80:69:56:45:86:d8:
        f6:e9:71:65:15:a5:e9:d3:6c:52:29:55:44:7b:b7:6f:1b:31:
        23:0a
Kai.

The patch seems right.  Should we push this through anyway (or attach the patch
to a new bug, and keep this one open to figure why your CA cert exhibit this
behavior?)

Bob, anything obviously wrong in Kai's CA?

Kai, would you agree that unless we can determine that there are lots of CA that
have the same problem as yours, we'll have to later your CA problem (not the
current patch)?
> The patch seems right.  Should we push this through anyway (or attach the patch
> to a new bug, and keep this one open to figure why your CA cert exhibit this
> behavior?)

It's fine with me to land this patch within this bug, if it fixes your other
problem. No problem.


> Bob, anything obviously wrong in Kai's CA?
> 
> Kai, would you agree that unless we can determine that there are lots of CA > that
> have the same problem as yours, we'll have to later your CA problem (not the
> current patch)?

Sure, if Bob says, my CA cert is wrong or looks uncommon, we can just keep this
bug open after the other patch has been checked in.
No Kai, there is nothing wrong with your CA. The "missing nickname" was and
evaluation as to why things worked in one case, but not in another. The real
problem was a difference in the way the trust bits were set on import. My patch
to NSS and the one above for PSM should fix this problem (I think my NSS patch
made it into the landing). My patch is to certdb/certdb.c.

bob
Depends on: 122720
Bob, your change did not make it into the landing (I used a snapshot from
Monday, you checked in Wednesday).

I tried the combinations of patches to certdb.c and your attachment to this bug,
but it does not work for me. I used a fresh cert db, and I still see the same
behaviour as described in comment 10.
No longer depends on: 122720
Depends on: 122720
Kai, Can you post your .p12 file. I can import the root cert just fine with my
tree. I'm running NSS 3.4 tip with the above patch and a new profile. I suspect
we are getting spurious trust inputs from importing the .p12 file, you have a
database with spurious trust values, or you are missing some fixes to NSS that I
have. My hope would be the latter, but my suspicions are the former. I can
verify that with your .p12. Thanks.

bob
Bob, please try this p12 file, I still see the problem when I test with a build
from yesterday morning. Thanks.
I just tested using the newest trunk, which meanwhile has the NSS snapshot from
20020510.

I still see the bug, reproducible with the attached p12 file.
WFM with the 6/6 branch and trunk Win2000 builds.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Verified with yesterday's branch build. The CA will appear. However, as John
reported in a separate bug, it won't appear until you close and reopen the cert
manager window.
Verified WFM.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Revision 1.23 of certdb/certdb.c claims that it was committed to fix this bug,
bug 121487.  See 
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/security/nss/lib/certdb&command=DIFF_FRAMESET&file=certdb.c&rev2=1.23&rev1=1.22

That change had the effect that any certs imported by CERT_ImportCerts have
the VALID_PEER or VALID_CA trust flags set.  

Those trust flags are OVERRIDES.  They cause a lot of cert validity checking 
to be skipped during cert verification.  One consequence of setting the 
VALID_CA trust bit is that it turns any intermediate CA into a valid object 
signing CA, completely defeating the logic that checks for an EKU extension 
to enable object signing.

These OVERRIDE trust bits should NEVER be set routinely.  They should ONLY 
be set when necessary to make a badly constructed cert work. 

So, this "fix" actually introduced a serious bug into NSS, turning all
imported CA certs into object signing CA certs.  

The original problem of PSM not displaying some CA certs should have been
fixed without necessitating that the VALID_CA override be set in all CA
certs.  Perhaps PSM remains dependent on this incorrect behavior.

This NSS flaw needs to be fixed.  I will file a new bug about this.
Revision 1.23 of certdb/certdb.c, which was committed to "fix" this bug,
was backed out in revision 1.80 to fix bug 376737.
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: