Certificate generation: SAN not present with latest step CLI

[frigus02]

Go 1.15 expects certificates to have a SAN (see https://github.com/golang/go/issues/39568). This means also the latest Kubernetes requires certificates to have a SAN.

PR #809 added the --san option to all step command in this documentation.

With the latesy step CLI (currently version 0.15.3), this option is ignored for intermediate and root certificates. See also https://github.com/smallstep/cli/issues/386.

One possible solution is to use a custom certificate template with step, which includes SANs. This would mean commands would change like this:

- step certificate create identity.linkerd.cluster.local ca.crt ca.key \
-   --profile root-ca --no-password --insecure --san identity.linkerd.cluster.local
+ cat >root.tpl <<EOF
+ {
+     "subject": {{ toJson .Subject }},
+     "issuer": {{ toJson .Subject }},
+     "sans": {{ toJson .SANs }},
+     "keyUsage": ["certSign", "crlSign"],
+     "basicConstraints": {
+         "isCA": true,
+         "maxPathLen": 1
+     }
+ }
+ EOF
+ step certificate create identity.linkerd.cluster.local ca.crt ca.key \
+   --template root.tpl --no-password --insecure --san identity.linkerd.cluster.local

It seems this would make the commands quite a bit harder to understand. Can anyone think of another solution?

[Pothulapati]

Can confirm that this works when used with templates. There are multiple places where we use step and it has to be updated everywhere like https://github.com/linkerd/website/pull/809/files

@alpeb @adleong Should we use this (so that we can use the latest versions of step) or pin to specific older version where --san worked directly?

[msvechla]

I ran into the exact same issues and ended up here.

I think either editing the docs to use the command provided above or using another tool to generate the certificates in the documentation would make sense. Otherwise more and more linkerd users will run into this.

Pinning the docs to an older version seems like a bad choice, both UX and security wise.

[adleong]

Pinning to an older version of step which supports the --san flag feels more ergonomic than using a custom template. Are there any downsides to pinning to a previous version?

[adleong]

I'd go even farther and say that even if we want to use the current latest version of step, we should still pin to that version. This prevents the behavior from changing out from under us and lets us upgrade the pinned version at our own pace.

[msvechla]

I agree, from a maintenance perspective it definitely makes sense to add the version for which the documentation is intended/tested.

It probably makes sense to wait for the outcome of smallstep/cli#386.

[Pothulapati]

Based on the latest comment from step folks, I creatd https://github.com/smallstep/cli/issues/386#issuecomment-726325415 to track this as a higher level issue.

@msvechla @frigus02 @adleong Feel free to add any feedback!

@frigus02 Thank you so much for all your help on this! :)

[frigus02]

No worries. Thanks for looking into this.

What does this mean for this documentation issue? Should we leave it until you found a solution? Until this is solved, should we add a note to the various pages in the docs, pinning the step CLI to version 1.4? If so, I'd be happy to prepare a PR.