Cannot import CRLs directly via links on a web page

RESOLVED INVALID

Status

Core Graveyard
Security: UI
RESOLVED INVALID
16 years ago
2 years ago

People

(Reporter: Sönke Tesch, Assigned: kaie)

Tracking

1.0 Branch
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
The CRLs from one of Germany's largest CA, TC TrustCenter AG, cannot be imported
via their web page at https://www.trustcenter.de/cgi-bin/CRL.cgi . Upon clicking
on one of the links to the CRLs, Mozilla just displays "Tranfering data.." in
the status bar forever. Stopping the transfer brings up a small window telling
me that the the download failed due to network problems.

Importing the CRLs works if you download them manually using the context menu
and then drag'n'drop the files into the browser window. However in this case the
automatic update feature doesn't work since the URL points to the files on the
local harddisk.

TrustCenter notes on the mentioned page that "Netscape only supports CRLs of
version 1". No idea if this is the reason or not. Makes me wonder however why
it's then possible to import the CRLs manually.
->Whoops, this one's been sitting here a while. Over to PSM.
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → bmartin
Version: Trunk → 2.4

Comment 2

15 years ago
I suspect that the server is not giving the right mime type to the browser.
This functionality works with, for example:
http://crl.verisign.com/RSASecureServer.crl

Mozilla will figure it out if the extension of the file ends in .crl, or the
proper mime type is passed by the cgi.

Assignee: ssaux → kaie

Comment 3

15 years ago
Created attachment 125507 [details]
Transcript of HTTP sessions showning varying content types returned, one of which demonstrates Mozilla not overriding content type (and not processing valid crl)

Updated

15 years ago
Attachment #125507 - Attachment description: Transcript of HTTP sessions showning varying content types returned → Transcript of HTTP sessions showning varying content types returned, one of which demonstrates Mozilla not overriding content type (and not processing valid crl)
(Assignee)

Comment 4

15 years ago
What Stephane said.

application/octect-stream is a general content type for untyped binary data.

The processing will only work if the cgi script returns a correct content type
like application/x-pkcs7-crl

Regarding your other question, automated updating, you can still enable
automatic update if you go to edit/prefs/privacy/validation/manage crls and edit
your crl.


Resolving bug as invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID

Comment 5

15 years ago
Kai: 
I understood from Stephane's comment that either the mime type OR the extension
would allow Mozilla "to figure it out".  If this is design behaviour this is
fine; but a note somewhere would be helpful since at least in my case I was
mystified by the behaviour (i.e. reading the file using HTTP failed, by FTP or
directly from a disk file the same crl file was ok).  And programs like MS IE
don't seem to operate the same way.

On your second point, "edit/prefs/privacy/validation/manage crls and edit
your crl".  As far as I can tell you cannot edit the url.  You can only
enable/disable updating and set update time/frequency. Additionally of course,
you cannot enter a new url either (only delete them).  So you cannot download
the file, read it directly from a disk to get Moz to recognize it as a crl, then
edit the url to point back to the original location (and presumably when
accessed this way the content-type has no bearing?).  Actually the easiest work
around is to use FTP, that seems to work.

I have verified that this is still the case in 1.4RC2.
(Assignee)

Comment 6

15 years ago
> either the mime type OR the extension
> would allow Mozilla "to figure it out"

I think the extension is not used by Mozilla, we rely completely on the mime
type returned by the server.
Severity: minor → normal

Updated

14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

10 years ago
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.