|
Post by AMI_Mani on Apr 20, 2021 17:31:07 GMT
Hi, We have below command in Host interface 1.3.0 for verifying Server certificate
Get Manager Certificate Fingerprint (NetFn 2Ch, Command 01h)
This command is used to get the fingerprint for the manager's TLS certificate for the host interface. In most cases, the
manager will only have one certificate available. Clients should use the response data from this command when
connecting over the host interface to verify the service's certificate matches.
We have option to get redfish account using Get Bootstrap Account Credentials during provision. Do we have any plan of getting server certificate also similar to this command, so that BIOS/Firmware doesn't required to have certificate embedded. As of now we have option to upload certificate in BIOS setup based on Managers certificate, but this will be similar to manual operation and doing for 1000's of server becomes complex
If we have any other option to achieve this please let me know
Thanks, Mani
|
|
|
Post by mraineri on Apr 20, 2021 17:42:00 GMT
Once you get your bootstrap account, you can then transition to the Redfish interface to get more information about the service. Transporting a certificate over IPMI in its entirety was not seen as beneficial considering that this would be performed over some low speed interface such as KCS. The usage of IPMI was kept very minimalistic in order to promote using the network interface with the full Redfish model.
|
|
|
Post by AMI_Mani on Apr 20, 2021 17:52:45 GMT
We can get Redfish username, password, but communicating to server with https needs certificate to be verified. We need to transport rootca of Manager for hostinterface to work and it will not be big size. There is no user involvement in this process, so only asking for this support for initial stage of provisioning
If my understanding is incorrect, please explain about getting more information
Once you get your bootstrap account, you can then transition to the Redfish interface to get more information about the service
Thanks, Mani
|
|
|
Post by mraineri on Apr 21, 2021 15:43:36 GMT
At this time we're not looking at extending IPMI usage any further. The scope of the bootstrap feature was very much limited to being able to transition to the Redfish interface. The request from users to solve this gap wanted something simple that would work on existing hardware, operating systems, and drivers. IPMI was the lowest common denominator, and so the focus was a very minimal approach to easily get credentials and allow users to switch to the Redfish interface.
Most scripts and client tools we've worked with do not necessarily need the certificate to be fully validated; most factory default deployments have self-signed certificates, which never validate. Still, once you establish your HTTPS connection you can query the manager's certificates further in the Redfish model itself, which would be found in the "Certificates" collection under the "HTTPS" object in "ManagerNetworkProcol".
|
|
|
Post by igork on May 3, 2021 15:51:40 GMT
At this time we're not looking at extending IPMI usage any further. The scope of the bootstrap feature was very much limited to being able to transition to the Redfish interface. The request from users to solve this gap wanted something simple that would work on existing hardware, operating systems, and drivers. IPMI was the lowest common denominator, and so the focus was a very minimal approach to easily get credentials and allow users to switch to the Redfish interface.
Most scripts and client tools we've worked with do not necessarily need the certificate to be fully validated; most factory default deployments have self-signed certificates, which never validate. Still, once you establish your HTTPS connection you can query the manager's certificates further in the Redfish model itself, which would be found in the "Certificates" collection under the "HTTPS" object in "ManagerNetworkProcol". Hello, My name is Igor and I'm from BIOS Redfish team in AMI. I have a question regarding your suggestion. But first let me explain the whole picture we have here. According to Redfish Host Interface specification in-band Host BMC communication should be protected with HTTPS protocol. Which means we have to use certificates to verify the connection since it is one part of the process. BIOS should make sure that it is talking to the right service, because BMC can send the critical commands to BIOS to initiate actions like enable/disable secure boot, update SecureBoot certificates, boot from specific boot device etc. So, we must be sure that we are getting those requests from the trusted source. And to make sure we have to use RooCA certificate and verify that we are getting request from the BMC. Previously we have predefined during build time RootCA which we keep on BIOS side as well as public certificate and private key on BMC side which were used for protection of in-band BIOS BMC communication. But keeping private key on BMC side maybe also not secured approach, because if some unintended person have the access to BMC he can compromise those private keys. So there were a suggestion to generate that set of the certificates and keys dynamically and use them to secure connection. And here we have that question raised if we generate everything on flight then we have to be able to provide the RootCA to BIOS using different connection from what we are trying to protect with TLS certificates. Because if we are using the same connection channel to send the certificate unprotected first and then we use that certificate to protect that channel then there is no sense at all in such protection. Thank you, Igor
|
|
|
Post by mraineri on May 4, 2021 18:46:22 GMT
Still pointing back to the original scope of these IPMI commands, the scenario you're describing goes outside the original goal of establishing these IPMI commands. The scope was to allow a stateless OS or management application to get Redfish credentials for the host interface. Beyond that the OS or management application can inspect the service's web certificates as needed, update them, etc, all via Redfish.
Since AMI is a member company, please feel free to bring this within the forum for further discussion.
|
|
|
Post by igork on May 5, 2021 13:54:48 GMT
One more question then. You still introduced one more IPMI command to get the certificates fingerprint. And my understanding you still consider that situation RootCA maybe wrong or not there. In case of fingerprint is differ, what should be done?
|
|
|
Post by mraineri on May 5, 2021 14:52:00 GMT
It's really up to the client. A client that is security conscious will likely terminate the connection during TLS handshaking.
Essentially the manager will have some web certificate, which could be some default self-signed certificate, or some certificate already installed by a user via other operations. The scope is not for verifying the root CA is correct, but rather to help ensure the fingerprint obtained via IPMI matches the fingerprint obtained via TLS handshaking when making the transition from the IPMI interface to the network interface. So, if the fingerprint obtained via IPMI does not match the fingerprint of the certificate presented via TLS handshaking, the client can quickly determine it's not interacting with the same device when it made that transition.
|
|
|
Post by igork on May 5, 2021 17:47:44 GMT
OK. Thank you
|
|