Store primaries root in secondary after intermediate signature #6333
Conversation
There was a problem hiding this comment.
This makes total sense I think.
I'm trying to think if there was a specific reason we made the root active before we got the signing cert but I can't think of one since nothing can use it yet.
The only thing that would be changed that I can think of would be that while a secondary DC is bootstrapping, before this change it would already be able to accept connections from the primary (or another bootstrapped secondary) and validate them even before it's own secondary CA cert is signed.
But that doesn't seem like a big win or issue - signing the CA cert should happen in O(second) of the secondary cluster first coming up and only once for it's whole lifetime so I don't think it's significant that we might possibly reject connections we might have been able to validate for that extra few milliseconds on initial bootstrap - it's likely no workloads even exist in the cluster yet if the servers are only just bootstrapping anyway unless it's an upgrade to an existing cluster that enabled Connect so I think it's reasonable that you have to wait for CA init to complete before connect works!
|
@banks Those were my thoughts exactly. Even if a proxy could validate the cert of the incoming service the other end wouldn't be able to validate the cert in the secondary so the connection would fail anyways. |
This ensures that the intermediate exists within the CA root stored in raft and not just in the CA provider state. This has the very nice benefit of actually outputting the intermediate cert within the ca roots HTTP/RPC endpoints. This change means that if signing the intermediate fails it will not set the root within raft. So far I have not come up with a reason why that is bad. The secondary CA roots watch will pull the root again and go through all the motions. So as soon as getting an intermediate CA works the root will get set.
mkeeler
force-pushed
the
bugfix/store-ca-root-intermediates
branch
from
a837026
to
c97be45
Compare
|
I keep trying to get CI to pass but other unrelated flaky tests are proving to be problematic. |
I am not sure this is the full fix but it seems to help for me.
This ensures that the intermediate exists within the CA root stored in raft and not just in the CA provider state. This has the very nice benefit of actually outputting the intermediate cert within the ca roots HTTP/RPC endpoints.
This change means that if signing the intermediate fails it will not set the root within raft. So far I have not come up with a reason why that is bad. The secondary CA roots watch will pull the root again and go through all the motions. So as soon as getting an intermediate CA works the root will get set.