Https Client Authentication Verify Hostname

Hallo ,

I have an https client to ES and using Self Signed Certificates with client authentication on. I am using PKI realm and have mapped the DN to a role. Things work fine for me.

But, authentication the hostname of the client in the client certificate does not work.

X-Pack/ES Version 6.1.3


          path: ${ES_PATH_CONF}/x-pack/${HOSTNAME}.p12
          type: PKCS12
        certificate_authorities: ${ES_PATH_CONF}/x-pack/Root_CA_01.cer
        supported_protocols: TLSv1.2
        client_authentication: required
        verification_mode: full
        audit.enabled: true
          ssl.enabled: true
          ssl.client_authentication: optional
            enabled: false
              - localhost
              - ${F5_HEALTH_CHECK_IP1}
              - ${F5_HEALTH_CHECK_IP2}
              - ${F5_IP}
              ### START Ip-Whitelist
              ### END Ip-Whitelist
            deny: _all
          ssl.enabled: true
            enabled: false
            roles: health_check
            authz_exception: true
              type: file
              order: 0
              enabled: true
              type: native
              order: 1
              enabled: true
              type: pki
              order: 2
              enabled: true

Viele Grüße


Please make the effort to format your post to be as readable as possible - there's a live preview panel for exactly this reasons. In particular, when providing your settings, surround them in a code block ( the </> button, or gated by three backticks: ```)

Lots of people read these forums, and many of them will simply skip over a post that is difficult to read, because it's just too large an investment of their time to try and follow a wall of badly formatted text.
If your goal is to get an answer to your questions, it's in your interest to make it as easy to read and understand as possible.

From your question, I take it that you are expecting that the setting should be looking at the hostname inside the SSL certificate.
We don't do that. IP filtering is done based on IP addresses, not SSL certificate contents.

I think I expressed myself here in a misleading way. Here's an example:
Client connects to an ES server with a client certifact issued to server, then it works via http. This does not work via the transport protocol. here comes the exception :

[2018-06-20T12:43:57,367][WARN ][o.e.x.s.t.n.SecurityNetty4Transport] [ls01167y] exception caught on transport layer [org.elasticsearch.transport.netty4.NettyTcpChannel@3fc458c9], closing connection
io.netty.handler.codec.DecoderException: Received close_notify during handshake


Caused by: Received close_notify during handshake


Why is not the connection denied via http?

Viele Grüße


The short answer is because transport and http are different.

When you say it does not work via transport do you mean transport-client, or as a node in the cluster?

Yes, mean a transport-Client as a node in the Cluster.

Is ther no way to verify that Client and Client-Zertifkat go togethter via http?

Viele Grüße


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