Configuring a longer pathlen for certificate chains

[kirill-kostenetskyi]

Hi there!
Our product needs certificates issued as a four-level chain and we chose step-ca as CA which seems should do the job for us.
We have not a lot of experience in the certification area, just a basic understanding. Let me know if we understand something in the wrong way, please.
We setup step-ca server and then we use this sort of commands to create the chain:

1. step ca certificate --ca-url https://33.333.333.333:443 account account.crt account.key
   using JWK provider
2. Then we use x5c provisioner to create the new certificate based on the previous:
   step ca certificate --ca-url https://33.333.333.333:443 session account_2.crt account_2.key --provisioner=x5c@dev --x5c-cert=account.crt --x5c-key=account.key
3. Then we use x5c provisioner again to create the next certificate level:
   step ca certificate --ca-url https://33.333.333.333:443 session account_3.crt account_3.key --provisioner=x5c@prod --x5c-cert=account_2.crt --x5c-key=account_2.key

So after that, we have at least three certificates (and another two inside step-ca server). Here are the questions:

1. How can we validate that account_3.crt was issued by account_2.crt or account_2.crt was issued by account.crt ? Does step has any functions to do that?
2. Does it store them and keeps records?
3. Does step the good choice for our purposes?

Could somebody please help us with answers?

[dopey]

Hey @kirill-kostenetskyi, glad you're trying out step for this. I think there's a couple misunderstandings about how the CA works and how certificates are signed, so let me try to clear those up.

When step ca init is run you get a root and intermediate certificate. When you start up step-ca every new certificate that is signed is signed by that intermediate certificate. Run step certificate inspect against any of your account_2.crt or account_3.crt and you'll see that they're signed by the intermediate, not another downstream cert.

A provisioner is a way to authenticate to the authority, rather than a way to select the signing CA. So when you use a JWK provisioner you authenticate via password. When you use a X5c certificate you authenticate via an x509 certificate previously issued by the CA. But each of the new certificates that you generate will be signed by the original intermediate.

Now, you say that for your product you need a chain that is 4 certificates long. This possible with step-ca but it’s not the default behavior. What you'll want to do is generate a root certificate using the step cli. By default, the root certificate generated by step ca init generates a root certificate with a max pathlen of 1, meaning that there can only be one intermediate certificate in the chain (between root and leaf). You will want a pathlen of 2. Here's an example template you could use:

{
    "subject": {{ toJson .Subject }},
    "issuer": {{ toJson .Subject }},
    "keyUsage": ["certSign", "crlSign"],
    "basicConstraints": {
        "isCA": true,
        "maxPathLen": 2
    }
}

Using this template you would run step certificate create --template root.tpl root_ca my-new-root-subject root.crt root.key.
Then you would create your first intermediate. By default the intermediate created by step ca init has a pathlen of 0 (does not allow any more intermediates in the chain), so you'll need to create one yourself using a new template.

Here's an example:

// intermediate1.tpl
{
    "subject": {{ toJson .Subject }},
    "keyUsage": ["certSign", "crlSign"],
    "basicConstraints": {
        "isCA": true,
        "maxPathLen": 1
    }
}

step certificate create --template intermediate1.tpl --ca root.crt --ca-key root.key <subject> intermediate1.crt intermediate2.crt

Next you'll want to create your second intermediate:

step certificate create --profile intermediate_ca --ca intermediate1.crt --ca-key intermediate1.key <subject> intermediate2.crt intermediate2.key

Next, bundle intermediate 1 and 2 into a single file, with 2 being on top of 1:

step certificate bundle intermediate2.crt intermediate1.crt intermediate_bundle.crt

Finally, you'll need to update your `ca.json`:

{
"root": "",
"crt": "",
"key": "",
}

Now, start up step-ca and when you create certificate using any provisioner they will be signed by intermediate2 and you will have a path length of 4 certificates.

[dopey]

Another note, to verify a certificate using step you can do step certificate verify <cert_file or hostname>. The certificates from your 4pathlen CA will have 3 certificates inside of them. leaf -> intermediate2 -> intermediate1. And then to verify them you'd do step certificate verify new-cert --root root.crt.

[dopey]

• Does it store them and keeps records?

Yes, but accessing those records can be difficult. The open source database is a key value byte store which means that you can't do sql style lookups. We're releasing a managed CA in the next few weeks which does have a certificate observability feature (allowing you to view certificates, lineage, renewal status) in the UI. It can connect to a CA that you run yourself locally, or we can run the CA for you. If certificate observability is interesting to you, I would encourage you to try it out once we release it.

