SSLPeerUnverifiedException Hostname "xyz" not verified

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

SSLPeerUnverifiedException Hostname "xyz" not verified

Josefz
This post was updated on .
Hi expert

I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured cluster
with LDAP authentication. Now I'm not anymore able to login into the webgui.
After I have entered the login/password I'm getting the following message:

An unexpected error has occurred
javax.net.ssl.SSLPeerUnverifiedException: Hostname i-li-nifi-97.bblab.ch not verified: certificate: sha256/14+aCYShEsw59mYdkVr/nuUIILI8e9tJksJtfNff3H0= DN: CN=Apache NiFi, OU=LI, O=Swisscom (Schweiz) AG, L=Worblaufen, ST=Bern, C=CH subjectAltNames: [*.bblab.ch]

And nifi-app.log reports the following error messages:
2018-07-05 12:08:40,705 WARN [Replicate Request Thread-1] o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request GET /nifi-api/flow/current-user to i-li-nifi-97.bblab.ch:8443 due to javax.net.ssl.SSLPeerUnverifiedException: Hostname i-li-nifi-97.bblab.ch not verified:
    certificate: sha256/14+aCYShEsw59mYdkVr/nuUIILI8e9tJksJtfNff3H0=
    DN: CN=Apache NiFi, OU=LI, O=Swisscom (Schweiz) AG, L=Worblaufen, ST=Bern, C=CH
    subjectAltNames: [*.bblab.ch]
2018-07-05 12:08:40,712 WARN [Replicate Request Thread-1] o.a.n.c.c.h.r.ThreadPoolRequestReplicator 
javax.net.ssl.SSLPeerUnverifiedException: Hostname i-li-nifi-97.bblab.ch not verified:
    certificate: sha256/14+aCYShEsw59mYdkVr/nuUIILI8e9tJksJtfNff3H0=
    DN: CN=Apache NiFi, OU=LI, O=Swisscom (Schweiz) AG, L=Worblaufen, ST=Bern, C=CH
    subjectAltNames: [*.bblab.ch]
        at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:316)
        at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:270)
        at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:162)
        at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:257)
        at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:135)
        at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:114)
        at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
        at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
        at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:126)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
        at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:200)
        at okhttp3.RealCall.execute(RealCall.java:77)
        at org.apache.nifi.cluster.coordination.http.replication.okhttp.OkHttpReplicationClient.replicate(OkHttpReplicationClient.java:120)
        at org.apache.nifi.cluster.coordination.http.replication.okhttp.OkHttpReplicationClient.replicate(OkHttpReplicationClient.java:114)
        at org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator.replicateRequest(ThreadPoolRequestReplicator.java:629)
        at org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator$NodeHttpRequest.run(ThreadPoolRequestReplicator.java:821)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)


I'm having a wildcard SSL certificate and I'm using the same
keystore/truststore combination for three usecases:
- for cluster connectivity (in nifi.properties)
- in "authorizer.xml"
- in "login-identity-providers.xml".

The keystore.jks (private/public) keypair has been signed by our internal
root CA and the root CA cert has been imported into the truststore.jks. As
the ldap login works with certificates I'm more or less sure that the certs
in general are fine. Has anybody an idea if wildcard CN and SAN names should
work in a cluster or where the problem could be? I've tried the same certs
as well in standalone mode, no issue at all.

The following parameters in nifi.properties are enabled:
nifi.security.needClientAuth=true
nifi.cluster.protocol.is.secure=true

Thanks in advance




--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Pierre Villard
Hi Josef,

I don't have a solution for you but it seems it has already been reported
and a JIRA has been opened:
https://issues.apache.org/jira/browse/NIFI-5370

Andy might be able to give more insights about it.

Pierre

2018-07-05 13:19 GMT+02:00 Josefz <[hidden email]>:

> Hi expert
>
> I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured cluster
> with LDAP authentication. Now I'm not anymore able to login into the
> webgui.
> After I have entered the login/password I'm getting the following message:
>
>
>
> And nifi-app.log reports the following error messages:
>
>
>
> I'm having a wildcard SSL certificate and I'm using the same
> keystore/truststore combination for three usecases:
> - for cluster connectivity (in nifi.properties)
> - in "authorizer.xml"
> - in "login-identity-providers.xml".
>
> The keystore.jks (private/public) keypair has been signed by our internal
> root CA and the root CA cert has been imported into the truststore.jks. As
> the ldap login works with certificates I'm more or less sure that the certs
> in general are fine. Has anybody an idea if wildcard CN and SAN names
> should
> work in a cluster or where the problem could be? I've tried the same certs
> as well in standalone mode, no issue at all.
>
> The following parameters in nifi.properties are enabled:
> nifi.security.needClientAuth=true
> nifi.cluster.protocol.is.secure=true
>
> Thanks in advance
>
>
>
>
> --
> Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/
>
Reply | Threaded
Open this post in threaded view
|

Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Jon Logan
I saw this in the release notes...specifically that wildcard certs are not
supported. How do most people handle this in practice? We can run a cert
server or get them from other means (AWS cert manager, etc) but am not sure
how to overcome the authorizers.xml issue -- would we need to have a
provisioning script register each new server certificate with NiFi before
it can actually do anything useful? Will new servers then have issues
joining because their authorizers will not match the rest of the cluster?

On Thu, Jul 5, 2018 at 8:04 AM, Pierre Villard <[hidden email]>
wrote:

> Hi Josef,
>
> I don't have a solution for you but it seems it has already been reported
> and a JIRA has been opened:
> https://issues.apache.org/jira/browse/NIFI-5370
>
> Andy might be able to give more insights about it.
>
> Pierre
>
> 2018-07-05 13:19 GMT+02:00 Josefz <[hidden email]>:
>
> > Hi expert
> >
> > I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured
> cluster
> > with LDAP authentication. Now I'm not anymore able to login into the
> > webgui.
> > After I have entered the login/password I'm getting the following
> message:
> >
> >
> >
> > And nifi-app.log reports the following error messages:
> >
> >
> >
> > I'm having a wildcard SSL certificate and I'm using the same
> > keystore/truststore combination for three usecases:
> > - for cluster connectivity (in nifi.properties)
> > - in "authorizer.xml"
> > - in "login-identity-providers.xml".
> >
> > The keystore.jks (private/public) keypair has been signed by our internal
> > root CA and the root CA cert has been imported into the truststore.jks.
> As
> > the ldap login works with certificates I'm more or less sure that the
> certs
> > in general are fine. Has anybody an idea if wildcard CN and SAN names
> > should
> > work in a cluster or where the problem could be? I've tried the same
> certs
> > as well in standalone mode, no issue at all.
> >
> > The following parameters in nifi.properties are enabled:
> > nifi.security.needClientAuth=true
> > nifi.cluster.protocol.is.secure=true
> >
> > Thanks in advance
> >
> >
> >
> >
> > --
> > Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Andy LoPresto-2
Hi Jon,

There are automatable, scalable, and non-restart-required ways to horizontally scale a secure cluster without requiring wildcard certificates. I should collect the various instructions / notes together into an article and people can reference that, but until that time, the Admin Guide [1] and the conversation Prashanth and I had on the ticket [2] are the best documentation for this. 

Basically:

* run the TLS toolkit as a server and have each node connect to it to obtain a valid cert. All of these will be signed by the same CA and each node will be able to communicate with all others. Add a new user with the node CN and RW on /proxy resource via the UI/API of the existing nodes. You should not need to modify authorizers.xml directly. 
* same permissions steps but use the toolkit in standalone mode. In this case, you must run it from the same directory every time (so it uses the same CA key to sign). 
* same permissions steps but run toolkit in standalone on each node. In this case, you must import the generated CA into existing node truststores (requires restart). 





Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 18, 2018, at 2:49 PM, Jon Logan <[hidden email]> wrote:

I saw this in the release notes...specifically that wildcard certs are not
supported. How do most people handle this in practice? We can run a cert
server or get them from other means (AWS cert manager, etc) but am not sure
how to overcome the authorizers.xml issue -- would we need to have a
provisioning script register each new server certificate with NiFi before
it can actually do anything useful? Will new servers then have issues
joining because their authorizers will not match the rest of the cluster?

On Thu, Jul 5, 2018 at 8:04 AM, Pierre Villard <[hidden email]>
wrote:

Hi Josef,

I don't have a solution for you but it seems it has already been reported
and a JIRA has been opened:
https://issues.apache.org/jira/browse/NIFI-5370

Andy might be able to give more insights about it.

Pierre

2018-07-05 13:19 GMT+02:00 Josefz <[hidden email]>:

Hi expert

I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured
cluster
with LDAP authentication. Now I'm not anymore able to login into the
webgui.
After I have entered the login/password I'm getting the following
message:



And nifi-app.log reports the following error messages:



I'm having a wildcard SSL certificate and I'm using the same
keystore/truststore combination for three usecases:
- for cluster connectivity (in nifi.properties)
- in "authorizer.xml"
- in "login-identity-providers.xml".

The keystore.jks (private/public) keypair has been signed by our internal
root CA and the root CA cert has been imported into the truststore.jks.
As
the ldap login works with certificates I'm more or less sure that the
certs
in general are fine. Has anybody an idea if wildcard CN and SAN names
should
work in a cluster or where the problem could be? I've tried the same
certs
as well in standalone mode, no issue at all.

The following parameters in nifi.properties are enabled:
nifi.security.needClientAuth=true
nifi.cluster.protocol.is.secure=true

Thanks in advance




--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/




signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Andy LoPresto-2
Just to add on, we are not saying that the current state is acceptable or the easiest to use. NIFI-5398 and NIFI-5443 exist to improve this experience. 

[2] https://issues.apache.org/jira/browse/NIFI-5443


Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 18, 2018, at 3:37 PM, Andy LoPresto <[hidden email]> wrote:

Hi Jon,

There are automatable, scalable, and non-restart-required ways to horizontally scale a secure cluster without requiring wildcard certificates. I should collect the various instructions / notes together into an article and people can reference that, but until that time, the Admin Guide [1] and the conversation Prashanth and I had on the ticket [2] are the best documentation for this. 

Basically:

* run the TLS toolkit as a server and have each node connect to it to obtain a valid cert. All of these will be signed by the same CA and each node will be able to communicate with all others. Add a new user with the node CN and RW on /proxy resource via the UI/API of the existing nodes. You should not need to modify authorizers.xml directly. 
* same permissions steps but use the toolkit in standalone mode. In this case, you must run it from the same directory every time (so it uses the same CA key to sign). 
* same permissions steps but run toolkit in standalone on each node. In this case, you must import the generated CA into existing node truststores (requires restart). 





Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 18, 2018, at 2:49 PM, Jon Logan <[hidden email]> wrote:

I saw this in the release notes...specifically that wildcard certs are not
supported. How do most people handle this in practice? We can run a cert
server or get them from other means (AWS cert manager, etc) but am not sure
how to overcome the authorizers.xml issue -- would we need to have a
provisioning script register each new server certificate with NiFi before
it can actually do anything useful? Will new servers then have issues
joining because their authorizers will not match the rest of the cluster?

On Thu, Jul 5, 2018 at 8:04 AM, Pierre Villard <[hidden email]>
wrote:

Hi Josef,

I don't have a solution for you but it seems it has already been reported
and a JIRA has been opened:
https://issues.apache.org/jira/browse/NIFI-5370

Andy might be able to give more insights about it.

Pierre

2018-07-05 13:19 GMT+02:00 Josefz <[hidden email]>:

Hi expert

I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured
cluster
with LDAP authentication. Now I'm not anymore able to login into the
webgui.
After I have entered the login/password I'm getting the following
message:



And nifi-app.log reports the following error messages:



I'm having a wildcard SSL certificate and I'm using the same
keystore/truststore combination for three usecases:
- for cluster connectivity (in nifi.properties)
- in "authorizer.xml"
- in "login-identity-providers.xml".

The keystore.jks (private/public) keypair has been signed by our internal
root CA and the root CA cert has been imported into the truststore.jks.
As
the ldap login works with certificates I'm more or less sure that the
certs
in general are fine. Has anybody an idea if wildcard CN and SAN names
should
work in a cluster or where the problem could be? I've tried the same
certs
as well in standalone mode, no issue at all.

The following parameters in nifi.properties are enabled:
nifi.security.needClientAuth=true
nifi.cluster.protocol.is.secure=true

Thanks in advance




--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/





signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Peter Wilcsinszky
In reply to this post by Andy LoPresto-2
On Thu, Jul 19, 2018 at 12:38 AM Andy LoPresto <[hidden email]> wrote:

> Hi Jon,
>
> There are automatable, scalable, and non-restart-required ways to
> horizontally scale a secure cluster without requiring wildcard
> certificates. I should collect the various instructions / notes together
> into an article and people can reference that, but until that time, the
> Admin Guide [1] and the conversation Prashanth and I had on the ticket [2]
> are the best documentation for this.
>
> Basically:
>
> * run the TLS toolkit as a server and have each node connect to it to
> obtain a valid cert. All of these will be signed by the same CA and each
> node will be able to communicate with all others. Add a new user with the
> node CN and RW on /proxy resource via the UI/API of the existing nodes.
>


> You should not need to modify authorizers.xml directly.
>

I would highlight that in that case you should use the original
authorizers.xml that do not contain any nodes, not even the initial admin
identity. This way new nodes can figure to accept authorizers information
from the cluster instead of having a conflict and failing to start.
(This failure scenario happened to me when tried to spin up new nodes with
the same authorizers.xml that I used for the inital cluster.)


> * same permissions steps but use the toolkit in standalone mode. In this
> case, you must run it from the same directory every time (so it uses the
> same CA key to sign).
> * same permissions steps but run toolkit in standalone on each node. In
> this case, you must import the generated CA into existing node truststores
> (requires restart).
>
> [1]
> https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#tls-generation-toolkit
> [2] https://issues.apache.org/jira/browse/NIFI-5370
>
>
>
>
> Andy LoPresto
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 18, 2018, at 2:49 PM, Jon Logan <[hidden email]> wrote:
>
> I saw this in the release notes...specifically that wildcard certs are not
> supported. How do most people handle this in practice? We can run a cert
> server or get them from other means (AWS cert manager, etc) but am not sure
> how to overcome the authorizers.xml issue -- would we need to have a
> provisioning script register each new server certificate with NiFi before
> it can actually do anything useful? Will new servers then have issues
> joining because their authorizers will not match the rest of the cluster?
>
> On Thu, Jul 5, 2018 at 8:04 AM, Pierre Villard <
> [hidden email]>
> wrote:
>
> Hi Josef,
>
> I don't have a solution for you but it seems it has already been reported
> and a JIRA has been opened:
> https://issues.apache.org/jira/browse/NIFI-5370
>
> Andy might be able to give more insights about it.
>
> Pierre
>
> 2018-07-05 13:19 GMT+02:00 Josefz <[hidden email]>:
>
> Hi expert
>
> I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured
>
> cluster
>
> with LDAP authentication. Now I'm not anymore able to login into the
> webgui.
> After I have entered the login/password I'm getting the following
>
> message:
>
>
>
>
> And nifi-app.log reports the following error messages:
>
>
>
> I'm having a wildcard SSL certificate and I'm using the same
> keystore/truststore combination for three usecases:
> - for cluster connectivity (in nifi.properties)
> - in "authorizer.xml"
> - in "login-identity-providers.xml".
>
> The keystore.jks (private/public) keypair has been signed by our internal
> root CA and the root CA cert has been imported into the truststore.jks.
>
> As
>
> the ldap login works with certificates I'm more or less sure that the
>
> certs
>
> in general are fine. Has anybody an idea if wildcard CN and SAN names
> should
> work in a cluster or where the problem could be? I've tried the same
>
> certs
>
> as well in standalone mode, no issue at all.
>
> The following parameters in nifi.properties are enabled:
> nifi.security.needClientAuth=true
> nifi.cluster.protocol.is.secure=true
>
> Thanks in advance
>
>
>
>
> --
> Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Jon Logan
Can you clarify that statement? If you have a completely empty
authorizers.xml file, would the node join the cluster and inherit the
clusters authorizers.xml? Also, what would happen if the whole cluster was
restarted? Are changes persisted? And if they are, if a node is restarted
at the same time a new node is added -- would that node not have an
outdated authorizers.xml and get rejected from rejoining?


