You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Andy LoPresto (JIRA)" <ji...@apache.org> on 2018/12/18 01:43:00 UTC

[jira] [Assigned] (NIFI-5459) Integrate TLS Toolkit with external CA / certificate providers

     [ https://issues.apache.org/jira/browse/NIFI-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy LoPresto reassigned NIFI-5459:
-----------------------------------

    Assignee: Andy LoPresto

> 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
>            Assignee: 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)