• Does step the good choice for our purposes?

Maybe :) It's hard to say without knowing more about your use case. step-ca is a highly configurable online certificate authority. If you're looking to automate your TLS or even just manage it better, step-ca is built to help with that.

[kirill-kostenetskyi]

@dopey Thanks a lot for your time and so detailed answer!
Your explanation is pretty clear!

Could you help us with another related question, please?
I am not sure step-ca can do that. We need something like centralized CA to which we can touch from a few APIs. Each API will have its 3rd level certificate, and we would like to create a 4th level certificate using CA but based on provided by API 3rd level certificate.

A detailed example:

1. We have two APIs: Alice and Bob
2. We have one CA server with root and intermediate level certificates (so-called 1st and 2nd level certificates)
3. Alice and Bob APIs have their 3rd level certificates (both has their own) based on 2nd level certificate from CA server.
4. Alice and Bob sometimes need short live 4th level certificates based on their 3rd level. So, they contact the CA server and requesting a new 4th level certificate using the private key or some preconfigured provisioner.
5. Alice and Bob also want to verify their 4th level certificate from time to time using the CA server.

Is that scenario possible with step-ca? If not, probably you could suggest any other solutions for such cases?

[maraino]

Hi @kirill-kostenetskyi, this is possible combining step-ca and step but it sounds weird, what is the use case?

In any case, a step-ca provisioner can be configured to sign intermediate certificates, configuring a provisioner with the right template, and having maxPathLen set to 2 in the 2nd level certificate. You can use 2 different provisioners if you need to define for example a different subject for Alice and Bob. Then with that 3rd level intermediate, Alice and Bob can use step certificate create or step certificate sign to sign in their computers new leaf certificates.

A more common solution would be to have a custom step-ca for Alice and another for Bob each one configured with their 3rd level intermediate.

[dopey]

