1045491 - Firefox 31 breaks access to HP Command View Server

Status: RESOLVED DUPLICATE of bug 1057123

(Core :: Security: PSM, defect)

Description

[Hans Blom]

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

Comment 1

[Hans Blom]

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

Comment 2

[Camilo Viecco (:cviecco)]

Can you please attach the server certificate?

Comment 3

[Hans Blom]

Attachment: 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"

Comment 4

[therealchewtoy]

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

[therealchewtoy]

Attachment: Another sample cert from a cmdview installation

Comment 6

[therealchewtoy]

Attachment: One more sample cert, from another installation.

Comment 7

[therealchewtoy]

Attachment: 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

[therealchewtoy]

Attachment: cmdview-cert-install-instructions.png

Shows the dialog the cmdview app walks users through for installing its self-signed certs.

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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

[nicola.canepa.74]

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

[therealchewtoy]

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

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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?

Comment 13

[Hans Blom]

Hello,
tested 32.0. No change.

Comment 14

[therealchewtoy]

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

[therealchewtoy]

Attachment: Screenshot of frozen firefox partly done loading cmdview page from nightly.

Comment 16

[Hans Blom]

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

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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.