"step-ca does not currently support sending certificate bundles of more than two certificates to clients"

[rwv37]

In the "Example: Intermediate CA Chain" section of "Announcing X.509 Certificate Flexibility, there's a bit saying (emphasis mine):

In this scenario, we'll create our PKI entirely offline, with the step command. We can always use the resulting credentials to establish an online CA later—however, step-ca does not currently support sending certificate bundles of more than two certificates to clients, so you'd need to do some extra work to support this in your setup.

This was written almost a year ago, so my first question is: Is it still true that step-ca doesn't support this?

Assuming that it's still true that step-ca doesn't support this, could I please get a little elaboration on the practical consequences, and what "extra work to support this" might entail?

So, for example, if I were to set up the PKI this way, does that mean step-ca would essentially be completely useless for it, and I would have to use some other (non-step-ca) server to provide all the services that step-ca otherwise would? Or perhaps some specific functionality (which?) wouldn't work, like "You won't be able to use step bootstrap" or "ACME won't work"?

Thanks in advance.

[rwv37]

I recently turned on an ACME provisioner, and noticed that the "full chain" resulting from a request to it includes only the leaf and the intermediate, not the root (the client is complaining about this, though still functioning). Is that perhaps a symptom of this?

[tashian]

There are four challenges in any PKI design:

• Root distribution
• Enrollment
• Renewal
• Revocation

Distributing the root certificate to clients is a separate process because it only needs to be done once per client. It is a trust bootstrapping process, which is why we suggest using step ca bootstrap to set up clients. With step ca bootstrap, you supply the root CA fingerprint to authenticate the root certificate that is being downloaded from the CA. Once all of your clients trust the root CA, they only need the intermediate and leaf when enrolling. (And, the root CA certificate allows clients to trust TLS connections with the CA itself.)

This two-tiered design allows you to store the root CA private key completely offline, because once you've used it to sign an intermediate CA certificate, it's not regularly needed anymore. And, if the online intermediate is ever compromised, you can revoke it and issue a new one without having to rotate the root on all of your clients. This is why the intermediate and leaf are sent together as a bundle during certificate enrollment and renewal.

I hope this helps.

[hslatman]

That is the expected behavior. Relying parties have their own roots configured, so roots are not required in the chain, and must even be ignored at validation time. I can imagine it can be confusing with it being named "full chain", but you'll see this term being used as such in multiple tools, e.g. certbot.

[tashian]

Yes, this limitation is still present.

step-ca sends down the certificate it used to sign the leaf, and the leaf.

This is because step-ca is designed to favor a simple deployment of a scalable two-tiered X.509 PKI, with one Root CA and one Intermediate CA that issues leaf certificates.