[ https://issues.apache.org/jira/browse/NIFI-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcio Sugar updated NIFI-7061: ------------------------------- Environment: Ubuntu 16.04, Java 1.8 (was: Ubuntu 16.04) > 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 > 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} > *Update:* > I've tried to debug {{TlsToolkitMain}} and found out that: > - 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)