Able to make single https connection based on already replaced ca certificate.

[zlukwins]

Issue is about single https connection (e.g. RedFish call) based on user certificate correlated with already replaced CA certificate works but it shouldn't. Flows looks like:

• generate two pairs CA and user certificates
• install first CA certificate using RedFish API
• confirm making https connections based on first user certificates works (e.g. using curl)
• replace first CA with the second one using RedFish API
• check if making https connections based on first user certificate doesn't work.

Last step fails - bmcweb allows making connection using first/old user certificate. Subsequent making connection try fails.

[edtanous]

The below is speculation, but I suspect what you're seeing is not a bug, but a feature that you don't realize curl has.

Curl has connection keepalive enabled by default, which is likely keeping you logged in even though you think that it's a "new" connection to the BMC. You can verify this by running curl with the "-v" argument, and you will see the second call has something like this near the top.

Connection #0 to host left intact

Can you please retry your test using the --no-keepalive flag in curl?

We can certainly debate shutting down connections when a root certificate changes, but I suspect doing that will be more difficult, as we have to actually gracefully shut down the sockets, or track certificates and invalidate only the connections using that certificate.

[mjusza]

I checked --no-keepalive flag in curl and it does not help here. Changing CA during sending many requests within one curl connection does not prevent from getting data using that flag. Only -H "Connection: close" header option helps and prevents using invalid user certificates.

I believe the real problem is keeping session authorized with user certificate signed with previous CA when new CA is currently in use.

[alext-w]

On a broader topic of whether we should break the connection upon the CA cert update.

FWIW, I'd vote for closing the sessions that use the old CA cert - if it was replaced while still being technically valid, chances are the key associated with it was compromised, so any client certs signed by it are potentially rogue.

Of course sane admins would normally replace their CA certs while they're still valid, some [short] time before they expire, so the above is probably a minority, but I don’t think we have any means of discerning those two situations.

Do we? If we indeed don't - do you think it would be worth it/possible to add an additional flag to the CA cert replacement request meaning "drop all sessions using this CA cert"? If the flag is set in the request, we drop sessions, if it's not - we skip that.

[zkurzyns]

Fix proposition for this issue: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/26111

[zlukwins]

I believe we have two issues here right now. First one is about the case described in the first post. And it is about bmcweb allows to make a connection (but only one) based on user certificate related to the CA certificate already replaced just after CA certificate replacement happened. Next connection making try doesn't work - bmcweb tells it is unauthorized. And fix proposition mentioned by @zkurzyns is related to this issue in fact. Adding '--no-keepalive' flag to the curl's call doesn't fix it. Second issue is about active connections made in the past based on CA cert replaced later.

[zlukwins]

Closing this issue since was fixed - there is no reproduction. But the flavor discussed here as well which was about not closing https connection based on already deleted/replace CA certificate was move to separate issue: #110