You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Andre F de Miranda (JIRA)" <ji...@apache.org> on 2017/04/27 10:08:04 UTC
[jira] [Updated] (NIFI-3750) tls-toolkit should support x.509
nameConstrains
[ https://issues.apache.org/jira/browse/NIFI-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andre F de Miranda updated NIFI-3750:
-------------------------------------
Description:
given the growing acceptance of namedConstraints in the browser space, it would be great if tls-toolkit certificates used the extension.
nameConstraints are an extension to x.509 that allow CA certificates to be constrained on the range the subjects they can "certify". One could for example, restrict certificates by the nifinode00.nifi.lab.example.com" to only issue certificates to "*.nifi.lab.example.com"
Consequentially the main rationale to use this technique is to allow users to install the tls-toolkit issued CA on browsers, knowing that that trusted CA can only be used to issue certificates to subjects within the "nifi.lab.example.com" namespace.
Once this is implemented, we could then consider both NiFi nodes and MiNiFi agents against a beefed version of tls-toolkit (via shared secret + approval), greatly reducing dependency on external certificates, without compromising the gains the toolkit offers to the customer base.
https://tools.ietf.org/html/rfc5280#section-4.2.1.10
was:
given the growing acceptance of namedConstrains in the browser space, it would be great if tls-toolkit certificates used the extension.
nameConstrains are an extension to x.509 that allow CA certificates to be constrained on the range the subjects they can "certify". One could for example, restrict certificates by the nifinode00.nifi.lab.example.com" to only issue certificates to "*.nifi.lab.example.com"
Consequentially the main rationale to use this technique is to allow users to install the tls-toolkit issued CA on browsers, knowing that that trusted CA can only be used to create certificates for subjects within the "nifi.lab.example.com" namespace.
Once this is implemented, we could then consider both NiFi nodes and MiNiFi agents against a beefed version of tls-toolkit (via shared secret + approval), greatly reducing dependency on external certificates, without compromising the gains the toolkit offers to the customer base.
https://tools.ietf.org/html/rfc5280#section-4.2.1.10
> tls-toolkit should support x.509 nameConstrains
> -----------------------------------------------
>
> Key: NIFI-3750
> URL: https://issues.apache.org/jira/browse/NIFI-3750
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Andre F de Miranda
>
> given the growing acceptance of namedConstraints in the browser space, it would be great if tls-toolkit certificates used the extension.
> nameConstraints are an extension to x.509 that allow CA certificates to be constrained on the range the subjects they can "certify". One could for example, restrict certificates by the nifinode00.nifi.lab.example.com" to only issue certificates to "*.nifi.lab.example.com"
> Consequentially the main rationale to use this technique is to allow users to install the tls-toolkit issued CA on browsers, knowing that that trusted CA can only be used to issue certificates to subjects within the "nifi.lab.example.com" namespace.
> Once this is implemented, we could then consider both NiFi nodes and MiNiFi agents against a beefed version of tls-toolkit (via shared secret + approval), greatly reducing dependency on external certificates, without compromising the gains the toolkit offers to the customer base.
> https://tools.ietf.org/html/rfc5280#section-4.2.1.10
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)