User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 if you go to the URL http://www.certificates-australia.com.au/general/cert_search_health.shtml you should be able to import the ca certificates if you select the netscape mime type radio button and then press the download button. The mime type served by the web server is correct (application/x-x509-ca-cert) but mozilla asks for save/run application for it. A site with the same mime type but without downlod button works well: http://trust.web.de/root.htm Mozilla should also support (preferably) the application/pkix-cert, application/pkixcmp and application/pkix-crl mime type over application/x-x509-email-cert and application/x-x509-ca-cert because the latter ones are just invented by netscape while application/pkix* is the official IANA mime type name. Reproducible: Always Steps to Reproduce:

.

Setting to new

We already have another bug where Nelson explains the special requirements for using the pkix type, we should dupe this bug against it.

*** This bug has been marked as a duplicate of 184649 ***

just the IANA mime type note dups the bud, the main bug report is not a dup.

Mass reassign ssaux bugs to nobody

The way you are using to deliver the certificate is a bit uncommon. In order to look at the response sent by your server, I simulated the button with the following command on Linux: curl --include -F "DN=cn=SecureNet Health OCA,o=securenet limited,c=AU" -F downloadType=caCert -F "filename=SecureNet Health OCA.crt" -F healthDir=true -F mimeType=application/x-x509-ca-cert http://www.certificates-australia.com.au/cgi-bin/download.pl The response sent is: HTTP/1.1 200 OK Date: Thu, 17 Nov 2005 00:15:22 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Content-Disposition: attachment; filename="SecureNet Health OCA.crt" Expires: Thu, 17 Nov 2005 00:15:23 GMT pragma: no-cache Transfer-Encoding: chunked Content-Type: application/x-x509-ca-cert That means, your server is explicitly telling us: the data should be handled as a file attachment. There is a general discussion going on in bug 185618, how such a scenario should be handled. As a workaround, if you can influence the server, make it stop sending the Content-Disposition: attachment; filename="SecureNet Health OCA.crt" line. *** This bug has been marked as a duplicate of 185618 ***