ElasticSearch XPack - PKI Realm authentication defaults to native authentication

Elastic Stack Elasticsearch
1

Hi, I am using ES version 7.6.2.

I'm trying to set up a PKI authentication in my ES cluster, my elasticsearch.yml looks like this. Although the transport security configuration is not relevant, I post it anyway:

# Transport
xpack.security.transport.ssl.verification_mode: full
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.key: /etc/elasticsearch/certs/eskey.pem
xpack.security.transport.ssl.key_passphrase: "1234"
xpack.security.transport.ssl.certificate: /etc/elasticsearch/certs/escert.pem
xpack.security.transport.ssl.certificate_authorities: [ "/etc/elasticsearch/certs/cacert.pem" ]

# HTTP
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.client_authentication: "required"
xpack.security.http.ssl.key: /etc/elasticsearch/certs/eskey.pem
xpack.security.http.ssl.key_passphrase: "1234"
xpack.security.http.ssl.certificate: /etc/elasticsearch/certs/escert.pem
xpack.security.http.ssl.certificate_authorities: [ "/etc/elasticsearch/certs/cacert.pem" ]

# ---------------------------------- PKI ---------------------------------------
xpack:
  security:
    authc:
      realms:
        pki:
          pki1:
            order: 1
            certificate_authorities: "/etc/elasticsearch/certs/cacert.pem"
        native:
          nt1:
            order: 2

Then, I am trying to authenticate with curl using a client certificate (kbcert.pem) signed with the CA certificate /etc/elasticsearch/certs/cacert.pem specified in the configuration above:

curl https://localhost:9200/_security/_authenticate\?pretty \ --key kbkey.pem --cert kbcert.pem --cacert /etc/elasticsearch/certs/cacert.pem -v

However, the authentication fails with a 401 code. I don't know why it defaults to a native authentication although I'm using a correct certificate:

*  SSL certificate verify ok.
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
> GET /_security/_authenticate?pretty HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.58.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Bearer realm="security"
< WWW-Authenticate: ApiKey
< WWW-Authenticate: Basic realm="security" charset="UTF-8"
< content-type: application/json; charset=UTF-8
< content-length: 734
< 
{
  "error" : {
    "root_cause" : [
      {
        "type" : "security_exception",
        "reason" : "missing authentication credentials for REST request [/_security/_authenticate?pretty]",
        "header" : {
          "WWW-Authenticate" : [
            "Bearer realm=\"security\"",
            "ApiKey",
            "Basic realm=\"security\" charset=\"UTF-8\""
          ]
        }
      }
    ],
    "type" : "security_exception",
    "reason" : "missing authentication credentials for REST request [/_security/_authenticate?pretty]",
    "header" : {
      "WWW-Authenticate" : [
        "Bearer realm=\"security\"",
        "ApiKey",
        "Basic realm=\"security\" charset=\"UTF-8\""
      ]
    }
  },
  "status" : 401
}
* Connection #0 to host localhost left intact

I hope you can help me out on this.

2

Can we see all the lines above :

What does elasticsearch prints in its logs around that time?

3

Sure, the certificate information is hidden if you don't mind:

* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9200 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: cacert.pem
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Client hello (1):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=**; ST=****; L=****; O=****; CN=****; emailAddress=****
*  start date: Apr 16 22:16:26 2020 GMT
*  expire date: Apr 11 22:16:26 2040 GMT
*  subjectAltName: host "localhost" matched cert's "localhost"
*  issuer: C=**; ST=****; L=****; O=****; CN=****; emailAddress=****

When I send the curlauthentication request of my previous message, nothing gets printed in the logs, so I don't find useful copying the log file here.

Please note that I am using a basic license, I'm not sure if that makes ES ignore the PKI authorization and use the native authentication. If that is the default ES behavior, please let me know.

4

The PKI realm is not available in Basic license ( see here, scroll down for security ). You can start a trial license for 30 days and try this out if you want

1 Like
5

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