SSL Certificate management proposal.

[Ed Tanous]

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.

> 
> Additional Requirements:
> 
>   * BMC should store the Signed certificate and private key in a
>     persistent secured storage location..

What does this mean exactly?  Encrypted disk backed by hardware 
security?  Is it just implying file system permissions?

>   * Activate process shall validate the new certificate against the
>     private key and information in the CSR.
You don't really define what the "activate process" is in this context. 
I suspect you're talking about a process designed for cert upload, but 
I'm not really sure given the context.

>   * Successful certificate activation shall replace the existing
>     certificate and private key.
>   * A new CSR generate request will overwrite the previous CSR. User
>     should take caution to not repeat CSR requests to prevent
>     overwriting pending CSRs.

If you're going after a CSR flow, I don't think you can do this to a 
user.  Having a CSR immediately overwrite would mean that it invalidated 
the old one, and you have a period of time where your BMC interfaces are 
down while you request a new certificate from your intermediate authority.

>   * Certificate management operation should be restricted for certain
>     privilege levels.

Which privilege levels?  This requirement should be more specific.

>   * As part of Boot process,  a new self-signed certificate is generated if:
> 
>   * No CA signed certificate is present or corrupted.
>   * A self-signed certificate is not present or corrupted.

Agree with these two, and I believe this is how all the web clients 
currently work.

>   * The certificate has expired.
Disagree with this one.  If the certificate has expired AND it was a 
self signed cert, it could be replaced, but it doesn't happen much in 
practice, as self signed certs usually have a very long validity period 
(10 years or more).
If a certificate that a user has uploaded expired, it should be left 
expired until the user decides to replace it.  We shouldn't be changing 
keys and certificates seemingly randomly or automatically.
There's also a question of how you determine if a certificate is 
"expired".  There are no guarantees that the BMC clock is accurate at 
all times, and the potential race conditions in supporting this outweigh 
the benefit.

> 
>   * Validity of the certificate must be ensured by the user or client
>     application by periodically checking the expiry date. Certificate
>     management feature may be be enhanced in future to generate events
>     when the certificate is about to expire.
> 
>   * Existing REST session will be tossed during certificate activate
>     process.
I assume you mean restarted?  I would word this requirement a little 
differently.

* While the web services may restart to begin using the new certificate, 
it shall not interrupt any update flows, and return codes returned by 
all interfaces shall be correct.

> 
> 
> Note: REST/D-bus details not included here.