@kirill-kostenetskyi When you use the term "based on" (e.g., 4th level certificates based on 3rd level) do you mean that the 4th level certificates need to be signed by the 3rd level certificates or that the 4th level certificate needs to have characteristics that are affected by the 3rd level? It is uncommon (i've never heard of it) for a server certificate (3rd level in your example) to be used as both a certificate to identify the server and as a signing certificate for downstream certificates.

[kirill-kostenetskyi]

@dopey, @maraino Appreciate a lot for your detailed answers, that's really helpful for us!

@dopey I mean that the 4th level certificates need to be signed by the 3rd level certificates.

@maraino let me try to explain it in more detail:
In our case, instead of Alice and Bob, there will be thousands of clients. We want to provide the ability to check their certificates in one place for Alice and Bob and other clients. At the same time, we want to own the root certificate as an owner of the whole product. That way we (the whole product owner) can always revoke the certificate at a higher level (revoke access for Alice / Bob or any other client).
We tried to create different provisioners for Alice and Bob. It works. We did it like that:

step ca provisioner add alice@protex --type JWK --create --password-file /etc/step-ca/password.txt --ca-config /etc/step-ca/config/ca.json
step ca certificate --ca-url https://127.0.0.1:443 --kty RSA alice-session alice-session.crt alice-session.key
step ca certificate --ca-url https://127.0.0.1:443 --kty RSA bob-session bob-session.crt bob-session.key

But we haven't found a way to validate the highest level (4th level) certificate with the selected provisioner. Is it possible to do this?

If yes, what is the maximum number of provisioners we can create on one CA server? In our case, we are talking about tens of thousands of clients like Alice and Bob. Will, it works well?

Thanks a lot for your answer!

[dopey]

@dopey I mean that the 4th level certificates need to be signed by the 3rd level certificates.

In my experience, certificates that are used to identify an end entity are not used to sign new certificates. So, it's uncommon to generate a public/private key pair for your 3rd level that you use to identify that client and then also use that private key to sign new keys. That's not to say that you can't do this, but it's unconventional.

Let me propose a small example along with our advice on how we would probably structure our PKI for that example. Suppose I own a company that has 100 customers or clients and I want to manage their PKI. I would generate a separate root certificate for each company. I would generate intermediates for each customer as well. Then each customer can use their intermediate to either generate new intermediates or generate leaf certificates directly. Each one of these 100 PKIs would have to be a separate instance of step-ca. We have a managed certificate manager product -- where we manage a certificate authority for you -- , and that's essentially (more or less) what we do for our customers.

But we haven't found a way to validate the highest level (4th level) certificate with the selected provisioner. Is it possible to do this?

I'm not sure what you mean by this. You don't validate certificates with a provisioner. You validate a certificate by having the root certificate and the complete certificate chain and validating each part of the chain.

If yes, what is the maximum number of provisioners we can create on one CA server? In our case, we are talking about tens of thousands of clients like Alice and Bob. Will, it works well?

The maximum number of provisioners is how many you can store in a file and then in memory when the CA starts up. But if you're using tens of thousands of provisioners then you're probably modeling something incorrectly. Provisioners are used to authenticate to the CA to sign certificates. You shouldn't have tens of thousands of different ways to authenticate to your CA. At most you'll probably have 5 or 6. If you have a CA per customer, then that customer probably needs 1 or 2 ways to authenticate to the CA. They may go on to create Tens of thousands of certificates using those 1 or 2 provisioners. That would be a correct usage given our model.

[maraino]

There's not an explicit maximum number of provisioners, but we've never tested it with thousands. Let us know if you find some kind of limit. You can also split the provisioners into multiple CAs each of them using different intermediates from the same root. Each user just needs to bootstrap once from the right --ca-url. You can also set the flag --provisioner alice@protex to get the provisioner you want instead of thousands. Or you can even configure that in $(step path)/config/defaults.json if a user is always using the same, same with --kty or any other flag.

What exactly do you mean if there's a way to validate the 4th level certificate?

• You can validate it against the root, if the CA is properly configured the 4th level certificate should contain the 3rd and 2nd intermediates appended. You can use step certificate verify --roots root_ca.crt alice.crt to validate it.
• You can check that a certificate is coming from a specific provisioner inspecting it and looking at the X509v3 Step Provisioner extension (1.3.6.1.4.1.37476.9000.64.1). It looks something like this:

X509v3 Step Provisioner:
    Type: JWK
    Name: alice@protex
    CredentialID: cliWWz213Ij-ZDLp_I6v9Deu4L4xmN_1MFXop_mEeqM

[kirill-kostenetskyi]

@dopey @maraino
Thank you for your detailed answers. Now it became clear to me how it works.

It seems that step-ca is not suitable for our needs. I don't want to burden you with the details, but I’ll leave here a complete description of the problem we are solving. Maybe you could share any thoughts.
We solve the problem of telephone fraud, named "phone number spoofing". The world has protocols (STIR/SHAKEN) that allow anybody to sign any call with a private key and put the link to the certificate inside the transport message. Then, all telephone stations (we call it this way for simplicity) will check the signature of the transport message and validate that the certificate is valid before communicating with the final recipient of the call. That way, the scammer will not have the ability to replace the phone number because he won't have any trusted certificate to pack the transport message back after the phone number replacement. That's described in more detail in this specification.
To do that, they all have to trust one root certificate. But we would like to make them more multi-level. So the 1st level is the root certificate. The 2nd level would be the certificate of some trusted certification center (of which there can be many) issued by the 1st level certificate. The 3rd level would be the telephone station level. With the last 3rd level, it would issue 4th level session certificates (short-live) and sign calls using it. At the same time our company, as root certificate holders, would like to be able to revoke any of the certificates of the 2nd/3rd/4th level. The same is true for 2nd level certificate holders (certification center), that should be able to revoke 3rd level and 4th level certifications.
This is our complete schematic for which we cannot find a ready-made solution. Does this make sense to you?

Thanks!

[maraino]

It's an interesting use case, and step-ca itself cannot handle all cases. As I see each one of those levels should have an instance of step-ca configured with the expected intermediate, or as an alternative an RA configured to talk to the proper CA.

Then step-ca doesn't currently support "active" revocations, meaning CRLs or OCSP, so you will need to build distribute those yourself.

And of course, build the service that validates the certificates just using the root certificate, and take into account the CRK.

@mmalone Do you have any more feedback for this.

[maraino]

As an alternative, our hosted or on-prem solution can be configured with some effort to handle all those CAs.

[mikemaxey]

@kirill-kostenetskyi - Mike Maxey, VP of Product here. We have talked with others about STIR/SHAKEN and discussed a path to supporting a new ACME challenge as defined in the STIR/SHAKEN standard docs. To date, we have not implemented this extension. Please let me know if this is a direction you have budget and interest in pursuing. I'm available at maxey(at)smallstep.com.

[kirill-kostenetskyi]

@maraino thanks a lot for your answers!
@mikemaxey I'll forward this to CTO.
Appreciate your help!