The TLS toolkit was designed to be a sandbox-level assistant for deployments which did not have access to a security team / dedicated certificate provider to replace manual generation of certificates with complicated openssl and keytool commands. It has grown to be depended on by many users, as well as Apache Ambari deployments.
Because of these uses, it should be made more robust, including integration with external certificate providers. Multiple commercial certificate providers have APIs for automating the submission of CSRs and requesting issuance of signed certificates. In the standalone or client/server model, the toolkit should be able to define an external certificate provider, and if the proper "definition" (API mapping) is available, use provided credentials to request and receive a signed certificate. There should be an intermediate mapping between a "toolkit-standard communication method" and the communication with the external provider, so that the toolkit requestor (standalone/client) does not need to change; either the server maps the standard request to a specific provider, or the standalone component uses the pluggable mapping to do the same.
Only two definitions should be required to mark this ticket as complete:
- the internal NiFi provider (map toolkit commands to internal openssl generation commands)
- an external provider (suggest letsencrypt.org as it is free, non-profit, and domain validation (DV) is automated)
Additional definitions can be provided as follow-on tickets independent of this ticket. If internal organization/enterprise certificate providers are needed, they can follow the well-defined extension point which should result from this effort.