User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 User PEM certificate cannot be imported - either from website (see URL) or from file (e.g. after downloading the file with curl). Host certificates on the other hand can be imported: e.g: https://ca.grid-support.ac.uk/cgi-bin/pub/download.cer?cmd=send_email_cert;type=email;key=4032 Reproducible: Always Steps to Reproduce: 1. Click on link to PEM Alternatively: 1. Click on Import in Certificate Manager and load PEM. Actual Results: Nothing. The certificate is not listed in Certificate Manager -> Other People Expected Results: The certificate should be listed in Certificate Manager -> Other People

Nelson, what exactly is the PEM certificate format?

I have tried, but have not found any evidence of any NSS bug here. IMO, this is a PSM bug. There may or may not be an NSS bug underlying it, but the issue is that PSM fails to import the downloaded cert and provides no explanation for the failure to the user. That's not NSS's fault. Wan-Teh, PEM is a file format defined by OpenSSL, based on ideas found in the PEM RFCs. Basically it's a text file containing one or more items such as certs, keys, etc. each of which is base64 enocded, and surrounded by text lines that look like ------- BEGIN CERTIFICATE ------ (base64 lines here ------- END CERTIFICATE ------ For things other than certs, the word CERTIFICATE is replaced in those text files with a word that describes those other things. NSS supports files containing only a single PEM-format certificate. That's what's being downloaded by the URL cited above. certutil will import them and create them when the -a argument is used. I downloaded the cert file from the URL cited above, and had no trouble importing it with certutil -A. I doubt that PEM format is relevant to the issue. Some time ago, there was a big CERT alert/vulnernerability-report complaining that if the browser imports certs that cannot be validated, the browser is vulnerable to various attacks (mostly DoS) due to importing bad certs. The solution was for the browser to stop importing certs that cannot be validated. That may be whats going on here. This cert has a Netscape certificate type extension in it that says it is valid for SSL server and SSL client use, only, and does not include email use. That may be relevant. The server downloads the cert with MIME content type application/x-x509-email-cert, so it is conceivable that the browser is checking the cert to see if it is valid for email, and finds that it is not, and then fails to import it. Perhaps it would import if the issuing CA was downloaded and trusted first. This report does not yet include a URL for that CA cert. Note that NSS does not impose any such restrictions on importing certs itself. certutil will happily import the cert cited above. Note that these certs come from a company's own private CA. Once again NSS developers are being drawn into the CA-education business through bugzilla.

Nelson, thank you very much for looking into this. I will convert your comment into a tech note so you didn't waste your time. Changed product to Core: Security: PSM.

I have done a little more research and if the CA root certificate is first imported into the browser by following this link: http://ca.grid-support.ac.uk/pub/cacert/cacert.crt and the user explicitly checks: "Trust this CA to identify software developers" then the user certificate is imported successfully. However, the user certificate still does not appear under Other People's certificates but rather under Web Sites.

The fact that the cert was succesfully imported after the issuing CA cert was imported and trusted appears to confirm my hypothesis that this is the result of the fix for bug 249004. PSM apparently no longer imports unverifiable certs. After reading bug 249004, I would say that is intentional, and the code is now working as designed. In that case, the observed behavior is not a bug, per se'. The cert doesn't appear in the tab of email certs because the cert has an extension that clearly says it is only valid for SSL, not email. I will attach a "pretty" formatted version of the cert to this bug to show that. The cert is being shown in cert manager as an SSL server cert because that is the only potentially valid use that NSS could make of it in the browser. So, I don't see a bug here. But (at this time) I will stop short of marking it invalid. Attachments forthcoming.

Notice the certificate type extension in the cert. It says the cert is only valid for SSL client and SSL server use, not email. That's why cert manager displays it as an SSL server cert. (If the browser also had the private key for it, it would appear as one of the user's own certificates.)

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

Marked the bug invalid based on Nelson's analysis (comment 5). The only thing we could do would be to do something about the silent failure problem of the fix for bug 249004. That is, if the cert we want to import is not valid, PSM right now silently ignores it. It would be nice to pop up an error dialog in that case.