Re: Knox SSL with NiFi SSLPeerUnverifiedException

[Kevin Risden]

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  wrote:

> Extracting my reply from the other thread here since this has a clearly
> identified error message:
>
> *2 way SSL on*
> - SSLPeerUnverifiedException: Certificate for  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  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
>>  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 

Re: Knox SSL with NiFi SSLPeerUnverifiedException

[Kevin Risden]

Extracting my reply from the other thread here since this has a clearly
identified error message:

*2 way SSL on*
- SSLPeerUnverifiedException: Certificate for  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 
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 
> 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
>
>

Knox SSL with NiFi SSLPeerUnverifiedException

[Ryan H]

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