SSL Certificate management proposal.

[Deepak Kodihalli]

On 31/07/18 11:21 PM, Ed Tanous wrote:
> On 07/31/2018 07:49 AM, Jayanth Othayoth wrote:
>>
>> The workflow for updating a signed certificate on the BMC consists of:
>> 1. Generating a CSR on the BMC
>> 2. Exporting the CSR from the BMC onto the user’s storage device
>> 3. Obtaining a singed certificate corresponding to the CSR from a CA
>> 4. Importing the signed certificate on the BMC
>>
> 
> This workflow is somewhat of a non starter for a lot of organizations 
> and IT departments.  First, it requires that every BMC have its own 
> private key, which isn't always desired.
> Second, it means that you either have to be able to specify all 
> parameters that a user would want to specify about his key (number of 
> bits, EC vs RSA, ect).
> Third, it requires that every BMC be provisioned by the intermediate 
> authority, which can be difficult if keys either have a cost associated 
> with them, or are difficult to acquire.
> 
> I would vote that we should start with the key and certificate upload 
> flows, as they are far simpler to implement, and better understood in 
> practice then try to go after the BMC CSR implementation if it's still 
> required.

We might have to do both (the CSR option if customers prefer the the 
private key never leaves the BMC), but agree with starting with a simple 
certificate and key upload approach. I wanted to discuss the following 
high-level design for the same :

1) OpenBMC Rest/Redfish API to upload certificate and private key, and 
also specify target protocol (see point 2). Synchronous API that lets 
caller know if the upload and installation was successful.
2) Have a json config that lets you know certificate install location 
based on different protocols (these would still be SSL/TLS certificates, 
but based on the protocol, say https or ldap) and/or web-servers being 
used, the certificate may have to be installed at different locations on 
the BMC flash.
3) Rest server copies the certificate to a common location and invokes 
an app via (internal) D-Bus api for certificate activation (lets app 
know the certificate path and the protocol type). The app consumes the 
config from 2).
4) The certificate "activation" would essentially be validating the 
certificate content (via openssl api) and then restarting specific 
systemd units. The app from 3) would perform this, and let the rest 
server know about the status. The app could again be configured based on 
the protocol and the web-server, to determine what service to restart 
(for eg restart nginx).

Regards,
Deepak