How to protect from bootstrap?

[Daniel-online]

Hi! I'm new to step ca, but I'm having some problem trying to understand the bootstrap option.

According to this, bootstrap allows me to connect and command my certification authority remotely by using the bootstrap option and according to this video I can even get tokens throught that.

However, here is the problem: to allow my clients to stablish an SSL connection with the CA, I need to provide to them the root certificate, but, if they have the root certificate, could'nt they get the fingerprint from the certificate and bootstrap into my CA, allowing them to get tokens without any control?

If yes, how can I counter that? Is there anyway to disable the bootstrap option, or to oblige an password upon anyone trying to use it?

If no, does that mean that I should'nt use step ca on an public IP?

OBS: I'm planning to use an gmail bot as a authentication mechanism

[maraino]

Hi @Daniel-online, by default all the endpoints are public, that does not mean that they are accessible by everyone. The /provisioners endpoint is probably the most sensible one because you can see the configuration of a CA.

The information in that endpoint should be safe, meaning that only "public" information should be displayed. There's a minor exception though, on an OIDC provisioner you can see the clientSecret. But that is generally ok, as it should be your IdP the one restricting the login to only clients in your organization. If that's not the case you can always use the property "domains" to control it.

If you're using a JWK provisioner, the private key is always encrypted, so only the people that know the password to decrypt it can use it. You can even remove it from the ca.json, but you need to provide another way to sign tokens.

/root/<fingerprint> or /roots will give you the root certificate but that's also public information.

To summarize, yes, by default all endpoints are public, but only users that can generate a valid token can get a certificate. And each provisioner has at least a way to limit access to things belonging to your organization, so only they can generate valid tokens.

---

And there are always other ways to protect the CA, using firewalls or proxies are probably the most typical. A non-trivial one would be to use TLS-over-mTLS, but I would not recommend you to go through that route unless it's critical.

You can always have multiple CAs on internal networks to give certificates to multiple hosts using multiple intermediate certificates. Or using VPNs, ...

---

OBS: I'm planning to use an gmail bot as a authentication mechanism

I guess you mean to use OIDC with a google account, if you have a custom domain myorg.com the solution is to add "domains": ["myorg.com"] in the provisioner configuration. You can also use GCP to create client credentials that only a list of users can login to.

If you don't have a way to limit the users, then you should use a different provisioner.

[Daniel-online]

1 - Thanks for the answer!

2 - So let me see if I got it: you need to have the private key and the password for it to get an certificate and so on... So if my identity provider can protect the said password/key it doens't matter if anyone bootstrap into my CA, they will not be able to get an JWT nor sign a certificate.

So, if I can assure that the password to decrypt the private key of the provisioner, I'm safe, right?

3 - By the way:

I guess you mean to use OIDC...

Actually, I was thinking about doing something similar to this, but with gmail.

[maraino]

Yes, you should be safe.

The JWK private key is encrypted and available in the /provisioners endpoint, we only use it to make signing tokens with step ca token or related commands easy. But as you're building something around it, you also have the option to store it in a different place and don't even have it in the ca.json (and /provisioners). The public key however is required, because the CA uses it to verify the token signature.

With custom code, you can even have the private key in a YubiKey, an HSM, or even in a cloud KMS if you want :)

[Daniel-online]

Hi! Sorry for being late, and thanks for the answer!
I am probably going to mark it as answer, however, I wanted to make one final question: what about DDoS? Couldn't an attacker bootstrap his machine to my server and try to send thousands of commands? Even if he doens't has the secret, he can still saturate the server with requirements.

Is there anyway I can block an IP/MAC address from bootstraping?

[maraino]

Is there anyway I can block an IP/MAC address from bootstraping?

You should use a firewall or a proxy server to do that.