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.
On Sat, Mar 10, 2018 at 11:17 AM, Ryan H <ryan.howell.developm...@gmail.com>
> 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:*
> PKIX path building failed:
> 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)
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.5 LTS
> Release: 14.04
> Codename: trusty
> OpenSSL Version:
> OpenSSL 1.0.1f 6 Jan 2014