Rotating Intermediate Certificates and CRL Issuing

[ashceryth]

Hello,

I'm currently testing step-ca and I think it's a great tool. I want to migrate my existing CA setup to step-ca because it seems to cover all the features I want.

I do value the idea of short lived certificates and passive revocation and want to use it wherever possible. However, I think there will always be some leaf certificates whose issuance can't really be automated and therefore the need for longer lifetimes. Thus it makes sense to use active revocation as well. step-ca's built-in CRL server seems to be the solution for this.

While planning my new setup I was also thinking about lifecycle management and rotating CA certificates. Unfortunately, there is something that gives me a headache when it comes to rotating CA certificates and the issuance of the CRL. If I understand RFC 5280 correctly, the CRL has to be signed by the same issuer as the certificates issuer (otherwise the cRLIssuer field must be present alongside the cRLDistribituionPoint). I'm not sure my interpretation is correct, though. So, imagine the following setup:

┌───────────────┐           ┌──────────────────┐      ┌───────────────┐
│               │           │                  │      │               │
│     Root      ├──────────►│  Intermediate 1  ├─────►│ Leaf Cert A   │
│               ├─────┐     │                  │      │               │
└───────────────┘     │     └──────────────────┘      └───────────────┘
                      │                                                
                      │     ┌──────────────────┐      ┌───────────────┐
                      │     │                  │      │               │
                      └────►│  Intermediate 2  ├─────►│ Leaf Cert B   │
                            │                  │      │               │
                            └──────────────────┘      └───────────────┘

Intermediate 2 has been created because Intermediate 1 will reach end of its lifetime soon. Leaf Cert A is still valid (expires before the Intermediate 1 expiration date). Intermediate 1 is no longer signing new certificates because Intermediate 2 is in operation (active intermediate certificate for step-ca). Leaf Cert B has been signed by Intermediate 2. Now, I revoke Leaf Cert A. Leaf Cert A should be listed on the CRL. The CRL will be signed by Intermediate 2, which is not the issuer of Leaf Cert A. I assume this may cause issues (especially when the subjects of the Intermediates differ) or am I missing something?

To circumvent this issue I thought about running multiple step-ca instances behind a reverse proxy for each generation of Intermediate CA, each with its own CRL DistributionPoint. This way the Distribution Point will be tied to the Intermediate Certificate. On the reverse proxy API endpoints for step-ca will always point to the "active" Intermediate. Revocation on the "old" CA be done with step-cli directly (not via reverse proxy).

However, this seems to cause another issue if I want to keep the ACME accounts when moving to a new "active" Intermediate CA. I guess, this can be solved by copying the badger DB. But the database also contains information about the certificates signed by the "old" Intermediate CA which are not needed anymore. I would be nice to start with a "clean" DB only with the needed accounts. Not sure how to solve this, as I don't want to fiddle around with the DB itself.

So, what's the best way to handle this?

A little side note: The "Consider Active Revocation" chapter in the Production Considerations guide in the docs confused me, because it suggests that the Intermediate CA can sign it's own CRL. I thought the Root CA would have to sign the CRL for any Intermediate CA. What am I missing here?

Thanks!

[tashian]

I think there may be an issue with our documentation here. step-ca doesn't have access to the root CA private key, so it cannot sign a CRL associated with the intermediate CA. It can only sign a CRL for leaf certificates.

It's also worth mentioning that you don't need step-ca to host your CRL. You could roll it by hand and host it on a static website. But, it does need to be rotated regularly.

[ashceryth]

Thank you very much for your reply!

Doing it manually would be possible, of course. But how can I generate the CRL if step-ca doesn't host it? I didn't see a command for that. I guess I have to extract the needed information from the database myself then and generate the CRL with something like openssl, correct?

I'm still wondering if it possible to use step-ca's internal CRL feature when you're planning to rotate intermediate CAs from time to time. The Production Considerations guide tells me to backup the old intermediate CA certificate/key and let the root CA sign a new one. How do I then revoke certificates signed by the previous intermediate CA? I think I can use step ca revoke in offline mode, but where does it save the information then? The old intermediate does not have it's own db.

Will the previously (before intermediate rotation) revoked certificates (within their validity period) still land on the the CRL of the new generation of the intermediate CA, because the information is still in the database? Or does step-ca check for the issuer in the db and does only generate the CRL for certs signed by the new CA certifcate? (I haven't tested that yet)

Thanks!

[tashian]

Hi @ashceryth,

In our open source server, the step ca revoke command simply blocks renewal of the certificate with the given serial number, and I think it would add that serial number to the CRL, if that's enabled. It sounds like you would need to use another tool to bridge the gap and create the CRL in the case where you have multiple intermediates. I believe each CA would have its own CRL endpoint.

step-ca's CRL feature is a community-contributed feature that we don't have the capacity to support or maintain. I want to suggest that you check out our Pro version of step-ca. It's a drop in replacement for step-ca that offers more active revocation and high availability features than our open source version. And, it comes with access to commercial support from Smallstep. You can schedule time with us here. We'd love to learn more about your setup and see how we can help.

Carl

[ashceryth]

Hi Carl,

Thanks for clarification! I will have to dig into that. It's just for homelab use.

Yes, each CA should have it's own CDP and CRL. Probably it's easier to extract the data using the mysql or pg backend. I think the discussion in #206 is a good starting point.

Thanks!