nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcio Sugar (Jira)" <j...@apache.org>
Subject [jira] [Resolved] (NIFI-7061) TLS Toolkit in client mode errors out when --subjectAlternativeNames option is set
Date Fri, 24 Jan 2020 04:57:00 GMT

     [ https://issues.apache.org/jira/browse/NIFI-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marcio Sugar resolved NIFI-7061.
--------------------------------
    Resolution: Duplicate

> 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)

Mime
View raw message