Uploaded image for project: 'Apache NiFi'
  1. Apache NiFi
  2. NIFI-7061

TLS Toolkit in client mode errors out when --subjectAlternativeNames option is set

    XMLWordPrintableJSON

    Details

    • 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
    • Labels:
      None
    • Environment:
      Ubuntu 16.04, Java 1.8.0_201

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                msugar Marcio Sugar
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: