nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy LoPresto <alopre...@apache.org>
Subject Re: SSLPeerUnverifiedException Hostname "xyz" not verified
Date Wed, 18 Jul 2018 22:37:49 GMT
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).

[1] https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#tls-generation-toolkit
<https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#tls-generation-toolkit>
[2] https://issues.apache.org/jira/browse/NIFI-5370 <https://issues.apache.org/jira/browse/NIFI-5370>




Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Jul 18, 2018, at 2:49 PM, Jon Logan <jmlogan@buffalo.edu> 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 <pierre.villard.fr@gmail.com>
> 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 <josef.zahner1@swisscom.com>:
>> 
>>> 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/
>>> 
>> 


Mime
View raw message