[NIFI-7061] TLS Toolkit in client mode errors out when --subjectAlternativeNames option is set

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Duplicate
• Affects Version/s: 1.10.0
• Fix Version/s: 1.11.0
• Component/s: Tools and Build
• Environment: Ubuntu 16.04, Java 1.8.0_201
• Assignee: Unassigned
• Reporter: Marcio Sugar
• Created: 22/Jan/20 18:30
• Updated: 24/Jan/20 04:56
• Resolved: 24/Jan/20 04:56

Description

Running the TLS Tookit 1.10.0 client with the –subjectAlternativeNames option set gives an error:

$ 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.

But the same command works fine with the TLS Toolkit 1.7.1 client:

$ 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

When the –subjectAlternativeNames option is not set, the 1.10.0 client runs with no issues:

$ 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

Note that, in all cases, the server is a TLS Tookit 1.10.0 process running on the same machine (msugar) as the clients:

$ nifi-toolkit-1.10.0/bin/tls-toolkit.sh server -t 0123456789abcdef -p 10000

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.

Issue Links

• duplicates: NIFI-6847 TLS Toolkit - NPE when used in client mode