Use curl for PKI realm authentication

Is it possible to use curl - for client PKI realm authentication? I know that we can fulfill file realm authentication by using curl -u username:password ... . But how to present client x509 certificate for PKI realm authentication with curl?


See the --key and --cert options :

Are you sure? I tried but failed. It maybe for client certificate in the case of bi-directional certification of TSL. Not for authentication of PKI realm.

This is not enough information for us to be able to assist you further.

  • What did you try and what and how it failed ?
  • What is your elasticsearch PKI realm configuration ?
  • What did you use as a certificate and key with curl ?
  • What was the error you got in curl ?
  • What was printed out in the elasticsearch logs?

It maybe for client certificate in the case of bi-directional certification of TSL. Not for authentication of PKI realm.

PKI realm authentication IS TLS client authentication.

I use the curl:
curl -v --cacert ./config/certs/ca-test.crt --cert ./cl-cert/cl-cert.pem --key ./cl-cert/clKey.pem

The response is :

  • About to connect() to port 9200 (#0)
  • Trying
  • Connected to ( port 9200 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: ./config/certs/ca-test.crt
    CApath: none
  • SSL connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • Server certificate:
  • subject:
  • start date: Jan 19 15:08:02 2019 GMT
  • expire date: Jan 18 15:08:02 2022 GMT
  • common name:
  • issuer: CN=Elastic Certificate Tool Autogenerated CA

GET / HTTP/1.1
User-Agent: curl/7.29.0
Accept: /

< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Bearer realm="security"
< WWW-Authenticate: Basic realm="security" charset="UTF-8"
< content-type: application/json; charset=UTF-8
< content-length: 429

  • Connection #0 to host left intact
    {"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication token for REST request [/]","header":{"WWW-Authenticate":["Bearer realm="security"","Basic realm="security" charset="UTF-8""]}}],"type":"security_exception","reason":"missing authentication token for REST request [/]","header":{"WWW-Authenticate":["Bearer realm="security"","Basic realm="security" charset="UTF-8""]}},"status":401}

You still didn't share your elasticsearch configuration so we can't know for sure. My guess is that your TLS configuration for the http layer is missing the 

setting that needs to be set to optional or required as described in our PKI realm documentation

But as I read from the documents, this value is defaulted to required. So I haven't set it specifically in elasticsearch.yml.

Can you point to the docs that say that?
It's certainly not true, if it were true then every http connection would need a client certificate.

You should explicitly enable TLS client authentication. I would recommend that you set it to optional.

Oh, I made a mistake. What I saw is the default TSL/SSL settings. The http TSL/SSL settings override them.
After I set optional, I got the following error:

{"error":{"root_cause":[{"type":"security_exception","reason":"action [cluster:monitor/main] is unauthorized for user [cl-jli]"}],"type":"security_exception","reason":"action [cluster:monitor/main] is unauthorized for user [cl-jli]"},"status":403}

Though I have some addition in config/role_mapping.yml:

  • "cn=cl-jli,OU=11-14B,O=Std"

We have no way of knowing whether that is the correct role mapping.

  • does the monitoring role exist? What privileges does it have?
  • Is that the correct DN for your certificate?

In roles.yml, I added:
cluster: [ 'monitor' ].

But even I changed the role to superuser in role_mapping.yml, i found the some error.

Then it seems like you are using an incorrect DN.

Try using the Authenticate API to debug this.

I use openssl x509 -subject -nameopt RFC2253 -noout -in cl-cert.pem to get exact DN from the client certificate. And then add the DN to role_mapping.yml with the role of monitoring_user. It works.
Thanks you!

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