[
https://issues.apache.org/jira/browse/NIFI-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022686#comment-17022686
]
Marcio Sugar commented on NIFI-7061:
------------------------------------
The problem was fixed in the 1.11.0 version released today.Â
> TLS Toolkit in client mode 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, Java 1.8.0_201
> Reporter: Marcio Sugar
> Priority: Critical
> Fix For: 1.11.0
>
>
> 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 -t 0123456789abcdef -p 10000
> {noformat}
> *Update:*
> I found the bug:
> - In the {{TlsCertificateAuthorityClientCommandLine}} class, the {{doParse}}
> method calls {{InstanceDefinition.createDefinitions}} with all the arguments
> but the 2nd set to null. So the {{keyStorePasswords}} argument is always null.
> - In the {{InstanceDefinition}} class, {{createDefinitions}} then calls
> {{createDefinition}}, which tries to get a value from a {{keyStorePasswords}}
> Supplier that doesn't exist in this case, causing the NPE to be thrown.
> - The NPE is not caught by any of the above mentioned methods, so no
> CommandLineParseException is ever created and it's eventually wrapped in an
> {{InvocationTargetException}}.
> - In the method {{doMain(String[])}}, the code after
> {{catch(InvocationTargetException)}} throws another NPE because
> {{e.getCause()}} returns null. Not all exceptions have a cause.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
