Vault as an ACME-based CA

[marcofranssen]

It would be great to be able to use vault as an ACME-based CA which could be used for company internal Certificates.

See here a link to the ACME specs. https://github.com/ietf-wg-acme/acme/

A project that might help on implementing the ACME CA within vault

https://github.com/letsencrypt/boulder

That would also allow this project to be integrated with go-acme/lego#1107

[delamart]

Could this be done by adding ACME API endpoints to the PKI secret engine ?

[marcofranssen]

I was also thinking this might be something we have to add on top of the pki engine.

[chewi]

As much as I'd like this, it has already been shot down in #668.

[MarkDeckert]

@chewi That's too bad :(

#668 was filed in 2015, only 1 month after the very first letsencrypt certificate was issued. I remember for quite a while most client implementations were cludgy at best.

Fast forward to 2020: Given the sheer amount of software that has 1st class support for ACME built-in now, should ACME compatibility in Vault be reconsidered as worthy of pursuit?

[danlsgiga]

This would be very much appreciated and a good use case is to enable internal mTLS among a chain of proxies that talk ACME without much effort.

[nvx]

The problem with ACME is it's designed for an unauthenticated user to be able to get a certificate via completing eg a DNS/http challenge. This is completely opposite to the Vault model where users are strongly authenticated, or as I've seen implemented in other implementations instead of requiring a challenge the ACME url instead has a token in it embedding some form of authorization (using a Vault token here has other issues around token lifecycles). Mapping anonymous or semi-anonymous via some token to eg PKI roles is a whole additional amount of complexity.

Instead if you wanted to use a Vault CA to issue certificates via an ACME Interface it would make more sense to have a separate service that talks to Vault (benefit no new attack surface on Vault, just the existing well understood PKI roles and policies to hit them) which in turn exposes an ACME compatible API secured via whatever mechanism is desired (some form of token in the URL, doing it's own DNS validation, etc). Since the ACME security model is entirely different than Vault's there is really no advantage to adding ACME endpoints to Vault directly (aside from convenience of not having to run a separate process), and a number of real disadvantages.

[mholt]

The problem with ACME is it's designed for an unauthenticated user to be able to get a certificate

FYI, ACME supports external account bindings to enforce authentication; several CAs use this to ensure a customer has a paid account: https://tools.ietf.org/html/rfc8555#section-7.3.4

[mmalone]

I work on https://github.com/smallstep/certificates, an open source certificate authority that supports ACME. We've started getting community requests for our CA to act as a "registration authority" in front of Vault, as described above by @nvx.

I'm trying to gauge interest in this functionality and scope the work. If you're interested in this functionality, please drop a 👍 on smallstep/certificates#343. If you have any thoughts on requirements or the details of an integration that'd be helpful too!

[sspreitzer]

@nvx I would like to point out that the ACME protocol's verification of domain ownership can be seen as a form of authentication. It could create a token that is authorized to issue a new certificate for that exact FQDN or wildcard.

[nvx]

@nvx I would like to point out that the ACME protocol's verification of domain ownership can be seen as a form of authentication. It could create a token that is authorized to issue a new certificate for that exact FQDN or wildcard.

It's not a form of authentication that matches how Vault tokens and policies work today though. Not seeing any advantage over the model used by the software that @mmalone (looks like that mentioned feature has been added already).

[sspreitzer]

@nvx & @mmalone I don't see that smallstep has integrated Vault. The topic is still in flux.

[dopey]

Also work on https://github.com/smallstep/certificates - and following up on @mmalone's comment from nearly a year ago. We did release the plugin architecture that allows us to integrate new backends but Vault is not supported yet. If anyone here has the experience / time to implement the interface we've exposed using the Vault API we'd be happy to assist.

I've opened up a new issue on our end to track a Vault specific API (smallstep/certificates#642) and have added a couple of reference links: the interface that needs to be implemented as a well as an example implementation (google CAS).

[nneul]

It's not strictly the same as this request, but I'd be interested in support for the inverse - having Vault's PKI functionality be able to function as an ACME client using dns based validation -- i.e. if configured for a specific dns suffix - be able to expose that using the existing vault pki mechanism, but have it reach out to an acme CA to obtain the cert instead of signing it internally.

This would allow a transparent handling of certificate domains via vault, with an 'invisible to the client' upgrade to fully externally trusted certs -- possibly on a subdomain/access policy basis.

[nneul]

Never mind looks like #4950 already covers this.

[mikemaxey]

I also work on https://github.com/smallstep/certificates. We've recently merged a PR that enables ACME RA support for vault PKI. Give it a try and let us know what you think.

[cipherboy]

With Vault 1.14, we will be shipping ACME issuance APIs as part of the PKI Secrets Engine! Feel free to give it a shot with the upcoming RC1 release (or by building main before then) and let us know if anyone has feedback. :-)

Docs are currently present in the repository.

[mholt]

This is cool, I look forward to Caddy / CertMagic users using this.