Re: BMCWeb policy for HTTPS site identity certificate

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]


Joseph Reynolds <jrey@linux.ibm.com> wrote:
    > Problem:
    > BMCWeb apparently treats certificates that are either expired or not valid
    > until a future date as unusable (investigation needed).  And BMCWeb deletes
    > unusable certificates.  This can confuse the administrator, especially
    > considering the BMC's time-of-day clock may not be set as expected.

    > Proposal:
    > What certificate management policy should BMCWeb use?  Here is an initial
    > proposal:
    > 1. certificate is perfectly good - Use the certificate.

okay.

    > 2. certificate is good but expired or not yet valid - Use the certificate and
    > log a warning.

very good.

    > 3. certificate is missing or bad format or algorithm too old - Use another
    > certificate or self-generate a certificate (and log that action).
    > In no case should BMCWeb should delete any certificate.

I think that there is a problem in 3.

"certificate is missing" is pretty much unambiguous.
"bad format" depends a bit upon evolution of libraries.
In particular, a new version of libssl might support some new algorithm, and
then should the firmware be rolled back, it will "bad format".

So I suggest that the certificate+keypair is never deleted, but may be renamed.
I think that we could have a debate about getting telemetry about bad
certificates back via HTTP.

I think that there are some operational considerations relating to
determining root cause that may trump some security issues relating to
telling bad actors whether they have succeeded in damaging a certificate.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]