Open
Bug 473254
Opened 16 years ago
Updated 2 years ago
Firefox should show an entire Cert Hierarchy even when it's invalid
Categories
(Firefox :: Page Info Window, defect)
Firefox
Page Info Window
Tracking
()
REOPENED
People
(Reporter: bugzilla, Unassigned)
Details
Attachments
(3 files)
Many's been the time I've had more trouble than I should've diagnosing why Firefox was claiming my SSL cert was not trusted. This is not helped by the fact that the 'Certificate Hierarchy' pane, under Certificate Viewer | Details tab, has a Certificate Hierarchy pane that only shows the hierarchy when it's 100% valid. I've set up a couple of domains that use StartCom/StartSSL as the certification authority. This is recognized by Firefox, but requires the web server to present a valid cert chain in order for Firefox to accept the SSL as valid. I think the version of Safari I have doesn't trust StartCom at all. Never mind, because the point of including a screenshot of Safari's behaviour is to illustrate that it's better when it can't verify the SSL's authenticity; see 'Safari's illustration of an invalid cert chain'. It shows the chain that the server is presenting, and where it doesn't trust something. This is useful info to know. Now look at 'Firefox's illustration of an invalid cert chain'. It only shows the current site's certificate! I have purposely set up the site with an invalid CA bundle, so basically Firefox isn't trusting the certificate that is one link above my site's (ie. StartCom Class 1 Primary Intermediate Server CA), but Firefox does not show this. For all I know, there is some weird problem with my cert, or Firefox doesn't trust StartCom itself. Finally look at 'Firefox's illustration of a valid cert chain'. This is good. Basically, I just want it to look like this even when the cert chain is broken because some of it is untrusted, but like Safari, it just gives a red cross or something to illustrate the untrusted parts of the chain.
Forgot to add; if you want to see this problem for yourself, go to https://www.game-point.net/ to see how Firefox's Cert Viewer shows an invalid cert chain, and https://www.mortonsolicitors.com/ to see how it shows a valid one.
Comment 4•16 years ago
|
||
When I visited https://www.game-point.net/ with Firefox 3 this afternoon, I got a working connection (no SSL error was reported) and when I then viewed the cert chain, I saw a chain of 3 certs, the last (highest) of which is the expected root. The orange and blue page showed a game-point pennant logo. Later today, https://www.game-point.net/ began returning the certificate for www.mortonsolicitors.com, and I was no longer able to connect with it without getting a certificate error page, because of the cert name mismatch. Firefox does not intentionally suppress the display of any cert chain information that it has. When it does not display a complete chain, that means that both - the server has sent out an incomplete cert chain, and - the browser does not already have the missing certs for that chain in its certificate database. Firefox constructs as much of the chain from the SSL server's cert to a root CA cert as it can construct, and displays that, even if the chain is incomplete or chains to an untrusted root. Any irrelevant, unparseable or duplicate certs sent out by the server are ignored. The order of the certs doesn't matter to Firefox, except that the first cert sent out must be the server's cert. In your case, the server was sending out 13 certs, but only 3 were relevant, so only those 3 were displayed. This is by design and as intended.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
(In reply to comment #4) > When I visited https://www.game-point.net/ with Firefox 3 this afternoon, > I got a working connection (no SSL error was reported) and when I then viewed > the cert chain, I saw a chain of 3 certs, the last (highest) of which is the > expected root. The orange and blue page showed a game-point pennant logo. That won't happen on a fresh new profile. It would suggest that you've, at some other time, visited a site that caused Firefox to download the 'StartCom Class 1 Primary Intermediate Server CA' certificate. One such site is https://www.mortonsolicitors.com/. > Later today, https://www.game-point.net/ began returning the certificate > for www.mortonsolicitors.com, and I was no longer able to connect with it > without getting a certificate error page, because of the cert name mismatch. No idea why that happened. It's serving up the www.game-point.net cert for me, right now. > Firefox does not intentionally suppress the display of any cert chain > information that it has. When it does not display a complete chain, that > means that both > - the server has sent out an incomplete cert chain, and Then how can Safari display the complete chain and indicate that it doesn't trust the StartCom base cert authority? > - the browser does not already have the missing certs for that chain in its > certificate database. No, but it obviously has the chain that the server tells it it needs to be able to validate the cert. It should show this chain and indicate which certs it doesn't have. > Firefox constructs as much of the chain from the SSL server's cert to a > root CA cert as it can construct, and displays that, even if the chain is > incomplete or chains to an untrusted root. But doesn't appear to display this information in the GUI. > Any irrelevant, unparseable or > duplicate certs sent out by the server are ignored. Fair enough, I'm not asking for that to change. > The order of the certs doesn't matter to Firefox, except that the first > cert sent out must be the server's cert. Are you saying that this isn't happening for either of my example sites? > In your case, the server was sending out 13 certs, but only 3 were relevant, > so only those 3 were displayed. This is by design and as intended. Those 3 were only displayed when the cert chain could be verified. When it couldn't it only showed the one www.game-point.net cert in the hierarchy, instead of all 3, like Safari.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 6•16 years ago
|
||
If the server doesn't send out a complete cert chain, and the browser doesn't already have the missing certs in its cert DB, then the chain will not be completely displayed. That is all as designed and intended. The SSL/TLS specifications require the server to send out the complete cert chain. Mozilla clients depend on servers meeting the requirement.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → WORKSFORME
What's the benefit of not showing the missing certs and indicating they're missing, or problem with showing them?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 8•16 years ago
|
||
Jeremy, is this Safari on Windows or on OS X? If this happens on OS X, than Safari has the same problem, meaning that the complete chain isn't supplied by the server. Firefox doesn't know to fetch the missing intermediate CA certificates as some other browsers do. I agree that this is bad design, but as far as I know code exists for allowing that at some point. The certificates of StartCom support the fetching of the missing certificates once this is turned on.
This is Safari on Windows. Why is StartCom so dependent on intermediate certs, anyway? They don't half cause headaches. A lot of the major cert authorities provide their certs that are just directly issued by the root cert in the browser, so this issue doesn't occur.
Comment 10•16 years ago
|
||
Good Question! It's recommended for CAs to sign the end-user certificates from an intermediate CA and keep the CA root entirely off-line. This way the root isn't exposed to unneeded risks. Most CAs are moving to this scenario these days, which for Firefox presents a certain problem. Incomplete installations result unfortunately in an error. Safari on Windows: Because Safari uses the certificate store provided by the operating system, you'll have to import the StartCom root into Windows currently. For OS X this isn't required because the roots are shipped with the OS similar to Firefox.
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•