Setting up some security on a test cluster here and it is driving me a bit nuts.
I can see in my kibana log that it is doing this
Line 1359: {"type":"log","@timestamp":"2019-10-18T10:01:31Z","tags":["error","elasticsearch","admin"],"pid":7431,"message":"Request error, retrying\nGET https://10.0.10.70:9200/.kibana/doc/config%3A6.8.0 => Hostname/IP does not match certificate's altnames: IP: 10.0.10.70 is not in the cert's list: "}
In my kibana.yml I have the hosts specified with FQDN and the same in the Elastic hosts yml file, so why is it doing this? Of course the IP is not in the certificate I'm using, but the host name is, it is a *.domain.com certificate so the hosts should be ok. Strange thing is when Kibana starts up, I can access the hosts just fine, it is only after a few minutes they stop working and I can see this in the log file.
curl: (51) SSL: certificate subject name (*.domain.com) does not match target host name '10.0.10.70'
I have the Certificate CA stored in /etc/ssl/certs on my Ubuntu server
So yeah same kind of error, so maybe the problem is originating from the Elastic nodes, I have some other problems with them also, so I have another post with my elasticsearch.yml in here
Think that the issue originates there, as I can see from my "_nodes/_all/settings?pretty"
that is says
What does the elasticsearch.yml look like on the 10.0.10.70 node?
It can take a little bit of magic to get Elasticsearch to publish FQDNs rather than IPs, so it will be easier to give you advice if we can see your starting point.
You're telling ES to bind to site-local IP address(es) of the host on which it is running. It will therefore adverstise itself as running on an IP address and not a FQDN.
When you enable node sniffing, Kibana finds out about nodes that exist according to that address that they advertise. Since your node advertises an IP, Kibana connects via an IP and expects the certificate to make that IP.
If you're using _site_ addresses and TLS certs that use DNS names, then you typically want to set network.publish_host to the FQDN that matches your cert.
yes that looks to be what is happening, but confused about how to make them be able to connect to eachother again, because "discovery.zen.ping.unicast.hosts" is set to the two hosts I have with FQDN - this has always worked fine.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.