[
https://issues.apache.org/jira/browse/NIFI-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825634#comment-16825634
]
Troy Melhase commented on NIFI-4247:
------------------------------------
I'd like to take a shot at this one; you've captured most of our discussion
regarding range lengths.
> 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)
