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

Add support for enrolling user provided CSR #33

Open
tr1ck3r opened this issue Nov 26, 2020 · 0 comments
Open

Add support for enrolling user provided CSR #33

tr1ck3r opened this issue Nov 26, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@tr1ck3r
Copy link
Member

tr1ck3r commented Nov 26, 2020

BUSINESS PROBLEM
Some applications only support key pairs and CSRs that they generate themselves and do not allow import of externally generated private keys. A solution is needed that accepts a CSR as input to obtain a certificate for such cases.

PROPOSED SOLUTION
Optionally allow a CSR file to be specified in the role configuration and, if specified, use it to enroll a certificate rather than generating a new key pair and CSR for enrolling a certificate. When the CSR file is specified the privatekey_path (and other private key parameters) should not be required in the role configuration (ignored if they are present). The common_name and alt_name parameters should also not be required, rather the CSR should be parsed to obtain their values.

There is currently a csr_path parameter declared and used in library/venafi_certificate.py that may have been intended to support this use case but it seems the implementation is incomplete. The csr_path parameter is not declared in tasks/local-certificate.yml which means no value can be assigned to it by a playbook using the role. Even when assigned a value the behavior of the library is inconsistent with the user provided CSR requirements, it seems to always generate a new key pair and write a private key file (which fails when privatekey_path is set to null as would be logical). For the user provided CSR use case we should assume the remote device already has the private key or it will be delivered to it by a separate process.

CURRENT ALTERNATIVES
Use VCert-Python.

@tr1ck3r tr1ck3r added the enhancement New feature or request label Nov 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant