Elasticsearch Curl Command with Sudo Permission Works, But Without Sudo or Using Simple Curl Command Returns Empty Response

I'm new to Elasticsearch and I'm currently working with it on my local WSL2 Ubuntu machine. I'm following the official Debian installation guide, and everything seems to be running fine, but I'm facing an issue when testing the Elasticsearch response.

Here's what's happening:

• When I use the following curl command with sudo permissions, I get a valid response and can confirm that Elasticsearch is running:

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:$ELASTIC_PASSWORD https://localhost:9200

• However, when I try a simpler command like this (without sudo), I get an empty response:

curl -X GET localhost:9200

This happens even though Elasticsearch is running and I can see it in the status checks.

I’ve checked that the service is active, and I also made sure that the ELASTIC_PASSWORD is correct when testing with the first curl command.

Why is this happening, and how can I fix it so that I can run the simple curl command without needing sudo?

Any help would be greatly appreciated! Thanks in advance.

I'm guessing you are using sudo because the un-privileged user does not have access to the cert in /etc/elasticsearch/certs/http_ca.crt.

Either way, I'm not sure why you are dropping the -u elastic:$ELASTIC_PASSWORD when running curl without sudo.

The endpoint (elastic) has no idea whether you elevated with sudo or not when using curl to send your request. I'm guessing the change in behavior is due to the absence of the username/password.

Something to keep in mind when debugging with curl, is adding -i param to see the HTTP code that came back from the request. I suspect, you are receiving a 4xx code related to authorization (possibly 401 or 403), because you sent a request without username/password.

To get around the need to use sudo to access /etc/elasticsearch/certs/http_ca.crt (if that is the reason you are using sudo), you can add -k param to skip TLS certificate verification.

For example: curl -k -u elastic:$ELASTIC_PASSWORD https://localhost:9200.

This is not recommended in production, but since you are hitting a localhost endpoint serving a self-signed certificate, it should be fine.