Re: SSLPeerUnverifiedException following upgrade from 1.6.0 to 1.13.2

2021-06-11 Thread James Srinivasan
This is my usual go-to reference for getting SANs working with openssl CSRs:

https://geekflare.com/san-ssl-certificate/

Newer openssl versions apparently allow it on the command line:

https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-the-command-line

On Fri, 11 Jun 2021 at 13:00, Phil H  wrote:
>
> Well, it took a lot of mis steps recreating and signing the certs (used the
> wrong CA) and working through all the other issues with SANs, BUT I GOT IT
> WORKING!
>
> Thanks David, and thanks to everyone else that helps out in this group!
> Nifi is so complicated I can’t imagine trying to do this stuff alone!
>
> On Fri, 11 Jun 2021 at 15:09, David Handermann 
> wrote:
>
> > Hi Phil,
> >
> > Thanks for providing the stack trace.  Recent versions of NiFi include
> > updates to the OkHttp library, which modified the hostname verification
> > process.  OkHttp starting with version 3.10.0 made changes to TLS hostname
> > verification, requiring that a certificate contain DNS Subject Alternative
> > Names matching the connection hostname.  Based on the error message, it
> > appears that the certificates configured do not have any Subject
> > Alternative Names, resulting in the SSLPeerUnverifiedException.  Generating
> > or obtaining new certificates that include the required DNS Subject
> > Alternative Names should resolve the problem.
> >
> > Here's the release notes for OkHttp 3.10.0, referencing RFC 2818, which
> > deprecated falling back to certificate common names for hostname
> > verification:
> >
> > https://square.github.io/okhttp/changelog_3x/#version-3100
> >
> > Regards,
> > David Handermann
> >
> > On Thu, Jun 10, 2021 at 11:16 PM Phil H  wrote:
> >
> > > Hi there,
> > >
> > > I upgraded an older dev setup today from 1.6.0 to 1.13.2.  After a
> > > couple of config tweaks, it’s “working”, but if I try and access the
> > > interface at https://nifi2.domain.blah/ I get a message on screen
> > > stating that nifi1.domain.blah is not verified.  The logs contain this
> > > same message, along with the stack trace.  (This also happens if I
> > > access nifi1 – it complains nifi2 is not verified).
> > >
> > > My keystore and truststore on both servers both contain the certs for
> > > both servers, and the truststore additionally contains the CA that
> > > signed both servers’ certificates.
> > >
> > > What am I missing?
> > >
> > > Thanks,
> > > Phil
> > >
> > >
> > >
> > >
> > >
> > > 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> > > o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request
> > > GET /nifi-api/flow/current-user to nifi1.domain.blah:443 due to
> > > javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.domain.blah
> > > not verified:
> > >
> > > certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
> > >
> > > DN: CN=nifi1.domain.blah, OU=domain, O=blah
> > >
> > > subjectAltNames: []
> > >
> > > 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> > > o.a.n.c.c.h.r.ThreadPoolRequestReplicator
> > >
> > > javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.
> > > nifi1.domain.blah not verified:
> > >
> > > certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
> > >
> > > DN: CN=nifi1.domain.blah OU=domain, O=blah
> > >
> > > subjectAltNames: []
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:389)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
> > >
> > > at
> > > okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
> > >
> > > at
> > > okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
> > >
> > > at
> > > okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> > >
> > > at
> > > okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> > >
> > > at
> > >
> > okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> > >
> > > at
> > >
> > >
> > 

Re: SSLPeerUnverifiedException following upgrade from 1.6.0 to 1.13.2

2021-06-11 Thread Phil H
Well, it took a lot of mis steps recreating and signing the certs (used the
wrong CA) and working through all the other issues with SANs, BUT I GOT IT
WORKING!

Thanks David, and thanks to everyone else that helps out in this group!
Nifi is so complicated I can’t imagine trying to do this stuff alone!

On Fri, 11 Jun 2021 at 15:09, David Handermann 
wrote:

> Hi Phil,
>
> Thanks for providing the stack trace.  Recent versions of NiFi include
> updates to the OkHttp library, which modified the hostname verification
> process.  OkHttp starting with version 3.10.0 made changes to TLS hostname
> verification, requiring that a certificate contain DNS Subject Alternative
> Names matching the connection hostname.  Based on the error message, it
> appears that the certificates configured do not have any Subject
> Alternative Names, resulting in the SSLPeerUnverifiedException.  Generating
> or obtaining new certificates that include the required DNS Subject
> Alternative Names should resolve the problem.
>
> Here's the release notes for OkHttp 3.10.0, referencing RFC 2818, which
> deprecated falling back to certificate common names for hostname
> verification:
>
> https://square.github.io/okhttp/changelog_3x/#version-3100
>
> Regards,
> David Handermann
>
> On Thu, Jun 10, 2021 at 11:16 PM Phil H  wrote:
>
> > Hi there,
> >
> > I upgraded an older dev setup today from 1.6.0 to 1.13.2.  After a
> > couple of config tweaks, it’s “working”, but if I try and access the
> > interface at https://nifi2.domain.blah/ I get a message on screen
> > stating that nifi1.domain.blah is not verified.  The logs contain this
> > same message, along with the stack trace.  (This also happens if I
> > access nifi1 – it complains nifi2 is not verified).
> >
> > My keystore and truststore on both servers both contain the certs for
> > both servers, and the truststore additionally contains the CA that
> > signed both servers’ certificates.
> >
> > What am I missing?
> >
> > Thanks,
> > Phil
> >
> >
> >
> >
> >
> > 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> > o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request
> > GET /nifi-api/flow/current-user to nifi1.domain.blah:443 due to
> > javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.domain.blah
> > not verified:
> >
> > certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
> >
> > DN: CN=nifi1.domain.blah, OU=domain, O=blah
> >
> > subjectAltNames: []
> >
> > 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> > o.a.n.c.c.h.r.ThreadPoolRequestReplicator
> >
> > javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.
> > nifi1.domain.blah not verified:
> >
> > certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
> >
> > DN: CN=nifi1.domain.blah OU=domain, O=blah
> >
> > subjectAltNames: []
> >
> > at
> >
> >
> okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:389)
> >
> > at
> >
> >
> okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
> >
> > at
> > okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)
> >
> > at
> >
> >
> okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
> >
> > at
> >
> >
> okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
> >
> > at
> > okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
> >
> > at
> > okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
> >
> > at
> >
> >
> okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
> >
> > at
> >
> >
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> >
> > at
> > okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
> >
> > at
> >
> >
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> >
> > at
> >
> okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
> >
> > at
> >
> >
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> >
> > at
> >
> >
> okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
> >
> > at
> >
> >
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> >
> > at
> >
> >
> okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
> >
> > at
> > okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
> >
> > at
> >
> >
> org.apache.nifi.cluster.coordination.http.replication.okhttp.OkHttpReplicationClient.replicate(OkHttpReplicationClient.java:132)
> >
> > at
> >
> >
> 

Re: SSLPeerUnverifiedException following upgrade from 1.6.0 to 1.13.2

2021-06-10 Thread David Handermann
Hi Phil,

Thanks for providing the stack trace.  Recent versions of NiFi include
updates to the OkHttp library, which modified the hostname verification
process.  OkHttp starting with version 3.10.0 made changes to TLS hostname
verification, requiring that a certificate contain DNS Subject Alternative
Names matching the connection hostname.  Based on the error message, it
appears that the certificates configured do not have any Subject
Alternative Names, resulting in the SSLPeerUnverifiedException.  Generating
or obtaining new certificates that include the required DNS Subject
Alternative Names should resolve the problem.

Here's the release notes for OkHttp 3.10.0, referencing RFC 2818, which
deprecated falling back to certificate common names for hostname
verification:

https://square.github.io/okhttp/changelog_3x/#version-3100

Regards,
David Handermann

On Thu, Jun 10, 2021 at 11:16 PM Phil H  wrote:

