You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Marcio Sugar (Jira)" <ji...@apache.org> on 2020/01/22 18:32:00 UTC
[jira] [Updated] (NIFI-7061) TLS Toolkit errors out when
--subjectAlternativeNames option is set
[ https://issues.apache.org/jira/browse/NIFI-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcio Sugar updated NIFI-7061:
-------------------------------
Description:
Running the TLS Tookit 1.10.0 client with the {{–subjectAlternativeNames}} option set gives an error:
{noformat}
$ nifi-toolkit-1.10.0/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 --subjectAlternativeNames nifi.mydomain.com
Service client error: null
Usage: tls-toolkit service [-h] [args]
Services:
standalone: Creates certificates and config files for nifi cluster.
server: Acts as a Certificate Authority that can be used by clients to get Certificates
client: Generates a private key and gets it signed by the certificate authority.
status: Checks the status of an HTTPS endpoint by making a GET request using a supplied keystore and truststore.
{noformat}
But the same command works fine with the TLS Toolkit 1.7.1 client:
{noformat}
$ nifi-toolkit-1.7.1/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 --subjectAlternativeNames nifi.mydomain.com
2020/01/22 13:16:57 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: Requesting new certificate from localhost:10000
2020/01/22 13:16:57 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Requesting certificate with dn CN=msugar,OU=NIFI from localhost:10000
2020/01/22 13:16:58 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Got certificate with dn CN=msugar, OU=NIFI
{noformat}
When the {{–subjectAlternativeNames}} option is not set, the 1.10.0 client runs with no issues:
{noformat}
$ nifi-toolkit-1.10.0/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 nifi.mydomain.com
2020/01/22 13:22:47 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: Requesting new certificate from localhost:10000
2020/01/22 13:22:48 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Requesting certificate with dn CN=msugar,OU=NIFI from localhost:10000
2020/01/22 13:22:48 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Got certificate with dn CN=msugar, OU=NIFI
{noformat}
Note that, in all cases, the server is a TLS Tookit 1.10.0 process running on the same machine (msugar) as the clients:
{noformat}
$ nifi-toolkit-1.10.0/bin/tls-toolkit.sh server -0123456789abcdef -p 10000
{noformat}
was:
Running the TLS Tookit 1.10.0 client with the {{–subjectAlternativeNames}} option set gives an error:
{noformat}
$ nifi-toolkit-1.10.0/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 --subjectAlternativeNames "nifi.mydomain.com"
Service client error: null
Usage: tls-toolkit service [-h] [args]
Services:
standalone: Creates certificates and config files for nifi cluster.
server: Acts as a Certificate Authority that can be used by clients to get Certificates
client: Generates a private key and gets it signed by the certificate authority.
status: Checks the status of an HTTPS endpoint by making a GET request using a supplied keystore and truststore.
{noformat}
But the same command works fine with the TLS Toolkit 1.7.1 client:
{noformat}
$ nifi-toolkit-1.7.1/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 --subjectAlternativeNames nifi.mydomain.com
2020/01/22 13:16:57 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: Requesting new certificate from localhost:10000
2020/01/22 13:16:57 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Requesting certificate with dn CN=msugar,OU=NIFI from localhost:10000
2020/01/22 13:16:58 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Got certificate with dn CN=msugar, OU=NIFI
{noformat}
When the {{–subjectAlternativeNames}} option is not set, the 1.10.0 client runs with no issues:
{noformat}
$ nifi-toolkit-1.10.0/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 nifi.mydomain.com
2020/01/22 13:22:47 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: Requesting new certificate from localhost:10000
2020/01/22 13:22:48 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Requesting certificate with dn CN=msugar,OU=NIFI from localhost:10000
2020/01/22 13:22:48 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Got certificate with dn CN=msugar, OU=NIFI
{noformat}
Note that, in all cases, the server is a TLS Tookit 1.10.0 process running on the same machine (msugar) as the clients:
{noformat}
$ nifi-toolkit-1.10.0/bin/tls-toolkit.sh server -0123456789abcdef -p 10000
{noformat}
> TLS Toolkit errors out when --subjectAlternativeNames option is set
> -------------------------------------------------------------------
>
> Key: NIFI-7061
> URL: https://issues.apache.org/jira/browse/NIFI-7061
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
> Affects Versions: 1.10.0
> Environment: Ubuntu 16.04
> Reporter: Marcio Sugar
> Priority: Major
>
> Running the TLS Tookit 1.10.0 client with the {{–subjectAlternativeNames}} option set gives an error:
> {noformat}
> $ nifi-toolkit-1.10.0/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 --subjectAlternativeNames nifi.mydomain.com
> Service client error: null
> Usage: tls-toolkit service [-h] [args]
> Services:
> standalone: Creates certificates and config files for nifi cluster.
> server: Acts as a Certificate Authority that can be used by clients to get Certificates
> client: Generates a private key and gets it signed by the certificate authority.
> status: Checks the status of an HTTPS endpoint by making a GET request using a supplied keystore and truststore.
> {noformat}
> But the same command works fine with the TLS Toolkit 1.7.1 client:
> {noformat}
> $ nifi-toolkit-1.7.1/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 --subjectAlternativeNames nifi.mydomain.com
> 2020/01/22 13:16:57 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: Requesting new certificate from localhost:10000
> 2020/01/22 13:16:57 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Requesting certificate with dn CN=msugar,OU=NIFI from localhost:10000
> 2020/01/22 13:16:58 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Got certificate with dn CN=msugar, OU=NIFI
> {noformat}
> When the {{–subjectAlternativeNames}} option is not set, the 1.10.0 client runs with no issues:
> {noformat}
> $ nifi-toolkit-1.10.0/bin/tls-toolkit.sh client -t 0123456789abcdef -p 10000 nifi.mydomain.com
> 2020/01/22 13:22:47 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: Requesting new certificate from localhost:10000
> 2020/01/22 13:22:48 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Requesting certificate with dn CN=msugar,OU=NIFI from localhost:10000
> 2020/01/22 13:22:48 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Got certificate with dn CN=msugar, OU=NIFI
> {noformat}
> Note that, in all cases, the server is a TLS Tookit 1.10.0 process running on the same machine (msugar) as the clients:
> {noformat}
> $ nifi-toolkit-1.10.0/bin/tls-toolkit.sh server -0123456789abcdef -p 10000
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)