What does "A secure connection is required for log in" mean?

When I enables secured transmission (TLS/SSL) in both elasticsearch and kibana, I got the following window after running both app successfully. What does it mean? And what should I do next?

It means that you have set secureCookies to true in kibana.yml and you haven't enabled TLS for http in Kibana.

Setting secureCookies means that the session cookie gets the secure flag set which means that your browser will only send it over https connections. But the fact that TLS for http is not enabled in Kibana, it means that your browser is not communicating over https with Kibana and as such cannot send the session cookie, leaving Kibana unable to keep you logged in. This is why you get this error up front, so that you can correct your configuration.

2 Likes

You mean that I need "Configure Kibana to encrypt communications between the browser and the Kibana server" as the url you provided?

Depends on what you want to do. Cookies with secure flag work only over https connections.

You can either:

  • Enable secureCookies and configure TLS for http in kibana ( This is the "Configure Kibana to encrypt communications between the browser and the Kibana server" part)
  • Disable secureCookies if for any reason you don't want to use https for accessing Kibana
1 Like

It is really not a simple task. It cost me around 6 hours to figure it out. Some facts are missing in the online documents of Elasticsearch.
I am using CentOS 7, elasticsearch and kibana 6.5.

(1) generate server certificate for kibana

Use elasticsearch-certutil in the installation directory of elasticsearch, since kibana installation directory has no such utility

details see: https://www.elastic.co/guide/en/elasticsearch/reference/current/certutil.html

But you need to create a yml file for the setting of subject Alternative name, which is indispensable for TLS/SSL certification by chrome browser.

In my case, it is kibanacert.yml and its contents are:

instances:
 - name: "kibana-server"
   dns:
        - "kibana.node.cn"

Here “ kibana.node.cn” is the subject Alternative name.

Also, you need to specify --pem for the output of separate key and certificate files rather than a single .P12 file, from which cert and key files derived can’t be parsed by kibana ( it is probably a bug of kibana). In my case, it is:

$ elasticsearch-certutil cert --silent --pem --in kibanacert.yml --out kibana-server.zip

it would prompt you with password, you just input your password and it would succeed.

Now you have kibana-server.zip file, move it to kibana installation directory.

$unzip kibana-server.zip

it would create two new directories, one named ca for storing of ca.crt, which is “Elastic Certificate Tool Autogenerated CA”, the other named kibana-server for storing of kibana-server.crt which is the certificate of kibana server, and kibana-server.key, which is the private key of kibana server.

(2) Set kibana host address in kibana.yml

In the config/kibana.yml, Specifies the address to which the Kibana server will bind.

server.host: kibana.node.cn

Please note that it must be set the same as the subject Alternative name of the certificate generated above.

In root mode, add the host name in /etc/hosts, i.e. add one line with the ip address of the server followed by space and the host name, otherwise the browser can’t parse the host name.

10.xx.xx.xx kibana.node.cn

(3) Set server certificate and private key in kibana.yml

In config/kibana.yml , enables SSL and paths to the PEM-format SSL certificate and SSL key files, respectively.

server.ssl.enabled: true

server.ssl.certificate: /path to the certificate/kibana-server.crt

server.ssl.key: /path to the key/kibana-server.key

(4) Configure Kibana to connect to Elasticsearch via HTTPS:

Just follow the steps in

https://www.elastic.co/guide/en/kibana/current/configuring-tls.html#configuring-tls

elasticsearch.ssl.certificateAuthorities:

must be the same as the one you created for elasticsearch.

(5) run bin/kibana

should run successfully

(6) import certificate files in chrome browser

Merge the certificate and key into one .p12 file

openssl pkcs12 -export -out kibana-server.p12 -inkey kibana-server.key -in kibana-server.crt

The kibana-server.p12 file is created.

In the Chrome Settins→Advanced→Manage certificate, in “Your certificate”, import the kibana-server.p12. In “Authorities”, import the ca.crt and select “Trust this certificate for identifying website”.

(7) run chrome browser

https://kibana.node.cn:6501

It would display a window for you to log-in If your Elasticsearch is protected with basic authentication or it would automatically connect to elasticsearch. Now it is done.

Thanks for the feedback. We would appreciate more details on what you think is missing, or you can open a Github issue directly.

I will add some comments to your previous answer as some things are amiss , in case someone having similar issues comes across this thread:

If the end goal here is to generate a self signed certificate, one can also use openssl, it is not necessary to use certutil if it is not available at the time or the machine used. For example:

openssl req -x509 -newkey rsa:4096 -keyout kibana-server.key -out kibana-server.crt -subj '/CN=kibana.node.cn' -days 365

This is not true. Chrome (and all other major browsers) can handle hostname validation just fine when the host name matches the CN of the certificate. What matters, and I think this is what caused issues for you, is that if you add a SAN in the certificate then it has to be correct as the browser will disregard the CN and try to match the SAN.

This is not a bug per se, but rather a known limitation. As you can see in our documentation , both server.ssl.certificate and server.ssl.key are defined as

Paths to the PEM-format SSL certificate and SSL key files, respectively.

This is only required for your use case, which is that you want to access Kibana on kibana.node.cn while it's running on localhost. This is also why it is applicable/advisable to generate a self-signed certificate for Kibana, and instruct your browser to explicitly trust this by importing it as you specify below.

This is best practice and users should be encouraged to do this, but as both I and @TimV explained to you in this and your other post, this has nothing to do with the error message you get in Kibana.

I tried several times with my chrome browser and found that the subject Alternative Name needs to be presented in the certificate and should be the same as the hostname you input in your browser address line. The CN doesn't work. It is probably because

Support for commonName matching in Certificates (removed)

, which I found on google.

This is not a bug per se, but rather a known limitation. As you can see in our documentation , both server.ssl.certificate and server.ssl.key are defined as

The elasticsearch-certutil can generate two types of certificate, one is pkcs12 file which integrates both the certificate and the private key, the other is separate *.crt and *.key file. I tried pkcs12 file, and extracted .crt and .key file from it, and found that running bin/kibana error, saying decrypt error of the certificate. And I have compared the .crt and .key files derived directly from elasticsearch-certutil with option --pem, to the .crt and .key files extracted from the pkcs12 file generated from elasticsearch-certutil, finding that the previous two are smaller. And I guess that this is some sort of incompatibility of elasticsearch stack.

I tried several times with my chrome browser and found that the subject Alternative Name needs to be presented in the certificate and should be the same as the hostname you input in your browser address line. The CN doesn't work.

I stand corrected, this is true. The same behavior is true for Firefox but only applies to CA signed certificates ( 1245280 - don't fall back to subject common name for name information for new certificates ) , which would explain why I haven't come across this before. Thanks for the follow up !

  • This is unrelated to the behavior you described before as a bug, my previous answer was addressing that.
  • If you provide the exact steps for reproduction, then we would be able to explain to you exactly what happens. I can only assume that when you exported the key and certificate files from the PKCS#12 with openssl, you added a password to the private key file but then failed to set server.ssl.keyPassphrase in kibana.yml so kibana could not decrypt the private key and use it. This would explain both the error you got and the fact that the file had different size.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.