[
https://issues.apache.org/jira/browse/NIFI-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16556380#comment-16556380
]
Andy LoPresto commented on NIFI-5459:
-------------------------------------
This effort should investigate the ACME protocol and the Let's Encrypt certbot
tool as examples, if not for direct integration.
* https://tools.ietf.org/html/draft-ietf-acme-acme-13
* https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment
* https://letsencrypt.org/docs/client-options/
*
https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578
> Integrate TLS Toolkit with external CA / certificate providers
> --------------------------------------------------------------
>
> Key: NIFI-5459
> URL: https://issues.apache.org/jira/browse/NIFI-5459
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions, Security, Tools and Build
> Affects Versions: 1.7.1
> Reporter: Andy LoPresto
> Priority: Major
> Labels: certificate, security, tls, tls-toolkit
>
> 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|https://letsencrypt.org/how-it-works/] 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