> Hi there,
>
> I upgraded an older dev setup today from 1.6.0 to 1.13.2.  After a
> couple of config tweaks, it’s “working”, but if I try and access the
> interface at https://nifi2.domain.blah/ I get a message on screen
> stating that nifi1.domain.blah is not verified.  The logs contain this
> same message, along with the stack trace.  (This also happens if I
> access nifi1 – it complains nifi2 is not verified).
>
> My keystore and truststore on both servers both contain the certs for
> both servers, and the truststore additionally contains the CA that
> signed both servers’ certificates.
>
> What am I missing?
>
> Thanks,
> Phil
>
>
>
>
>
> 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request
> GET /nifi-api/flow/current-user to nifi1.domain.blah:443 due to
> javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.domain.blah
> not verified:
>
> certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
>
> DN: CN=nifi1.domain.blah, OU=domain, O=blah
>
> subjectAltNames: []
>
> 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> o.a.n.c.c.h.r.ThreadPoolRequestReplicator
>
> javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.
> nifi1.domain.blah not verified:
>
> certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
>
> DN: CN=nifi1.domain.blah OU=domain, O=blah
>
> subjectAltNames: []
>
> at
>
> okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:389)
>
> at
>
> okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
>
> at
> okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)
>
> at
>
> okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
>
> at
>
> okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
>
> at
> okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
>
> at
> okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
>
> at
>
> okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
>
> at
>
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
>
> at
> okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
>
> at
>
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
>
> at
> okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
>
> at
>
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
>
> at
>
> okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
>
> at
>
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
>
> at
>
> okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
>
> at
> okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
>
> at
>
> org.apache.nifi.cluster.coordination.http.replication.okhttp.OkHttpReplicationClient.replicate(OkHttpReplicationClient.java:132)
>
> at
>
> org.apache.nifi.cluster.coordination.http.replication.okhttp.OkHttpReplicationClient.replicate(OkHttpReplicationClient.java:126)
>
> at
>
> org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator.replicateRequest(ThreadPoolRequestReplicator.java:652)
>
> at
>
> org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator$NodeHttpRequest.run(ThreadPoolRequestReplicator.java:844)
>
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> 

SSLPeerUnverifiedException following upgrade from 1.6.0 to 1.13.2

2021-06-10 Thread Phil H
Hi there,

I upgraded an older dev setup today from 1.6.0 to 1.13.2.  After a
couple of config tweaks, it’s “working”, but if I try and access the
interface at https://nifi2.domain.blah/ I get a message on screen
stating that nifi1.domain.blah is not verified.  The logs contain this
same message, along with the stack trace.  (This also happens if I
access nifi1 – it complains nifi2 is not verified).

My keystore and truststore on both servers both contain the certs for
both servers, and the truststore additionally contains the CA that
signed both servers’ certificates.

What am I missing?

Thanks,
Phil





2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request
GET /nifi-api/flow/current-user to nifi1.domain.blah:443 due to
javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.domain.blah
not verified:

certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=

DN: CN=nifi1.domain.blah, OU=domain, O=blah

subjectAltNames: []

2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
o.a.n.c.c.h.r.ThreadPoolRequestReplicator

javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.
nifi1.domain.blah not verified:

certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=

DN: CN=nifi1.domain.blah OU=domain, O=blah

subjectAltNames: []

at
okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:389)

at
okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)

at
okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)

at
okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)

at
okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)

at
okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)

at
okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)

at
okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)

at
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)

at
okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)

at
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)

at
okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)

at
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)

at
okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)

at
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)

at
okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)

at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)

at
org.apache.nifi.cluster.coordination.http.replication.okhttp.OkHttpReplicationClient.replicate(OkHttpReplicationClient.java:132)

at
org.apache.nifi.cluster.coordination.http.replication.okhttp.OkHttpReplicationClient.replicate(OkHttpReplicationClient.java:126)

at
org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator.replicateRequest(ThreadPoolRequestReplicator.java:652)

at
org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator$NodeHttpRequest.run(ThreadPoolRequestReplicator.java:844)

at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

at java.util.concurrent.FutureTask.run(FutureTask.java:266)

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)