Closed Bug 294660 Opened 18 years ago Closed 17 years ago

Failure to import ssl server cert from unknown CA as an email cert

Categories

(Core :: Security: PSM, defect)

1.7 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: matt_viljoen, Assigned: KaiE)

References

()

Details

Attachments

(2 files)

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.
Assignee: wtchang → kaie
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: bishakhabanerjee
Version: unspecified → 1.7 Branch
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.
Summary: Failure to import user PEM → Failure to import ssl server cert from unknown CA as an email cert
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.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.