Is this a correct assumption? I would think the only way would be to have a cert server and have servers generate certs on initialization? We have our NiFi cluster autoscaling so we'd need this server stood up versus manually provisioning ahead of time. Are there any viable alternatives? And regarding site-to-site visibility, is there a way to change the default so when nodes join they can see ports, etc?
On Fri, Jul 20, 2018 at 7:55 PM, Jon Logan <jmlo...@buffalo.edu> wrote: > The other issue we have is that we would now have to run two additional > separate services in any deployment we would run -- namely, a certificate > server and LDAP. We try to reduce complexity of deployments, but it's stuff > like this that quickly becomes a maintenance burden. > > On Fri, Jul 20, 2018 at 3:51 PM, Josefz <josef.zahn...@swisscom.com> > wrote: > >> @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/ >> > >
