Ignore root cert expiration in Server. (v1.1 cherry-pick of PR 26372) #26406
Conversation
Since there is no real way to rotate the root cert for a fabric, even just to update its validity period, enforcing the validity period for it just means making the fabric not work and runs the risk of making devices completely unreachable. Switch to not validating expiration time for a root certificate, while keeping existing behavior for the NotBefore and all other certificate types.
bzbarsky-apple
deleted the
cherrypick-ed8d546b1fa0600963311db590be62486c610cd2
branch
|
It is understood that a disconnection risk, what's the balance between the security justification and connectivity, such as botnet? |
|
@gnought What exact issue are you trying to solve? That said: this is a cert that cannot be rotated, so expiring it can only cause connectivity loss and there is no way to avoid that, because the cert cannot be rotated. |
|
How could we make sure the server is valid and connection is still secure? @bzbarsky-apple |
|
@gnought I'm not sure what you are asking. The root cert is stored by the server. The server itself is validating (or not, after this change) the root cert that it itself is storing. Can you explain what you think is or should be validate and how it makes the connection "secure" or not? |
…6372) (project-chip#26406) Since there is no real way to rotate the root cert for a fabric, even just to update its validity period, enforcing the validity period for it just means making the fabric not work and runs the risk of making devices completely unreachable. Switch to not validating expiration time for a root certificate, while keeping existing behavior for the NotBefore and all other certificate types. cherry-picked from: 4ff8bc7
|
@bzbarsky-apple May I ask few questions? Is there any plan to have a proper rotation mechanism for the fabric operation root cert in the future? In case we won't, should we have the operation cert with no well-defined expiration date? I see in the specification, the validity in the cert example is Another question. Is this update safe to use in v1.0 branch? So that we can patch the v1.0 matter SDK for our coming manufacturing? |
See https://github.com/CHIP-Specifications/connectedhomeip-spec/issues/5210 for adding a way to update the cert to one that matches in all ways except the validity period. But that hasn't happened yet, and at the moment there is no work being done on it. So there is a plan, but no timeline.
That is probably what you should do, yes.
It should be, yes. |
…6372) (project-chip#26406) Since there is no real way to rotate the root cert for a fabric, even just to update its validity period, enforcing the validity period for it just means making the fabric not work and runs the risk of making devices completely unreachable. Switch to not validating expiration time for a root certificate, while keeping existing behavior for the NotBefore and all other certificate types. cherry-picked from: 4ff8bc7
…t-chip#26372) (project-chip#26406)" This reverts commit ba9cc4f.
This is a cherry-pick of #26372 to the v1.1 branch.
Since there is no real way to rotate the root cert for a fabric, even just to update its validity period, enforcing the validity period for it just means making the fabric not work and runs the risk of making devices completely unreachable.
Switch to not validating expiration time for a root certificate, while keeping existing behavior for the NotBefore and all other certificate types.