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

Troy Melhase reassigned NIFI-4247:
----------------------------------

    Assignee: Troy Melhase

> TLS Toolkit should parse regex in SAN fields
> --------------------------------------------
>
>                 Key: NIFI-4247
>                 URL: https://issues.apache.org/jira/browse/NIFI-4247
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Tools and Build
>    Affects Versions: 1.3.0
>            Reporter: Andy LoPresto
>            Assignee: Troy Melhase
>            Priority: Major
>              Labels: certificate, security, subjectAltName, tls, tls-toolkit
>
> Similar to the way the TLS Toolkit can generate multiple certificates with 
> one command through parsing some minimal regular expression syntax in the 
> hostname field, the SAN field should be processed the same way. Currently, a 
> command which generates three hosts via {{-n "server[1-3].com"}} cannot have 
> the corresponding SAN entries provided inline. Once NIFI-4222 is implemented, 
> the hostname will be present in the SAN list by default, but if there are 
> additional desired entries, the command must be split and run individually. 
> Example:
> ||Desired hostname||Desired SAN||
> |{{server1.com}}|{{server1.com, otherserver1.com}}|
> |{{server2.com}}|{{server2.com, otherserver2.com}}|
> |{{server3.com}}|{{server3.com, otherserver3.com}}|
> {code}
> $ ./bin/tls-toolkit.sh standalone -n "server[1-3].com" 
> --subjectAlternativeNames "otherserver[1-3].com"
> {code}
> Currently, this must be run as: 
> {code}
> $ ./bin/tls-toolkit.sh standalone -n "server1.com" --subjectAlternativeNames 
> "otherserver1.com"
> $ ./bin/tls-toolkit.sh standalone -n "server2.com" --subjectAlternativeNames 
> "otherserver2.com"
> $ ./bin/tls-toolkit.sh standalone -n "server3.com" --subjectAlternativeNames 
> "otherserver3.com"
> {code}
> The ranges should be checked for length equality, but need not necessarily be 
> identical. For example:
> {code}
> $ ./bin/tls-toolkit.sh standalone -n "server[1-3].com" 
> --subjectAlternativeNames "otherserver[4-6].com"
> {code}
> Today, if you don't care about SAN values, this is achievable with:
> {code}
> $ ./bin/tls-toolkit.sh standalone -n "server[1-3].com"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to