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/23 00:09:00 UTC
[jira] [Updated] (NIFI-7061) TLS Toolkit in client mode 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:
-------------------------------
Summary: TLS Toolkit in client mode errors out when --subjectAlternativeNames option is set (was: TLS Toolkit errors out when --subjectAlternativeNames option is set)
> 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
> 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)