-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
role to support JWK-based (x509) certificates #127
Comments
While I don't use JWK-based certs myself, I'd be more than happy to support that use case. The way I see it, the main purpose of As for the implementation side of things, I like the idea of a single, unified role. |
This role can accommodate all different types of provisioners. For the currently implementation, only: - ACME - JWK If the requested provisioner is not supported, role will fail with appropriate message. If this role is adopted, suggest we deprecate `step_acme_cert`. FIXES: maxhoesel-ansible#127
My initial cut at an implementation is in PR #129, but I'm soliciting feedback there. It supports both
I'm not sure a role and a module of the same name would conflict, would they? If so, I'm fairly agnostic about the name. |
I'm not 100% sure either, but I think I remember having an issue related to that before. That said, even if there is an issue, it's all in the far future when someone actually wants to add the standalone certificate command into the collection. I just thought I'd point it out for future reference, but it's nothing to worry about. And thanks for getting an initial implementation going 👍 |
This role can accommodate all different types of provisioners. For the currently implementation, only: - ACME - JWK If the requested provisioner is not supported, role will fail with appropriate message. If this role is adopted, suggest we deprecate `step_acme_cert`. FIXES: maxhoesel-ansible#127
This role can accommodate all different types of provisioners. For the currently implementation, only: - ACME - JWK If the requested provisioner is not supported, role will fail with appropriate message. If this role is adopted, suggest we deprecate `step_acme_cert`. FIXES: maxhoesel-ansible#127
@maxhoesel - I recently revisited my fork to support this issue, and also looked at the latest code base. I'm pretty sure you've got everything needed to support JWK-based certificate creation. I'm testing on the current HEAD of What's your take on this issue and the associated (long abandoned by me) pull request? I am pretty sure we can abandon both as "superseded by new code" BTW - thanks for continuing to develop this collection - it's really coming along. |
There is a role for creating X509 certificates via an ACME provisioner (
step_acme_cert
), but there is not one using other provisioners, e.g.JWK
. The routines are mostly parallel, and the creation of the renewal viasystemd
should be similar if not identical. To date, I've been using the modules (step_ca_token
andstep_ca_certificate
) directly, but I should rather be using a role that others can use, and vet.I am starting development of a new role, and believe that the existing role could be subsumed by a single
step_certificate
role. But if you prefer, I could provide a separatestep_jwk_certificate
.Preferences?
The text was updated successfully, but these errors were encountered: