We've been relying on the puppet CA more and more for service-level certificates, and it is been showing its limitations.
- no ECDSA keys
- no wildcard SANs allowed
- no control over certificate validity (pegged at 5 years)
- no IP-based SANs (needed for mcrouter, which is why I open this as a subtask of setting up mcrouter in production)
- No way to receive the signed certificate from the API
we had to create our own scripts (that fiddle with puppet internals) for overcoming some of those limitations, and we even created a tool (called cergen) in order to have an easy way to manage certificate generation in a declarative way.
I think this approach, that allowed us to scale up our use of internal certificates fast and is also well integrated with puppet, is showing its limits. We should install a PKI management software for having our internal root CA, and probably have the puppet CA be an intermediate authority for that root CA. This CA should probably sign and manage all application-level certs, or delegate to intermediate CAs the management of specific domains (like kubernetes).
Ideally, this PKI management software should be:
- widely used and well supported
- flexible enough to be able to accomodate most of our needs
- Allow to define both short-term and long-term certificates
- Have support for CRLs
- ideally be able to manage our externally-requested certificates as well with a single tool
- be easy to integrate into puppet configuration management
This list of requirements came up in a quick chat with @Vgutierrez this morning, and it seems to me that cfssl ticks all the boxes we might need. I'm not 100% sure it makes sense to consider this a blocker for deploying mcrouter (we can probably get away with generating certificates with a dedicated CA for now), but I wouldn't exclude it could also make sense to build this once and for all.