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 [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jul 18, 2018, at 2:49 PM, Jon Logan <[email protected]> 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 <[email protected]> > 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 <[email protected]>: >> >>> 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
Description: Message signed with OpenPGP using GPGMail
