- Hp ilo 4 cli commands serial numbers#
- Hp ilo 4 cli commands serial number#
- Hp ilo 4 cli commands full#
I've managed to inadvertently reproduce this under Nightly 16. Then attach it to the bug when you add the attachment, you will have the option of marking it as security-sensitive before uploading it so other users will not be able to access it. Since this certificate may contain information about the hostname of the server. For the file type, choose "X.509 Certificate with Chain".
Hp ilo 4 cli commands full#
To get the full certificate chain, click on the site identity block (or the lock icon, in Nightly/Aurora) > More Information > View Certificate > Details tab > Export. Having the cert chain will be very useful in determining exactly what the devices are doing wrong. But, before we could even come up with an automatic workaround, it would be very helpful to have the full certificate chain from one of the devices. There are many possible things we could do in Gecko which may or may not work around the issue. (Kev, is resolving this with help on HP's end something in your department?)ĥ. If any users have filed a support request with HP about the issue already, please add your HP issue number to the bug or email me ( with it. We should file a support request with HP about the issue. It should NOT be generating certificates with duplicate issuer/serial-number combinations. Regardless of what mitigations that we may (or may not) implement in Gecko, this is clearly a bug in HP's iLO product.
Hp ilo 4 cli commands serial number#
This will significantly reduce the chances of getting the duplicate serial number error, and usually you can resolve it by restarting the browser, when the override isn't permanent.Ĥ. Another, worse, workaround: When you add the certificate exceptions, make sure you uncheck the checkbox in the override dialog box that makes the exception permanent. Installing your own certificates should solve this problem for you, and it is highly recommended to do so. A workaround: the the HP iLO documentation clearly states that it is possible to replace the certificate used on the device with your own, which could be your own self-signed certificate or a certificate issued by a certificate authority. Bug 435013 can be used for tracking the more general problem.Ģ. Let's keep this bug focused on the HP iLO/iLOM products. Offer a user's choice of what to do: Cancel connection, Accept temporarily, Accept permanently, maybe replacing the conflicting certificateġ. The user only has as choice to continue no connection is establishedĪn encrypted connection should be possible, at least temporarily accepting the dubious certificateĭisplay (or allow to display) details of the certificate being in question, in comparison to the conflicting certificate. A pop-up appears saying that the certificate is not acceptableģ. connect to HP's iLOM2 that has created at least two certificates during its lifetimeĢ. Neither can I see the issuing CA, but I guess the certificate is self-signed.ġ. Unfortunately no serial number is displayed there. Certificate can be viewed from command line's "SO" (=Security Options) and "L" (display SSL certificate). ILOM firmware in question is "E.03.30" (latest AFAIK) on a HP Integrity (Itanium2) rx4640 server.
Hp ilo 4 cli commands serial numbers#
When trying to connect to HP'S iLOM2 (Integrated Lights Out Management 2) via HTTPS, Firefox 2.0.0.4 (on Windows/XP) brings up a windows saying that there was a certificate with a duplicate serial number from the same CA detected, and that I should get a different certificate.ġ) The iLOM2 firmware creates the certificates locally, allowing only limited user influence.Ģ) The user cannot decide to "connect anyway" (like for other dubious certificates)ģ) There's no way to display the details of the certificates that Firefox claims to have duplicate serial numbers (the average user might not care, but the IT professional will)
0 kommentar(er)
