Skip to content
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

Open
eengstrom opened this issue Sep 30, 2021 · 4 comments · May be fixed by #129
Open

role to support JWK-based (x509) certificates #127

eengstrom opened this issue Sep 30, 2021 · 4 comments · May be fixed by #129
Labels
enhancement New feature or improvement to an existing one roles Something affecting one or more roles

Comments

@eengstrom
Copy link
Contributor

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?

@maxhoesel
Copy link
Collaborator

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!

@maxhoesel maxhoesel added enhancement New feature or improvement to an existing one roles labels Sep 30, 2021
eengstrom added a commit to eengstrom/ansible-collection-smallstep that referenced this issue Oct 6, 2021
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
@eengstrom
Copy link
Contributor Author

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.

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_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!

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.

@maxhoesel
Copy link
Collaborator

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 👍

eengstrom added a commit to eengstrom/ansible-collection-smallstep that referenced this issue Oct 9, 2021
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
eengstrom added a commit to eengstrom/ansible-collection-smallstep that referenced this issue Oct 18, 2021
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
@github-actions github-actions bot removed the roles label May 28, 2022
@maxhoesel maxhoesel added the roles Something affecting one or more roles label May 28, 2022
@eengstrom
Copy link
Contributor Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement to an existing one roles Something affecting one or more roles
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants