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
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
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.
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/Emailfirstname.lastname@example.org 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/Emailemail@example.com 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/Emailfirstname.lastname@example.org 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
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.
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
Created attachment 72882 [details] pkcs#12 file, password "dummy" 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
Last Resolved: 16 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.
Status: RESOLVED → VERIFIED
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.
You need to log in before you can comment on or make changes to this bug.