Received plaintext http traffic on an https channel, closing connection Netty4HttpChannel

Buenas tardes,
Soy nueva en estos foros, pero he visto que la mayoría de los problemas que me he encontrado con ELK los he podido solucionar gracias a este foro.

Pero este problema lo llevo arrastrando ya más de 1 mes y no consigo solución. Espero que puedan ayudarme.

Tengo levantado un docker.compose a través de portainer de ELK. Tengo un clúster con 3 nodos, con las comunicaciones cifrazadas habilitados los xpack tanto de transport.ssl como http.ssl con sus certificados. pero le he asignado una ip (red zerotier) al primer nodo y a kibana para poder visualizarlo fuera del servidor como una ip púclica y obtengo este error:

{"type": "server", "timestamp": "2021-03-11T14:17:09,806Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "received plaintext http traffic on an https channel, closing connection Netty4HttpChannel{localAddress=/172.25.0.2:9200, remoteAddress=/192.168.195.46:36496}", "cluster.uuid": "6lZ4D79BR22M8RjMXSfSwQ", "node.id": "MFx7WpgIQ2uFpFoUfZZ1PQ" },
{"type": "server", "timestamp": "2021-03-11T14:17:10,920Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "received plaintext http traffic on an https channel, closing connection Netty4HttpChannel{localAddress=/172.25.0.2:9200, remoteAddress=/192.168.195.46:36498}", "cluster.uuid": "6lZ4D79BR22M8RjMXSfSwQ", "node.id": "MFx7WpgIQ2uFpFoUfZZ1PQ" },
{"type": "server", "timestamp": "2021-03-11T14:17:10,956Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "received plaintext http traffic on an https channel, closing connection Netty4HttpChannel{localAddress=/172.25.0.2:9200, remoteAddress=/192.168.195.46:36500}", "cluster.uuid": "6lZ4D79BR22M8RjMXSfSwQ", "node.id": "MFx7WpgIQ2uFpFoUfZZ1PQ" },
{"type": "server", "timestamp": "2021-03-11T14:17:11,027Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "received plaintext http traffic on an https channel, closing connection Netty4HttpChannel{localAddress=/172.25.0.2:9200, remoteAddress=/192.168.195.46:36502}", "cluster.uuid": "6lZ4D79BR22M8RjMXSfSwQ", "node.id": "MFx7WpgIQ2uFpFoUfZZ1PQ" },
{"type": "server", "timestamp": "2021-03-11T14:17:14,325Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "http client did not trust this server's certificate, closing connection Netty4HttpChannel{localAddress=/172.25.0.2:9200, remoteAddress=/192.168.195.46:36526}", "cluster.uuid": "6lZ4D79BR22M8RjMXSfSwQ", "node.id": "MFx7WpgIQ2uFpFoUfZZ1PQ" },
{"type": "server", "timestamp": "2021-03-11T14:17:14,329Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "http client did not trust this server's certificate, closing connection Netty4HttpChannel{localAddress=/172.25.0.2:9200, remoteAddress=/192.168.195.46:36524}", "cluster.uuid": "6lZ4D79BR22M8RjMXSfSwQ", "node.id": "MFx7WpgIQ2uFpFoUfZZ1PQ" },
{"type": "server", "timestamp": "2021-03-11T14:17:14,507Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "http client did not trust this server's certificate, closing connection Netty4HttpChannel{localAddress=/172.25.0.2:9200, remoteAddress=/192.168.195.46:36530}", "cluster.uuid": "6lZ4D79BR22M8RjMXSfSwQ", "node.id": "MFx7WpgIQ2uFpFoUfZZ1PQ" }

Espero que puedan ayudarme. Gracias

Hola Andrea,

Disculpas por cualquier español deficiente, he usado el traductor de Google en mis respuestas en inglés, pero espero que esto tenga sentido.

Esto significa que el cliente realizó una solicitud no cifrada (a través de HTTP) pero Elasticsearch requiere cifrado (a través de HTTPS). Debe ajustar este cliente para usar HTTPS en lugar de HTTP.

(This means the client made an unencrypted request (over HTTP) but Elasticsearch requires encryption (over HTTPS). You need to adjust this client to use HTTPS instead of HTTP)

Esto significa que el cliente no confiaba en el certificado que Elasticsearch presentó como prueba de su identidad. Debe configurar el cliente para que confíe en la autoridad de certificación que emitió el certificado que Elasticsearch está usando para el tráfico HTTPS.

(This means the client did not trust the certificate that Elasticsearch presented as a proof of its identity. You need to configure the client to trust the certificate authority that issued the certificate that Elasticsearch is using for HTTPS traffic)

Hola David,

Muchas gracias por la respuesta tan rápida, no te preocupes por el idioma te he entendido perfectamente.

Haciendo referencia a tu respuesta, comentarte que los certificados dentro del docker, se han realizado siguiendo los pasos de la página oficial de Elasticsearch (Running the Elastic Stack on Docker | Getting Started [7.11] | Elastic)

Entonces, ¿tendría que tocar alguna configuración del servidor para que confíe en el certificado? También tengo configurada mi archivo '/etc/hosts' con la ip que le asignado a Elasticsearch y el nombre que le he otorgado a elasticsearch.hosts.

También le proporciono la ip y dns en el archivo instances.yml que coinciden con lo que tengo en el archivo '/etc/hosts' y en la variable "elasticsearch.hosts" y "elasticsearch.url" de Kibana. Adjunto fotos de los archivos de configuración.

instances_elk

Espero que puedas ayudarme. Muchas gracias.

Un saludo,
Andrea

Hola Andrea,

¿Su instalación de Kibana funciona? Si es así, este Kibana no está causando estos mensajes. Creo que hay otro cliente. Su dirección es 192.168.195.46. Elasticsearch no conoce más detalles sobre este cliente, necesitará usar otros métodos para averiguar qué se está ejecutando en esa dirección y qué causa estos mensajes.

(Does your Kibana installation work? If so, this Kibana is not causing these messages. I think there is another client. Its address is 192.168.195.46. Elasticsearch doesn't know any more detail about this client, you will need to use other methods to find out what is running at that address and causing these messages.)

Hola David,

La instalación de Kibana si funciona, el mensaje de esa dirección "192.168.195.46" me la proporciona Elasticsearch, pero yo no he configurado nada para esa dirección. Pero en el navegador puedo ver kibana y elasticsearch.

Adjunto imagenes de las urls de Elasticsearch y Kibana:

"url_elasticsearch=hhtps//:192.168.195.9:9200" and "url_kibana=https://192.168.195.9:5601"

url_elasticsearch

Entonces no entiendo el mensaje de error, si me deja acceder a las paginas.

Hola David,

sigo con el mismo error y no puedo encontrar que cliente esta llamando a esa dirección ip. Lo más asombroso es que puedo conectarme tanto a Kibana como a ElasticSearch en mi navegador y las comunicaciones entre clúster y nodos están cifradas con sus respectivos certificados. Pero no entiendo porque el network de docker entra en conflicto con la ip que le asigno y me proporciona esos errores en el log.

{"type": "server", "timestamp": "2021-03-12T09:54:32,451Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "http client did not trust this server's certificate, closing connection Netty4HttpChannel{localAddress=/172.27.0.5:9200, remoteAddress=/192.168.195.46:43734}", "cluster.uuid": "Jcf-oGubTKymE7YEdqPFhQ", "node.id": "m9hN9MgJTvGcI6OK_frzOw" },
{"type": "server", "timestamp": "2021-03-12T09:54:32,451Z", "level": "WARN", "component": "o.e.x.s.t.n.SecurityNetty4HttpServerTransport", "cluster.name": "es-prod", "node.name": "server1", "message": "http client did not trust this server's certificate, closing connection Netty4HttpChannel{localAddress=/172.27.0.5:9200, remoteAddress=/192.168.195.46:43736}", "cluster.uuid": "Jcf-oGubTKymE7YEdqPFhQ", "node.id": "m9hN9MgJTvGcI6OK_frzOw" },
{"type": "server", "timestamp": "2021-03-12T09:51:38,936Z", "level": "INFO", "component": "o.e.x.s.a.AuthenticationService", "cluster.name": "es-prod", "node.name": "server1", "message": "Authentication of [elastic] was terminated by realm [reserved] - failed to authenticate user [elastic]", "cluster.uuid": "Jcf-oGubTKymE7YEdqPFhQ", "node.id": "m9hN9MgJTvGcI6OK_frzOw" }

Te proporciono más información sobre mis logs y si necesita alguna información más sobre mi configuración no dudes en decírmelo, espero poder solucionar este error.

Muchas gracias por todo,
un saludo

No entiendo a qué conflictos te refieres. Creo que hay otro proceso que intenta acceder a Elasticsearch desde 192.168.195.46. Tal vez otro Kibana con una mala configuración, tal vez algo completamente diferente. ¿Quizás pueda averiguar qué es con ps o netstat -antp? Realmente no puedo ayudar, esta es más una cuestión de administración del sistema que cualquier cosa que tenga que ver con Elasticsearch.


(I don't understand which conflicts you mean. I think there is another process trying to access Elasticsearch from 192.168.195.46. Maybe another Kibana with a bad config, maybe something else entirely. Perhaps you can work out what it is with ps or netstat -antp? I cannot really help, this is more of a system administration question than anything to do with Elasticsearch.)

Buenas David,

Creo que he encontrado la razón de porque aparece otra ip escuchando. Tengo montado también en mi ordenador un Elastic y Kibana para poder trabajar el local y no tocar este ELK porque lo tenemos en producción.

¿Puede ser que las ips entren en conflicto por eso? Porque justo esa ip coincide que es la de mi ordenador, la correspondiente a la red zerotier.

¿Sabrías alguna forma de redirigir mi ELK de producción a la ip que le he concedido en la configuración y que ignore ese WARN ?

Gracias por todo. Un saludo

Quizás, si su Kibana local está configurado para conectarse a este Elasticsearch.

Creo que no hay "conflicto de IP", es solo un cliente con la configuración incorrecta.

La solución es arreglar la configuración del cliente que está causando los problemas. No creo que puedas arreglar esto en Elasticsearch en sí.


Maybe, if your local Kibana is configured to connect to this Elasticsearch.

There is no "IP conflict" I think, it is just a client with the wrong configuration.

The solution is to fix the configuration of the client that is causing the problems. I don't think you can fix this in Elasticsearch itself.

Buenas David,

He comprobado mi Elasticsearch "local" y no estaba configurado para que se conectara a Kibana que tengo montado en otro servidor a través de docker y redirigido con una red zerotier para poder acceder a el desde fuera del servidor.

De todas maneras, estoy intentando solucionar la configuración de docker, que es el cliente donde tenemos Elasticsearch y Kibana para poder modificar ese error. Todavía sin éxito. Muchas gracias por tu ayuda.

Ahora tengo que solucionar el problema con el certificado de la empresa para proporcionárselo a Elasticsearch, que de momento tampoco lo he conseguido.

Gracias por todo. Un saludo

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