role to support JWK-based (x509) certificates
eengstrom opened this issue · 4 comments
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 via systemd should be similar if not identical. To date, I've been using the modules (step_ca_token and step_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 separate step_jwk_certificate.
Preferences?
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 step_acme_cert right now is to automate issuing and renewal of certs - which is something that the other cert types would benefit from as well.
As for the implementation side of things, I like the idea of a single, unified role. step_certificate sounds good to me, but there is the risk of a conflict with a future module for the step certificate command. That said, that's not a problem right now, so feel free to go ahead!
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
step_acme_certright now is to automate issuing and renewal of certs - which is something that the other cert types would benefit from as well.
My initial cut at an implementation is in PR #129, but I'm soliciting feedback there. It supports both ACME and JWK provisioners. Others should be easily added, following the pattern established.
As for the implementation side of things, I like the idea of a single, unified role.
step_certificatesounds good to me, but there is the risk of a conflict with a future module for thestep certificatecommand. That said, that's not a problem right now, so feel free to go ahead!
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 👍
@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 main of the collection, and I'm not seeing anything but a couple of minor issues.
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.