Upload CA certificate to iLO?

[Speeddymon]

Hi all,

We have already uploaded signed certificate from private CA.
We are having our iLO scanned for security vulnerabilities by Qualys.
Our iLO is on a network segregated from the production network by ACLs.

We granted Qualys access to scan iLO in order to keep compliant with PCI-DSS and FIPS requirements.
Qualys is reporting the certificate is not trusted.

Our browsers trust our private CA, but PCI requirements won't allow Qualys to trust our private CA.
Our only solution is to upload our CA bundle to the iLO

As per TLS spec, server certificates can include the CA bundle in the same file in the following format:
server certificate, then intermediate CA, then root CA.

So there would be 3 BEGIN CERTIFICATE lines and 3 END CERTIFICATE lines.

I did successfully integrate the 3 certificates into one file in the above format.
Will iLO accept certificates in this format? If not, how can we upload the root CA and intermediate certificates to our iLO?

[Speeddymon]

https://certsimple.com/help/combining-intermediate-and-certificate

This was the instructions I followed to combine the certificates.

[NareshISS]

OpenSSH key formatiLO legacy formatThe iLO legacy format keys are OpenSSH keys surrounded by the BEGIN/END headers needed forRIBCL.This format must be one line between the BEGIN SSH KEY and END SSH KEY text.Administering SSL certificatesSSL protocol is a standard for encrypting data so that it cannot be viewed or modified while in transit onthe network. An SSL certificate is a small computer file that digitally combines a cryptographic key (theserver public key) with the server name. Only the server itself has the corresponding private key, allowingfor authenticated two-way communication between a user and the server.A certificate must be signed to be valid. If it is signed by a Certificate Authority (CA), and that CA istrusted, all certificates signed by the CA are also trusted. A self-signed certificate is one in which theowner of the certificate acts as its own CA.By default, iLO creates a self-signed certificate for use in SSL connections. This certificate enables iLO towork without additional configuration steps.IMPORTANT: Using a self-signed certificate is less secure than importing a trusted certificate.Hewlett Packard Enterprise recommends importing a trusted certificate to protect the iLO usercredentials.

https://support.hpe.com/hpsc/doc/public/display?docId=c03334051

[Speeddymon]

Hi @NareshISS 

I'm not sure how a copy and paste from the user guide is going to help here.

Please re-read my post. We already have our server certificate uploaded in iLO.

The issue is we need to upload the intermediate and root certificates from our PRIVATE CA - so that Qualys will trust the server certificate.

Even though our Browser trusts the private CA, the Qualys vulnerability scanner does not trust it, as it is a PRIVATE ENTERPRISE CA hosted in ActiveDirectory.

Do we need to combine the 3 certificates into one file and upload it?

[Speeddymon]

I generated a new CSR and got the certificate signed by our private CA.

I then followed these steps to combine the server certificate with intermediate certificate:
https://certsimple.com/help/combining-intermediate-and-certificate

Then I tried to upload the combined certificate to iLO 3 but I got this error:
Error making call: call=certificate; error=400; message=Missing '"' at end of string, or string longer than max (4096).

Dell supports 2 certificates combined in one when following certain steps:
https://www.dell.com/community/Systems-Management-General/Uploading-a-private-CA-root-intermediate-certificate-to-iDRAC/m-p/7426869#M28309

Please help us find a fix for our HPE servers

[PeterWolfe]

iLO3 doesn't support adding a CA chain. iLO4 and later do support that. 

Note that the iLO is the server in this case and qualsys is the client. The server is not expected to (but can optionally) supply the CA root. When/if it does do that, the client is expected to ignore it!! The root is only trusted cause it's present in the *client's* trust store. 

So for your specific use-case, all you really need to do is get the proper chain (root and intermediates)  into the client's trust store. 

> Our browsers trust our private CA, but PCI requirements won't allow Qualys to trust our private CA.

Can you elaborate on that? What is it about PCI that doesn't allow you to allow Qualys to trust your CA?

[Speeddymon]

>> Note that the iLO is the server in this case and qualsys is the client. The server is not expected to (but can optionally) supply the CA root. When/if it does do that, the client is expected to ignore it!! The root is only trusted cause it's present in the *client's* trust store.

Hi Peter, unfortunately this is no longer correct. See: https://knowledge.digicert.com/solution/SO16297.html

I realize the OS and browser have the trusted root certificate authorities locally retained, however with CRLs, HTTP headers, OCSP stapling and other modern HTTP features, those monolithic trusted root authority stores are far less important now.

>> > Our browsers trust our private CA, but PCI requirements won't allow Qualys to trust our private CA.
>> Can you elaborate on that? What is it about PCI that doesn't allow you to allow Qualys to trust your CA?

It's not that we don't allow Qualys to trust our CA. It was explained to me that Qualys policies would not permit Qualys from trusting it, even if they wanted to. The only way to verify the certificate is via the root, and the root is not installed in Qualys scanners, therefore it can only be trusted by sending the intermediate certificate with the SSL certificate of the iLO.

>> iLO3 doesn't support adding a CA chain. iLO4 and later do support that. 
What does it take to open a case with iLO engineers to get iLO3 setup with the same ability? I realize storage is limited, however there was another post on here (https://community.hpe.com/t5/ProLiant-Servers-ML-DL-SL/iLO3-1-26-Certificate-error/m-p/5437327/highlight/true#M125655) which highlighted how small the space is for certificates and Oscar indicated he would have iLO team to make space matching the iLO2.

SO, if space could be made available to increase iLO3 certificate storage to match iLO2, then it would stand to reason that they could find some way to free just enough space to allow certificates with the chain as well.

This is a pretty simple requirement to fulfill, so we would appreciate if you could escalate the case to iLO engineers at the earliest. We have a service contract so we could raise a support ticket as well if it's needed. Just let me know if that's the case.