Https Client Authentication Verify Hostname

Elastic Stack Elasticsearch
1

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
Settings:

    .
    .
    .

    xpack:
      ssl:
        keystore:
          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
      security:
        audit.enabled: true
        http:
          ssl.enabled: true
          ssl.client_authentication: optional
          filter:
            enabled: false
            allow:
              - localhost
              - ${F5_HEALTH_CHECK_IP1}
              - ${F5_HEALTH_CHECK_IP2}
              - ${F5_IP}
              ### START Ip-Whitelist
              ### END Ip-Whitelist
            deny: _all
        transport:
          ssl.enabled: true
          filter:
            enabled: false
        authc:
          anonymous:
            roles: health_check
            authz_exception: true
          realms:
            file:
              type: file
              order: 0
              enabled: true
            native:
              type: native
              order: 1
              enabled: true
            pki1:
              type: pki
              order: 2
              enabled: true
            ldap1:
    .
    .
    .
    .

Viele Grüße

Dietmar

2

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.

3

From your question, I take it that you are expecting that the xpack.security.http.filter.allow 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.

4

I think I expressed myself here in a misleading way. Here's an example:
Client ls0001y.company.com connects to an ES server wa9901y.company.com with a client certifact issued to server ls0002y.company.com, 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: javax.net.ssl.SSLException: Received close_notify during handshake

.

Caused by: javax.net.ssl.SSLException: Received close_notify during handshake

.

Why is not the connection denied via http?

Viele Grüße

Dietmar

5

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?

6

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

Dietmar

7

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