Thanks again.

On Thu, Jul 19, 2018 at 4:55 AM, Peter Wilcsinszky <
[hidden email]> wrote:

> On Thu, Jul 19, 2018 at 12:38 AM Andy LoPresto <[hidden email]>
> wrote:
>
> > Hi Jon,
> >
> > There are automatable, scalable, and non-restart-required ways to
> > horizontally scale a secure cluster without requiring wildcard
> > certificates. I should collect the various instructions / notes together
> > into an article and people can reference that, but until that time, the
> > Admin Guide [1] and the conversation Prashanth and I had on the ticket
> [2]
> > are the best documentation for this.
> >
> > Basically:
> >
> > * run the TLS toolkit as a server and have each node connect to it to
> > obtain a valid cert. All of these will be signed by the same CA and each
> > node will be able to communicate with all others. Add a new user with the
> > node CN and RW on /proxy resource via the UI/API of the existing nodes.
> >
>
>
> > You should not need to modify authorizers.xml directly.
> >
>
> I would highlight that in that case you should use the original
> authorizers.xml that do not contain any nodes, not even the initial admin
> identity. This way new nodes can figure to accept authorizers information
> from the cluster instead of having a conflict and failing to start.
> (This failure scenario happened to me when tried to spin up new nodes with
> the same authorizers.xml that I used for the inital cluster.)
>
>
> > * same permissions steps but use the toolkit in standalone mode. In this
> > case, you must run it from the same directory every time (so it uses the
> > same CA key to sign).
> > * same permissions steps but run toolkit in standalone on each node. In
> > this case, you must import the generated CA into existing node
> truststores
> > (requires restart).
> >
> > [1]
> > https://nifi.apache.org/docs/nifi-docs/html/administration-
> guide.html#tls-generation-toolkit
> > [2] https://issues.apache.org/jira/browse/NIFI-5370
> >
> >
> >
> >
> > Andy LoPresto
> > [hidden email]
> > *[hidden email] <[hidden email]>*
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On Jul 18, 2018, at 2:49 PM, Jon Logan <[hidden email]> wrote:
> >
> > I saw this in the release notes...specifically that wildcard certs are
> not
> > supported. How do most people handle this in practice? We can run a cert
> > server or get them from other means (AWS cert manager, etc) but am not
> sure
> > how to overcome the authorizers.xml issue -- would we need to have a
> > provisioning script register each new server certificate with NiFi before
> > it can actually do anything useful? Will new servers then have issues
> > joining because their authorizers will not match the rest of the cluster?
> >
> > On Thu, Jul 5, 2018 at 8:04 AM, Pierre Villard <
> > [hidden email]>
> > wrote:
> >
> > Hi Josef,
> >
> > I don't have a solution for you but it seems it has already been reported
> > and a JIRA has been opened:
> > https://issues.apache.org/jira/browse/NIFI-5370
> >
> > Andy might be able to give more insights about it.
> >
> > Pierre
> >
> > 2018-07-05 13:19 GMT+02:00 Josefz <[hidden email]>:
> >
> > Hi expert
> >
> > I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured
> >
> > cluster
> >
> > with LDAP authentication. Now I'm not anymore able to login into the
> > webgui.
> > After I have entered the login/password I'm getting the following
> >
> > message:
> >
> >
> >
> >
> > And nifi-app.log reports the following error messages:
> >
> >
> >
> > I'm having a wildcard SSL certificate and I'm using the same
> > keystore/truststore combination for three usecases:
> > - for cluster connectivity (in nifi.properties)
> > - in "authorizer.xml"
> > - in "login-identity-providers.xml".
> >
> > The keystore.jks (private/public) keypair has been signed by our internal
> > root CA and the root CA cert has been imported into the truststore.jks.
> >
> > As
> >
> > the ldap login works with certificates I'm more or less sure that the
> >
> > certs
> >
> > in general are fine. Has anybody an idea if wildcard CN and SAN names
> > should
> > work in a cluster or where the problem could be? I've tried the same
> >
> > certs
> >
> > as well in standalone mode, no issue at all.
> >
> > The following parameters in nifi.properties are enabled:
> > nifi.security.needClientAuth=true
> > nifi.cluster.protocol.is.secure=true
> >
> > Thanks in advance
> >
> >
> >
> >
> > --
> > Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/
> >
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Bryan Bende
The authorizers.xml supports many different options, such user group
providers for file-based, ldap, or composite, and policy provider for
file-based and ranger.

