Digging into the NiFi TLS toolkit and SubjectAlternativeName for IP
addresses. I checked the NiFi TLS toolkit code for SubjectAlternativeName
and found this:

https://github.com/apache/nifi/blob/master/nifi-toolkit/nifi-toolkit-tls/src/main/java/org/apache/nifi/toolkit/tls/util/TlsHelper.java#L226

namesList.add(new GeneralName(GeneralName.dNSName, cn));

Since the type is "GeneralName.dNSName" that means that it is assuming a
DNSName and not an IP address.

If the NiFi TLS toolkit supported IP addresses for SubjectAlternativeName
then it would have to be "GeneralName.iPAddress"
http://javadox.com/org.bouncycastle/bcprov-jdk15on/1.51/org/bouncycastle/asn1/x509/GeneralName.html#iPAddress

Again the error message is confusing but think this could be the cause of
the issue since the subject alternative name is being treated as a DNSName
and not an IP address like you think it is.

Kevin Risden

On Tue, Mar 13, 2018 at 8:46 PM, Kevin Risden <kris...@apache.org> wrote:

> Extracting my reply from the other thread here since this has a clearly
> identified error message:
>
> *2 way SSL on*
> - SSLPeerUnverifiedException: Certificate for <NIFI-IP> doesn't match any
> of the subject alternative names: [NIFI-IP]
>
> This error is most likely occurring because you are using IP addresses.
> SSL certificate CN=ip_address I'm not sure is 100% valid. The debug output
> you have above has one problem though where SubjectAlternativeName has
> DNSName=ip_address. Instead this should have IP=ip_address. I don't know if
> the nifi SSL toolkit can generate a SubjectAlternativeName with
> IP=ip_address. It might be assuming you provide a hostname. The error
> output is confusing but the first NIFI-IP is the certificate common name
> and the second is most likely a DNSName and NOT an ip address like you
> think it is.
>
> *SSL - Hostnames vs IPs*
> This is super general but I have run into issues with hostnames vs IPs for
> SSL before. SSL was built for hostnames. CN=HOSTNAME is the original way to
> configure an SSL certificate. If you put the FQDN in the CN then you MUST
> use the FQDN when trying to connect to that server. You can't just use the
> short hostname since it won't match. SubjectAlternativeName is an extension
> of SSL certificates that allow for easier configuration of certificates
> instead of always using a hostname in the CN. A single certificate could
> now be used for multiple hostnames and in some cases IPs.
> SubjectAlternativeName defaults to DNSName when you add to it. I have not
> seen this work with pure IP addresses. If you want to use IP addresses
> inside SubjectAlternativeName, you must have the prefix "IP:" for example
> IP:127.0.0.1. This differentiates it from DNSName.
>
>
>
> Kevin Risden
>
> On Sat, Mar 10, 2018 at 11:17 AM, Ryan H <ryan.howell.development@
> gmail.com> wrote:
>
>> Hi All,
>>
>> I am starting a new thread on this as it is a different error on the last
>> thread I was on and hopefully to catch the attention of additional persons
>> that may have expertise with this (sorry for the many emails on this).
>>
>> I have a NiFi secure cluster that I am using Apache Knox to proxy all
>> traffic to. This set up has been tested first as an insecure cluster, which
>> works fine. Switching to the secure cluster though has been a nightmare
>> with an error that I cannot get past.
>>
>> *The original error was:*
>> javax.net.ssl.SSLHandshakeException: 
>> sun.security.validator.ValidatorException:
>> PKIX path building failed: 
>> sun.security.provider.certpath.SunCertPathBuilderException:
>> unable to find valid certification path to requested target
>>
>> Adding the keystore.jks and truststore.jks obtained from the NiFi TLS
>> Toolkit to the Knox gateway.jks keystore got rid of the above error, but
>> then resulted in a new one.
>>
>> *This is the new error that I am now stuck at:*
>>  javax.net.ssl.SSLPeerUnverifiedException: Certificate for
>> <NIFI-IP-ADDR> doesn't match any of the subject alternative names: [
>> NIFI-IP-ADDR]
>>
>> The error seems to be misleading as the NIFI-IP-ADDR is in fact in the
>> SANS within the certificate, as well as the error itself.
>>
>> On the Knox side, "twoWaySsl" is enabled both in the sandbox.xml as well
>> as the service.xml (defined in the NIFI service). On the NiFi side, the
>> Knox identity has an entry in the authorizers.xml file as a User Identity
>> (I did try adding it as a Node Identity as well just to try something new).
>>
>> My last thoughts on this were that it potentially had something to do
>> with either the version of Java or openssl that I am running, but
>> unfortunately its not much help as I am not sure what would work vs what
>> wouldn't work. The other thought would be that this may potentially be an
>> issue with the TLS Toolkit, but it works just fine for the cluster nodes.
>>
>> Can anyone verify that this setup works? Has anyone set this up with Knox
>> proxying NiFi over SSL using the self-signed certs via TLS Toolkit (if so,
>> can you share details on your set up)? I have to missing something here,
>> but out of ideas on what...
>>
>> NiFi Version: 1.6.0
>> NiFi TLS Toolkit Version: 1.6.0
>> Knox Version: 1.1.0
>>
>> Java Version:
>> openjdk version "1.8.0_141"
>> OpenJDK Runtime Environment (build 1.8.0_141-8u141-b15-3~14.04-b15)
>> OpenJDK 64-Bit Server VM (build 25.141-b15, mixed mode)
>>
>> OS:
>> Distributor ID: Ubuntu
>> Description: Ubuntu 14.04.5 LTS
>> Release: 14.04
>> Codename: trusty
>>
>> OpenSSL Version:
>> OpenSSL 1.0.1f 6 Jan 2014
>>
>>
>

Reply via email to