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 2019/04/15 17:16:00 UTC
[jira] [Updated] (NIFI-4247) TLS Toolkit should parse regex in SAN
fields
[ https://issues.apache.org/jira/browse/NIFI-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy LoPresto updated NIFI-4247:
--------------------------------
Description:
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}
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}
was:
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}
> 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
> 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}
> 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)