SSL Certificate management proposal.

[Jayanth Othayoth]

On Tue, Jul 31, 2018 at 11:21 PM Ed Tanous <ed.tanous at intel.com> 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.
>
Agree with your concern, but from the security standpoint transmitting
private key over network is not recommended.  Additionally a simplified
method also can be provided for customers who wants that.
> >
> > 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?
Storage method can be varied based on the implementation. Curenlty looking
at 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.
>
Upload process just save the Signed certificate in a  BMC location and
"activation" will replace the curently used certificate in the secured
location and restart all the impacted services.
> >   * 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.
>
As mentioned earlier  curently used certificate will be replaced only after
the successful activation. So there wont be any downtime during CSR
creation process.
> >   * Certificate management operation should be restricted for certain
> >     privilege levels.
>
> Which privilege levels?  This requirement should be more specific.
>
User privilege level need to be discussed more.
> >   * 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.

Agreed.
> >
> >   * 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.
>
Agreed.
> >
> >
> > Note: REST/D-bus details not included here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180801/69cd21d6/attachment.html>