Firefox 31 breaks access to HP Command View Server




4 years ago
4 years ago


(Reporter: hans.y.blom, Unassigned)


30 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)



(6 attachments)



4 years ago
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

Actual results:

Connection refused with sec_error_inadequate_key_usage

Expected results:

I should hav gotten login page from the server

Comment 1

4 years ago
Confirmed by downgrading to 30.0, connection working. Upgrading to 31.0 and connection fails


4 years ago
QA Whiteboard: [bugday-20140804][DUPEME]
Component: Untriaged → Security: PSM
Product: Firefox → Core
See Also: → bug 1044350, bug 1044269
Can you please attach the server certificate?
Flags: needinfo?(hans.y.blom)

Comment 3

4 years ago
Created attachment 8467605 [details]
Hello, I think this is the certificate in question.

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

4 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

4 years ago
Created attachment 8471668 [details]
Another sample cert from a cmdview installation

Comment 6

4 years ago
Created attachment 8471669 [details]
One more sample cert, from another installation.

Comment 7

4 years ago
Created attachment 8471672 [details]
Screenshot showing text cmdview displays when cert not installed in browser trust store.

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

4 years ago
Created attachment 8471676 [details]

Shows the dialog the cmdview app walks users through for installing its self-signed certs.
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 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 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

4 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

4 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).
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 13

4 years ago
tested 32.0. No change.
Flags: needinfo?(hans.y.blom)

Comment 14

4 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

4 years ago
Created attachment 8485753 [details]
Screenshot of frozen firefox partly done loading cmdview page from nightly.

Comment 16

4 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.
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.
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1057123
You need to log in before you can comment on or make changes to this bug.