The concept of inheritance only really applies to the file-based cases
because in the other scenarios like LDAP and Ranger,  the users and
groups are stored external to NiFi, so want to be clear that we are
talking about file-based scenarios here.

In the file-based case, if you have a new node that has no flow, no
users/groups, and no policies, then it will inherit everything from
the cluster.

The common issue is if all the above is true, but you defined an
initial admin or node identity in the authorizers.xml on the new node,
then before joining the cluster it will create the users and policies
locally, and now it no longer matches the cluster. So that is why
Peter pointed out to make sure the those are not populated locally on
the new node.



On Fri, Jul 20, 2018 at 1:44 PM, Jon Logan <[hidden email]> wrote:

> Can you clarify that statement? If you have a completely empty
> authorizers.xml file, would the node join the cluster and inherit the
> clusters authorizers.xml? Also, what would happen if the whole cluster was
> restarted? Are changes persisted? And if they are, if a node is restarted
> at the same time a new node is added -- would that node not have an
> outdated authorizers.xml and get rejected from rejoining?
>
>
> Thanks again.
>
> On Thu, Jul 19, 2018 at 4:55 AM, Peter Wilcsinszky <
> [hidden email]> wrote:
>
>> On Thu, Jul 19, 2018 at 12:38 AM Andy LoPresto <[hidden email]>
>> wrote:
>>
>> > Hi Jon,
>> >
>> > There are automatable, scalable, and non-restart-required ways to
>> > horizontally scale a secure cluster without requiring wildcard
>> > certificates. I should collect the various instructions / notes together
>> > into an article and people can reference that, but until that time, the
>> > Admin Guide [1] and the conversation Prashanth and I had on the ticket
>> [2]
>> > are the best documentation for this.
>> >
>> > Basically:
>> >
>> > * run the TLS toolkit as a server and have each node connect to it to
>> > obtain a valid cert. All of these will be signed by the same CA and each
>> > node will be able to communicate with all others. Add a new user with the
>> > node CN and RW on /proxy resource via the UI/API of the existing nodes.
>> >
>>
>>
>> > You should not need to modify authorizers.xml directly.
>> >
>>
>> I would highlight that in that case you should use the original
>> authorizers.xml that do not contain any nodes, not even the initial admin
>> identity. This way new nodes can figure to accept authorizers information
>> from the cluster instead of having a conflict and failing to start.
>> (This failure scenario happened to me when tried to spin up new nodes with
>> the same authorizers.xml that I used for the inital cluster.)
>>
>>
>> > * same permissions steps but use the toolkit in standalone mode. In this
>> > case, you must run it from the same directory every time (so it uses the
>> > same CA key to sign).
>> > * same permissions steps but run toolkit in standalone on each node. In
>> > this case, you must import the generated CA into existing node
>> truststores
>> > (requires restart).
>> >
>> > [1]
>> > https://nifi.apache.org/docs/nifi-docs/html/administration-
>> guide.html#tls-generation-toolkit
>> > [2] https://issues.apache.org/jira/browse/NIFI-5370
>> >
>> >
>> >
>> >
>> > Andy LoPresto
>> > [hidden email]
>> > *[hidden email] <[hidden email]>*
>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> >
>> > On Jul 18, 2018, at 2:49 PM, Jon Logan <[hidden email]> wrote:
>> >
>> > I saw this in the release notes...specifically that wildcard certs are
>> not
>> > supported. How do most people handle this in practice? We can run a cert
>> > server or get them from other means (AWS cert manager, etc) but am not
>> sure
>> > how to overcome the authorizers.xml issue -- would we need to have a
>> > provisioning script register each new server certificate with NiFi before
>> > it can actually do anything useful? Will new servers then have issues
>> > joining because their authorizers will not match the rest of the cluster?
>> >
>> > On Thu, Jul 5, 2018 at 8:04 AM, Pierre Villard <
>> > [hidden email]>
>> > wrote:
>> >
>> > Hi Josef,
>> >
>> > I don't have a solution for you but it seems it has already been reported
>> > and a JIRA has been opened:
>> > https://issues.apache.org/jira/browse/NIFI-5370
>> >
>> > Andy might be able to give more insights about it.
>> >
>> > Pierre
>> >
>> > 2018-07-05 13:19 GMT+02:00 Josefz <[hidden email]>:
>> >
>> > Hi expert
>> >
>> > I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured
>> >
>> > cluster
>> >
>> > with LDAP authentication. Now I'm not anymore able to login into the
>> > webgui.
>> > After I have entered the login/password I'm getting the following
>> >
>> > message:
>> >
>> >
>> >
>> >
>> > And nifi-app.log reports the following error messages:
>> >
>> >
>> >
>> > I'm having a wildcard SSL certificate and I'm using the same
>> > keystore/truststore combination for three usecases:
>> > - for cluster connectivity (in nifi.properties)
>> > - in "authorizer.xml"
>> > - in "login-identity-providers.xml".
>> >
>> > The keystore.jks (private/public) keypair has been signed by our internal
>> > root CA and the root CA cert has been imported into the truststore.jks.
>> >
>> > As
>> >
>> > the ldap login works with certificates I'm more or less sure that the
>> >
>> > certs
>> >
>> > in general are fine. Has anybody an idea if wildcard CN and SAN names
>> > should
>> > work in a cluster or where the problem could be? I've tried the same
>> >
>> > certs
>> >
>> > as well in standalone mode, no issue at all.
>> >
>> > The following parameters in nifi.properties are enabled:
>> > nifi.security.needClientAuth=true
>> > nifi.cluster.protocol.is.secure=true
>> >
>> > Thanks in advance
>> >
>> >
>> >
>> >
>> > --
>> > Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/
>> >
>> >
>> >
>> >
>>
Reply | Threaded
Open this post in threaded view
|

Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Josefz
@Andy LoPresto

