connect: Improve CA Cross-signing workflow for CA Provider Compatibility
- Dominant language
- Go
- Stars
- 30.1k
- Forks
- 4.6k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 43
Description
This may be done at the same time as re-introducing external CA provider plugins. This is being captured to avoid loosing the intent and context but it not planned immediately. For the time being we _are unlikely to accept pull requests_ on this issue as it needs a more thorough internal design process and sign off than the outline here. Please do comment with context if this is of interest to you though!
## Background
When building out the ACM PCA provider (#6189) we noted that AWS PCA is unable to blindly cross sign external root certs. This is not too surprising and is likely to be the case for many if not most other CAs we integrate with. We relied on this in our original design since Vault can do it and it made things really flexible however it's not necessary and we could support cross signing perfectly well with PCA and other providers if we change our strategy.
Additionally, Secondary datacenter CA process added some complication to the CA workflow which actually already mimics the more standard and compatible workflow most providers could accomodate but we currently only require that workflow in secondary DCs and not when rotating between CA providers in the primary. The fact that providers behave differently in Primary and Secondary DCs adds a lot of complication to them currently although it all works.
## Rough Proposal
Right now we optimize for Provider flexibility - providers can choose whether or not to sign leafs directly with the root certificate in the Primary DC. Secondary DCs always use Intermediates though to avoid needing to transmit Root keys between datacenters and increase availability in partitions.
If we were a little more opinionated and standard we could both simplify the Provider and CA code in Consul, and support full featured integrations with more external Providers (e.g. ACM PCA).
The changes would look something like this:
- All DCs including primary must sign leafs with an intermediate.
- The flow is the same for initializing that intermediate CA in Primary and secondary:
- Generate CSR for secondary CA
- Have it signed by the Root in the primary DC, call this `intermediate-cert`
- Also have the same CSR signed by the _previous_ CA's root (this is a standard CA operation not a special privileged one) and call this `intermediate-cross-signed`
- Install both certs, using the key to sign leafs and return both intermediates with each leaf
- Leaf will validate through both the regular intermediate to the new CA and through the cross-signed intermediate to the old CA on a host that has not yet observed the CA change.
Contributor guide
Assessment
This issue has not been assessed yet.