Redfish: Generating and installing CSR based certificates.

Ratan Gupta ratagupt at linux.vnet.ibm.com
Fri Feb 15 15:24:16 AEDT 2019


Hi Jayanth,

I have some querys

On 14/02/19 7:23 PM, Jayanth Othayoth wrote:
> All,
> Please find the Redflish based CSR ( Certificate Signing Request) 
> generation and installing the certificate in BMC.
> This is based on the latest Redfish spec (Reference: 
> https://www.dmtf.org/sites/default/files/Redfish_2018_Release_3_Overview.pdf) 
> and related documents.
> Included the Gerrit link related to  d-bus interfaces :
>     Review Link: 
> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/16571/
>
> Looking for the inputs  on this  design flow and any additional 
> changes required from the security aspect on managing private keys in 
> the BMC.
>
>   * The user performs the GenerateCSR action ( URIs:
>     /redfish/v1/CertificateService ) with required parameters.
>       o Certificate service provides a d-bus interface to generate CSR .
>           + Certificate manager create Private key and saves the
>             service specific path
>           + Returns the d-bus path for the newly created CSR.
>
I am hoping this design is wrt Redfish, which explains the flow to 
deploy CSR based certificate.

I was little confused about d-bus interface terminology here, I 
understand that in redfish we have certificate service schema which has 
action

GenerateCSR, I am assuming we are talking about the same.

GenerateCSR should not return the d-bus Path however it should return 
the URI of the Certificate Collection where the certificate will be 
installed.

Does the GenerateCSR creates CSR resource which can be modifiable in future?

>       o  Certificate service provides d-bus interface to download CSR
>           +  The user need need wait for the creation of CSR specific
>             d-bus path to download the newly created CSR
>
Does the certificate service schema have the action Download CSR?

I hope that response of GenerateCSR returns the CSR, There should not be 
another redfish call to get the CSR.

>       o  The user takes the CSR file and get it signed by the
>         appropriate authority.
>           +  This step is outside the scope of Redfish.
>   *  The user navigates to the appropriate certificate collection
>       o   Example: if trying to replace the HTTPS certificate for a
>         Manager, navigate to the Manager’s Certificate Collection that
>         is subordinate to the NetworkProtocol/HTTPS object
>   * The user performs a POST on the Certificate Collection with the
>     certificate string in the body
>       o  Use the existing certificate upload d-bus interface.
>   * Certificate manager validates the certificate with the available
>     service specific private keys in the BMC.
>   * After successful validation  pairs the private key used in the
>     first step with the installed certificate.
>
Would the implementation persist the CSR and associated private key for 
verification?

I can understand that we can do the verification of public/private key 
through oprenssl function, but is there a possibility that user can 
change the CSR request(eg change the organization)

and get it signed and upload the certificate, How the implementation 
takes care of it?

Now suppose user creates three CSR request and on the BMC we have three 
associated private keys and once user upload the certificate

would the implementation starts matching the certificate public key with 
all the stored private keys and once it gets matched

then the implementation creates the pairing?

How the certificates would be deleted?
> Assumption:
>
>   * For a service, BMC allows maximum 3 ( ?) CSR requests. Any new
>     request after this will remove the oldest private key information
>     from the BMC.
>   * User has to do a Factory removing  the private key from the system.
>
Regards

Ratan Gupta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190215/471567a0/attachment-0001.htm>


More information about the openbmc mailing list