I fully understand what you wrote regarding certs in the admin guide,
however as you already mentioned, in my point of view this certificate stuff
is really a pain. We have lost multiple days to get it running together with
LDAP, just because of the complexity of the whole configuration. And after
the upgrade to 1.7.0 we had again issues because of certs and the bug...

Let me explain why we use wildcard certs. We have to use our company CA and
we have to manually insert the CSR on a website (with some additional
parameters) to get the certificate signed. If we have to do that for 20
nodes or even more, this would be a huge work. Additionally our network
where the NiFi Nodes are, is a subnet secured by a firewall, so it's not
possible to connect from outside through the cluster port. If an attacker is
inside the subnet and is able to create a NiFi Node who can join the cluster
(with the certificate and the password for the keystore), then we would
anyway have bigger problems. But yes of course, wildcard certs are less
secure.

*Two questions for you:*

1. We used the wildcard certs already in NiFi 1.5.0 in our lab, however we
would like to go live with 1.7.1 now. If we haven't seen any issues on NiFi
1.5.0 with the wildcard certs, how likely would it be that we see some
issues on 1.7.1?

2. Somewhere I've read that in an optimal world (eg. with the NiFi TLS
Certkit) we should have a Cert with a unique DN and as well use the same DN
for the SAN per node. Would it be ok to have the following:

3-Node Cluster Environment: nifi-node-1, nifi-node-2, nifi-node-3

One Keystore Certificate for all NiFi nodes with the following attributes:
-> DN "CN=NiFi Apache";
-> SAN = nifi-node-1, nifi-node-2, nifi-node-3

Background is the following, we are planning a loadbalancer in front of NiFi
Webgui and I don't see any solution to get the whole thing work without the
procedure above. Today we use wildcard, with that we are good to go. But as
you already mentioned multiple times that wildcards are not supported we are
looking for some alternatives.

Thanks in advance
Josef



--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/