Closed
Bug 1045491
Opened 10 years ago
Closed 10 years ago
Firefox 31 breaks access to HP Command View Server
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1057123
People
(Reporter: hans.y.blom, Unassigned)
References
Details
Attachments
(6 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243
Steps to reproduce:
I connect to a HP Command View Server
https://server:2374
Actual results:
Connection refused with sec_error_inadequate_key_usage
Expected results:
I should hav gotten login page from the server
Confirmed by downgrading to 30.0, connection working. Upgrading to 31.0 and connection fails
Updated•10 years ago
|
Hard to know if this really is the certificate in question since CommandView is a HP proprietary product and everything is installed "behind the curtains"
Flags: needinfo?(hans.y.blom)
Comment 4•10 years ago
|
||
Just to second this, I have the same issue with 31 and my commandview servers, all six of them. These are self-signed certs created by the commandview installation process, and when you connect with a browser the first time you're expected to place these certs into the trusted root ca store.
I will upload two more sample certs, then also contribute some screenshots of the dialog the site displays until you install these certs as trusted.
Comment 5•10 years ago
|
||
Comment 6•10 years ago
|
||
Comment 7•10 years ago
|
||
This screenshot shows the text the web site displays to a first-time visitor in the browser. This is normal, not a symptom of the problem.
Comment 8•10 years ago
|
||
Shows the dialog the cmdview app walks users through for installing its self-signed certs.
Comment 9•10 years ago
|
||
Thank you for the additional information. From what I can see, the two end-entity certificates you posted here have key usage extensions with the keyCertSign bit set. Unfortunately, the specification specifically disallows this:
from RFC 5280 section 4.2.1.3: Key Usage:
The keyCertSign bit is asserted when the subject public key is
used for verifying signatures on public key certificates. If the
keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (Section 4.2.1.9) MUST also be asserted.
(since the cA bit in the basic constraints extension for end-entity certificates must be false, the keyCertSign bit cannot be asserted in the key usage extension for end-entity certificates)
Is there any way to adjust how the Command View software generates its certificates? (maybe via an advanced configuration dialog?)
Comment 10•10 years ago
|
||
Would it be possible to have a configuration item to turn this check on and off (with default to on, to be safer)?
I think HP (as stated by a technician on the phone) would be unwilling to modify the SAN firmware to change this in the short term.
Comment 11•10 years ago
|
||
I second this request -- though I have little hope it will be addressed by the Firefox team, I have far less hope it will be addressed by HP. In the short term I've switched to using IE for these sites.
In response to David Keeler's question, I am not aware of any way to influence the cert that is used.
There are two versions of CommandView -- one is software installed on a Windows server; the other is embedded within the EVA controllers. The server version is called CommandViewSBM; the controller version is CommandViewABM.
I think the server version is based on Tomcat -- it's probably practical (for someone familiar with Tomcat) to replace the cert in that version, but for the ABM version that's not accessible (presuming it's even Tomcat).
Comment 12•10 years ago
|
||
This might be fixed by bug 1057123. Hans (or anyone else with access to this hardware/software), if you use the latest Nightly version of Firefox, is this still an issue?
Flags: needinfo?(hans.y.blom)
Comment 14•10 years ago
|
||
Just tested Nightly "35.0a1 (2014-09-08)" on win7 x64. Browser freezes completely shortly after starting to parse the page content. I don't think it was getting this far before -- but then again, this still isn't a usable state.
Attached screenshot, "frozenfox.png".
Comment 15•10 years ago
|
||
Reporter | ||
Comment 16•10 years ago
|
||
Tested Nightly "35.0a1 (2014-09-08)" on win7 x64. Freezes as reported by previous testers on startup. Window dark grey, no text, no buttons, just gray abyss.
Comment 17•10 years ago
|
||
Thanks for checking back on that, all. If you can get as far as that screenshot, then the certificate issue has been fixed. The freezing issue would be another bug - I would file a new bug in the general component and have the bug triagers help figure out what might be going on.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•