Parameter to reduce 10 year lifetime on CA root and intermediates?

[dnwe]

What would you like to be added

A parameter on the GenerateRootCertificate and GenerateIntermediateCertificate APIs to override the hardcoded 10 year validity

https://github.com/smallstep/certificates/blob/v0.15.6/pki/pki.go#L269-L273

Why this is needed

As per the docs https://github.com/smallstep/certificates/blob/master/docs/defaults.md#root-certificate 10 years is just a reasonable default when you don't have immediate plans/procedures in place for automated re-generation and rotation. However, it would be useful if these lifetimes could be overwritten in the Go API so that we could (e.g.,) issue a 5 year root and 2 year intermediates and exercise our automated rotation more regularly to grow confidence in it

[maraino]

Hi @dnwe are using this package in your own application? Currently these values are hardcoded because this package contains the core functionality used by step ca init.

[dnwe]

@maraino yes we're essentially just driving the API in exactly the same way as the cli to bootstrap a CA, but directly from Go code rather than exec'ing the cli binary

Essentially I was wondering if we could parameterise the lifetime here and then a followup PR could expose the lifetime as a configuration option on step ca init if that makes sense?

[mmalone]

tl;dr:

1. I don't like the idea of a --not-after flag on step ca init.
2. I do like the idea of --intermediate-cert and --intermediate-key flags on step ca init.
3. I also like the idea of --root-template and --intermediate-template flags on step ca init.

I'm +1 on a PR that does 2 and/or 3.

The conflicting requirement here is API simplicity. More specifically, we'd like to avoid an explosion of flags on step ca init to control the details of the various subprocesses that occur under the hood of that command. In this case the situation is worse since a --not-after flag would be ambiguous: are you trying to set the expiry for the root or intermediate? So, immediately, we'd probably need two new flags: --root-not-after and --intermediate-not-after. This doesn't scale.

I have a strong preference for mechanisms that allow you to decompose subprocesses. For example, the --root and --key flags to step ca init allow you to create a root certificate using step certificate create (or openssl, or something else) and pass that existing root/key into step ca init.

Unfortunately, we don't have flags to pass the intermediate cert/key into step ca init. One option I'd be open to is to add those flags. I have a bunch of scripts that work around this problem by running step ca init then immediately replacing the intermediate with a new one that has the features I want.

Implementation notes:

1. The --root / --key flags probably should have been --root-cert and --root-key to make room for the possibility of --intermediate-cert and --intermediate-key. We may want to rename --root/--key and make the old names (hidden/undocumented) aliases.
2. We only need the root key to sign an intermediate cert. So, if you pass in --root-cert, --intermediate-cert, and --intermediate-key, we don't need --root-key. It should be optional in that case.

Another option is to add --root-template and --intermediate-template flags to step ca init. This would be harder to use than an explicit --not-after flag, but it's a big hammer that would support a ton of different use cases.

[maraino]

@dnwe To programmatically create a PKI, I would recommend you to use directly the x509util package in go.step.sm/crypto. Look a this code from some tests that creates a root, intermediate and signs a leaf with an intermediate: https://github.com/smallstep/certificates/blob/96de4e6ec8fe98c930ae70c91f888fe1f3a52861/cas/stepcas/stepcas_test.go#L171-L173 https://github.com/smallstep/certificates/blob/96de4e6ec8fe98c930ae70c91f888fe1f3a52861/cas/stepcas/stepcas_test.go#L49-L76

I guess I can probably add some helper methods to x509util to make things still a little easier like create the *x509.Certificate more directly, instead of creating first the *x509.CertificateRequest, then using x509util.NewCertificate to templatize it.