Hi,
I have set "xpack.security.http.ssl.enabled: true" in elasticsearch.yml. Then I found that I can't connect Kibana to this elasticsearch node.
So how to configure Kibana in such a case?
Hi @li_jessen2016,
Could you please share the logs and config file for further investigation ?
Hope, you have read the below documentation for xpack SSL configuration.
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/configuring-tls.html#tls-http
Regards,
Harsh Bajaj
error [11:44:43.795] [fatal][root] Error: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
at Object.createSecureContext (_tls_common.js:104:17)
at Server (_tls_wrap.js:819:25)
at new Server (https.js:60:14)
at Object.createServer (https.js:82:10)
at module.exports.internals.Core._createListener (/home/jli/kibana-6.5.4-linux-x86_64/node_modules/hapi-latest/lib/core.js:493:79)
at new module.exports.internals.Core (/home/jli/kibana-6.5.4-linux-x86_64/node_modules/hapi-latest/lib/core.js:110:30)
at new module.exports (/home/jli/kibana-6.5.4-linux-x86_64/node_modules/hapi-latest/lib/server.js:25:18)
at Object.createServer (/home/jli/kibana-6.5.4-linux-x86_64/src/core/server/http/http_tools.js:70:20)
at HttpServer.start (/home/jli/kibana-6.5.4-linux-x86_64/src/core/server/http/http_server.js:40:36)
at HttpService.start (/home/jli/kibana-6.5.4-linux-x86_64/src/core/server/http/http_service.js:45:38)
at
at process._tickCallback (internal/process/next_tick.js:189:7)
at Function.Module.runMain (module.js:696:11)
at startup (bootstrap_node.js:204:16)
at bootstrap_node.js:625:3
FATAL Error: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
The docs for this are here:
Step 1 is optional, step 2 is what applies to the issue you're facing
Step1 is optional? You mean there is no need to set this:
server.ssl.enabled: true
server.ssl.key: /path/to/your/server.key
server.ssl.certificate: /path/to/your/server.crt ?
Step2, I have a CA for Elasticsearch node, should I apply this file to the elasticsearch.ssl.certificateAuthorities: /path/to/your/cacert.pem? I have already done so.
Hi @li_jessen2016,
Could you please tell me how you generating ssl certificate?
This message digital envelope routines: EVP_DecryptFInal_ex: bad decrypt
can also occur when you encrypt and decrypt with an incompatible versions of openssl.
Regards,
Harsh Bajaj
Those settings control whether Kibana listens over SSL. It is possible to have Kibana listening on plaintext http
while Elasticsearch listens on SSL https
.
So, yes it is optional and is unrelated to the original question you were asking about how to get Kibana to talk to an ES node that uses SSL.
Yes, you should.
I am using the already existing SSL certificate of elasticsearch node, which has been proven to be effective, for the Server certificate of Kibana. Is that acceptable?
I have disabled server.ssl settings by setting "server.ssl.enabled: false", and also # the following settins:
#server.ssl.certificate:
#server.ssl.key:
while using the CA of already existing one of elasticsearch for setting "elasticsearch.ssl.certificateAuthorities".
It runs with no error, but the browser returns
What does it mean? Does it mean that it is required to set server.ssl, i.e. step 1?
I think you are wrong. If you enable https to elasticsearch, you must also enable https between kibana server and browser, otherwise it shows "a secured connection is required for log in".
I have worked it out.
I am correct. I have a 6.6.0 install running here with TLS on Elasticsearch but not for Kibana.
As @ikakavas told you in that other thread, the problem with
A secure connection is required for log in
Is because you told Kibana that it needs to use secure cookies (cookies that will only be sent over https) but weren't using https. That seems to be a configuration problem on your side - it's not an inherent requirement of the platform.
In my practice, I just tried again. If you set
xpack.security. enabled: true
in the elasticsearch.yml, then you have to set
elasticsearch.url: "https://hostname:9200"
rather than
elasticsearch.url: "http://hostname:9200"
in kibana.yml. So in this case, if you still set
server.ssl.enabled: false
in kibana.yml, you will find the browser displaying "A secure connection is required for log in".
So tell me if I am wrong.
Yes, this is correct but irrelevant and unrelated to the rest of your message. The settings above control how Kibana communicates internally with Elasticsearch.
Why do so and why do you conflate this with any of the above ? I have explained to you in the other thread why you get the "A secure connection is required for log in" error when you set server.ssl.enabled: false
. It is entirely unrelated to whether you set xpack.security.enabled: true
in the elasticsearch.yml
, it will happen regardless.
My practice shows that for kibana to connect to elasticsearch via https, you must set
server.ssl.enabled: true
, otherwise you get the error message of "a secured connection is required for login". This is in conflict with what @Timv wrote as above.
Li, this is simply not correct. If you come to this conclusion, there is something else you are doing wrong and we're trying to explain this to you and help you understand. I will restate that server.ssl.enabled: true
controls how your browser connects to kibana and not how Kibana connects to Elasticsearch. We resolved the "a secured connection is required for login" issue in the other thread, and we did not resolve this by changing the xpack.security. enabled: true
or the elasticsearch.url
settings. so I'm not really sure why you still insist that these are somehow connected.
I don't know how else to explain this.
You mean that the kibana don't need to set server.ssl.enabled:true
to have secured connection to elasticsearch via https://elasticsearch-hostname:9200
? Yes, it's true. But under this circumstance, when you use browser to connect to kibana server via http:kibana-hostname:5601
, it would display that "a secured connection is required for log in". So from a client point of view, besides the browser, do you have any other ways to implement the functions of kibana, say, visualization of data search result?
I'm glad we can finally agree on something
Can we also agree that this has NOTHING to do with how kibana communicates with Elasticsearch and as such with the xpack.security. enabled: true
in or the elasticsearch.url
settings ?
The "circumstance" you mention is the missing server.ssl.enabled:true
and this error only has to do with that. I explained to you why this error occurs in my answer in What does "A secure connection is required for log in" mean? - #2 by ikakavas
There is no need for provoking questions. The only thing we have been trying to explain to you is that the way that Kibana communicates with Elasticsearch (via TLS on https://elasticsearch-hostname:9200
or plain http on http://elasticsearch-hostname:9200
) has NOTHING to do with the error above. Can we just agree upon that and move on ?
If xpack.security. enabled: false
in elasticsearch.yml, then there would be no display of warning message of "a secured connection is required for log in"
on browser with http://kibana-hostname:5601
when I set server.ssl.enabled:false
and elasticsearch.url: "http://el.node.cn:9200"
in kibana.yml.
I guess that the warning message of "a secured connection is required for log in"
is for the security of user name and password input via browser, which is only required when xpack.security. enabled: true
in elasticsearch.yml. So I don't think it has nothing to do with elasticsearch security settings, though the secured connection between elasticsearch node and kibana node is not dependent on server.ssl
settings in kibana.yml.
Or, In plain words, it's something similar to the relationship between condition A and condition B.
Condition A is not dependent on condition B, while condition B is reliant on condition A.
Well, obviously if you disabled security entirely then there is no longer a login page, and consequently you don't get a warning message on that (non-existent) login page.
But that warning isn't caused by enabling security, it is caused by enabling secure cookies without using a secure (https) channel between the browser and Kibana.
You can also make that message go away by shutting down your Elasticsearch cluster. In that case you will get a "Cannot connect to Elasticsearch" error, rather than a "secure connection" error. But that doesn't mean that this error is caused by having your Elasticsearch cluster online.
To try and summarise what we have been trying to explain in this thread.
- If you enabled TLS on the HTTP (Rest) interface for Elasticsearch, then you also need to configure Kibana to communicate with Elasticsearch over
https
. - Depending on how you configured TLS in Elasticsearch, you will probably also need to configure some
elasticsearch.ssl.*
settings. - None of that requires that you enable
https
for Kibana access (server.ssl.enabled
). - You can, and probably should, configure Kibana to use ssl (via
server.ssl.enabled
,server.ssl.certificate
, andserver.ssl.key
), but it is not required. - If you enable secure cookies in Kibana (
xpack.security.secureCookies: true
), then you will need to enablehttps
in Kibana, either through a proxy or viaserver.ssl.enabled
- If you have security enabled in the Elastic Stack, and enable secure cookies in Kibana but do not use
https
then you will get the a secured connection is required error on the login page. This is true, regardless of whether Kibana is usinghttps
to connect to Elasticsearch (that is, whetherelasticsearch.hosts
is ahttps
URL in kibana.yml, and whetherxpack.security.http.ssl.enabled
is true in elasticsearch.yml).
You keep trying to tell us that our advice is wrong, but you haven't provided any example configuration files to show what you have tried to set up.
When we try and explain what is happening, you seem to ignore what we are telling you, and argue with about how you tried and it didn't work (but never show us what you tried, and how that relates to our explanations).
We have invested a lot of time into trying to help you solve this problem. If you want our assistance then please listen to what we are telling you, show us how you have tried to implement it, and stop arguing that we're wrong.