<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 23, 2020 at 8:46 PM Ed Tanous <<a href="mailto:ed@tanous.net">ed@tanous.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">First off, if you are finding certificates are expiring in a<br>
production environment, you need to rethink your certificate<br>
replacement strategy.  The BMC cannot be the primary entity in charge<br>
of certificate replacement and revocation, and the fact that this is<br>
happening points to a greater organizational problem than the bmc can<br>
cover.<br>
<br>
One thing to note;  At one point, I had talked through how to<br>
prototype ACME protocol replacement of certificates automatically, so,<br>
given an ACME server on the network, the BMC could essentially<br>
automatically provision itself and keep its certs up to date.  If<br>
someone wanted to run with that, it might reduce some of the pain here<br>
(and be extremely cool).<br>
<br>
On Thu, Jul 23, 2020 at 7:24 AM Joseph Reynolds <<a href="mailto:jrey@linux.ibm.com" target="_blank">jrey@linux.ibm.com</a>> wrote:<br>
><br>
><br>
> 4 Question: If BMCWeb finds an unusable HTTPS site identity certificate,<br>
> it DELETES it and self-generates one.  This has caused problems for<br>
> certificates that are not valid until a future date. In general, what<br>
> certificate management support should we have for BMCWeb?  What is needed?<br>
<br>
This is not how bmcweb was intended to work, and I had explicitly<br>
tested that it doesn't have this behavior (prior to it being moved<br>
over to certificate manager).  The only time it previously would<br>
replace a certificate was if the cert file didn't exist, or was<br>
completely unreadable.  I suspect the right thing here is to bisect<br>
the commit that broke this behavior (I'll bet it's easy to find) and<br>
get a bug filed with the author so they can either fix it or revert<br>
the patch.<br>
<br>
This one smells awfully suspicious: 082f28fd2588fd9fcd9452ad38234ce875319163.<br></blockquote><div><br></div><div>  Ed,</div><div>        <a href="https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/22938">https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/22938</a>  introduced to fix issue <a href="https://github.com/openbmc/bmcweb/issues/91">https://github.com/openbmc/bmcweb/issues/91</a>. <br></div><div>     We should also add check to ignore “X509_V_ERR_CERT_NOT_YET_VALID” to allow user to upload “NOT_YET_VALID” certificate similar to certificate manager verification function.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> ANSWER:<br>
> There were two discussion threads: The BMC’s notion of time of day<br>
> (TOD), and how BMCWeb should handle certificates.<br>
><br>
> Does the BMC have a battery backed TOD clock?  Depends on BMC model.<br>
> Can it validate if it has access to its NTP server (when configured)?<br>
> Does the BMC know if its time was set correctly?<br>
><br>
> How does the BMC know if the BMC has the correct time?  Have a BMC flag<br>
> that says, “Look like the BMC TOD clock is not working.”  Does the BMC<br>
> know if we got a good time from an  NTP server?  Can we read the GPS<br>
> signal?  What is the industry solution?<br>
> Should the BMC store its idea of what date it is?  So it can report if<br>
> the time changes significantly.  Or will this lead to a bigger problem?<br>
> Is it better/simpler to check for TOD = beginning-of-era-1/1/1970?  →<br>
> start an email thread<br>
<br>
The above is all asking the wrong question: "Can we determine if the<br>
certificate is valid?"  This is irrelevant, the question is: "Should<br>
we ever be replacing a user provided certificate with one generated on<br>
the BMC."  The answer previously has been no.  In almost all cases the<br>
user provided certificate, even an expired one, will still be better<br>
than one the BMC self signs.  Between having an invalid certificate<br>
chain, and an invalid date, I'll take the invalid date every time.<br>
<br>
It should be noted, most browsers (in my testing) seem to ignore the<br>
HTTP date header entirely, so the BMC doesn't even need the correct<br>
time to set up a proper encryption channel.<br>
<br>
><br>
> BMCWeb configuration?  Configure option: delete cert and generate<br>
> self-signed -vs- use defective certificate.  What is the purpose of<br>
> deleting the unusable cert?<br>
<br>
This question needs answered.  I suspect this was unintentional, and<br>
someone simply used some bad openssl code to attempt to verify the<br>
cert against the (possibly non existent) chain without realizing this<br>
requirement.<br>
<br>
>  Should “out of date” not be part of the<br>
> “unusable” definition? ⇒ Ideas: 1. If bmcweb finds a usable cert but is<br>
> out of date, that cert can still be used.  2. Leave the defective<br>
> certificate (do not delete it) and log an error.<br>
<br>
A lot of BMCs don't have a dedicated RTC, and rely on other systems<br>
(like the PCH or NTP) to get the correct time.  bmcweb needs to come<br>
up long before the PCH or NTP (both of which are also optional) so as<br>
a general rule, using these for valid time is a non-starter.  I could<br>
see logging an error _if_ you know time is valid, but I'm not sure how<br>
a bmc could know that.<br>
<br>
><br>
> The group consensus was that BMCWeb should treat its HTTPS site identity<br>
> certificate like this:<br>
> 1 certificate is perfectly good - Use the certificate<br>
> 2 certificate is good but expired or not yet valid - Use the certificate<br>
> and log a warning<br>
<br>
Add "and we know time has been set appropriately".  Also, be careful<br>
with not yet valid.  I don't know how openssl chains handle clock skew<br>
between certificate generator and client.  If the BMC has a time<br>
that's 1 minute fast, is the certificate "not yet valid"?<br>
<br>
> 3 certificate is missing or bad format or algorithm too old - Use<br>
> another certificate or self-generate a certificate (and log that action)<br>
<br>
We shouldn't be replacing certificates unless it's completely missing<br>
(ie, we're on a first boot or a factory reset) and wouldn't be<br>
switching certificates on the fly.  If the algorithm is too old, the<br>
user is free to replace it with their own, which is the right<br>
procedure anyway.  We also have no idea if the user has added this<br>
public certificate to their local root store, so replacing it out of<br>
the blue might look like an attack.  Also, we have no idea if the<br>
users' client systems support the new crypto format.  We could be<br>
unintentionally DOSing them if, say, we turn on a new keytype or size<br>
and their clients don't support that key.<br>
<br>
> There are no cases where BMCWeb should delete any certificate.<br>
<br>
I think I know what you mean, but to be clear, we should delete the<br>
old certificates when they're replaced.  We should delete root trust<br>
store certificates when requested, ect.  I don't think we can say "no<br>
cases" here.<br>
</blockquote></div></div>