Currently while executing the below curl command:
curl -k -v "https://localhost:9200/_xpack/security/_authenticate?pretty" --cacert 'ca.crt' --key 'ca.key'
You should not be using ca.crt and ca.key for authentication. You should be using ca.crt and ca.key to generate a new certificate and key with
./certutil - as I described above - . If you use
--name "cert_for_prac" for example , the files will be named
Then you can use
cert_for_prac.key with curl as in
curl -k -v --cert cert_for_prac.crt --key cert_for_prac.key
There is no rule by Elasticsearch as to what is the DN of the users in your PKI realm
PKI realm users authenticate by providing their client key and certificate. They don't have a password. If a user has a private key and a certificate that is trusted by the CA that you configure for
certificate_authorities then they can authenticate to Elasticsearch.
As we mention in the documentation that I've shared above, the CN of the user in the certificate gets mapped to a username in Elasticsearch. This doesn't mean that a user with that username is "created" in Elasticsearch (or in any other realm) but just that when a user with that private key/ certificate authenticates to Elasticsearch, they will be known as that username. If you don't want to use the CN but something else from the information in the certificate, the instructions are in the same document above.
Now when your user authenticates via the PKI realm, they have no permission to do anything as they are not assigned any roles by default. You need to decide and define the which roles they get by using the role mapping api (described in the same documentation)
kibana, etc are not in the native realm. They are
buiilt-in users of the
reserved realm. These users can only authenticate with username/password.
A native realm also uses username/password for authentication. You can create users to use in the native realm with the User Management APIs.