search

smallstep / certificates

🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.
https://smallstep.com/certificates
Apache License 2.0
6.64k stars 432 forks source link

ACME orders are not tied to a provisioner and can be "finalized" by any ACME provisioner ... #262

Open dopey opened 4 years ago

dopey commented 4 years ago

ACME orders are not tied to a provisioner and can be "finalized" by any ACME provisioner. The result is that the claims from the "finalizing" provisioner will be applied to the end certificate, rather than the claims of the provisioner that created the order. We should probably be restricting access for orders to the provisioner that created it.

It's not really much of a "restriction", since ACME provisioners have no authentication. However, logically it doesn't make sense to start an order with a provisioner that has claims A but then wind up with certificate that has claims B. The certificate should probably have the claims of the provisioner that created the order.

dopey commented 4 years ago

I'm guessing this is low-priority because in order to actually hit this scenario a user would need to change the provisioner id in the request url mid conversation with the step-ca.

Figure we should track the bug in an issue for posterity.

dcow commented 4 years ago

Agree. This is also the case for some other acme operations. For example, you can perform a challenge using a different provisioner than the one that created the challenge. While there may not be obvious security holes, it's still behavior I'd consider abnormal if having multiple distinct acme provisioners is something we support.