SSL Certificate issues

I am trying to set up a server to evaluate and determine if/how we can use this solution.

Unfortunately I am going mad trying to set it up. I have been trying, searching, reading and trying again for over a week now and I keep hitting the same error.
I have seen plenty of others running into the same or similar problems, but there is either no solution given or I don't understand it. I hope someone here can point me in the right direction.

I'm using a VM running Server 2022 Std for OS

  • Elasticsearch is up and running
  • Kibana is up and running, properly enrolled
  • Fleet server is up and running, status healthy

So far so good. However, if I try (optional) step 3 in the Elasticsearch Installation guide, checking the Elasticsearch cluster with an authenticated cURL call, that fails with this error:
curl: (60) schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN

But the rest of the setup steps are all fine right up to the point where I want to connect addional agents. Agent setup fails with tthe following error:
Error: fail to enroll: fail to execute request to fleet-server: x509: certificate signed by unknown authority

I have checked, converted and imported the certificates I found in %ES_HOME%\config\certs but that does not help. I did notice that the fingerprint I was given during initial setup corresponds to the fingerprint that is shown in the Fleet server config, but that the http_ca.crt and http.p12 certificates have a different fingerprint.

What am I missing and where can I find the certificate with the fingerprint that is showing in my Fleet server?

can you provide your configuration which was in elasticsearh.yml file.

Note: Hide the sensitive information.

Sure. I have not made any changes (yet). Removing a lot of commented lines, this is what remains:

*** elasticsearch.yml ***
xpack.security.enabled: true
xpack.security.enrollment.enabled: true

xpack.security.http.ssl:
enabled: true
keystore.path: certs/http.p12

xpack.security.transport.ssl:
enabled: true
verification_mode: certificate
keystore.path: certs/transport.p12
truststore.path: certs/transport.p12

cluster.initial_master_nodes: ["HOSTNAME"]

http.host: 0.0.0.0

*** end of file ***

how you are calling API can you past here.

Sorry, not sure what you mean here.

This is de cURL commend that fails immediately after starting up Elasticsearch:

curl --cacert %ES_HOME%\config\certs\http_ca.crt -u elastic:$ELASTIC_PASSWORD https://xxx.xxx.xxx.xxx:9200

That produces this error:

curl: (60) schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN

And this is the install command I used to try to install an additional agent:

.\elastic-agent.exe install --url=https://xxx.xxx.xxx.xxx:8220 --enrollment-token=xxxxxxxxxxxxxxxxxxxxx

And that produces this error:

Error: fail to enroll: fail to execute request to fleet-server: x509: certificate signed by unknown authority

Anyone else that can help? I just don't understand why I run into a certificate error right after initial setup of Elasticsearch, before I even edit a thing.

Would I have more success if I move to Ubuntu for OS ?

Run the curl with the -v switch you will get more details.

Also assuming you read this carefully?

Thanks for your reply Stephen.

The -v switch was is good tip, although it only provided more questions.
This line in the output stands out:
schannel: using IP address, SNI is not supported by OS.

SNI is support by Windows Server since long.

I'll go over the manual page you refer to again (but yes, I have done so a couple of times already). Will report back with the results later.

Yes sorry I'm not the best with windows SSL. It seems sometimes there are some special requirements there.

If you share the output, perhaps I can help.

Often what we see is people putting IPs in the certs and then using domain name or vice versa or putting the IPs and the DNS fields of the certs So there's mismatches all those have to be aligned properly.

I started over again. Fresh VM and install. But again I am hitting the same problems.

Reading the article you linked to again and again, it gets more unclear for me every time I read it. I've got a few questions:

  • Installing the Fleet Server agent works just fine using the fingerprint from the http_ca.p12 certificate. The other agents I want to enroll into the Fleet require a different certificate?
  • I create a new ca.crt and key file. Do these file replace the http_ca.p12 file that was created during setup?
  • Where do the fleet-server.crt and key file go that were created?

I ran into an option I had not seen before. This provided me with a solution (at least for this setup)

I have added --insecure to the installation string for my Agents. Agents are installing and connecting just fine now.

I know it's not a solution, but it's a workaround I can live with right now.

Thanks for trying to help.

1 Like

Hi @nvanalphen
Self Managed Fleet with Self Signed Certs is Tricky, we do our best on the documentation but I think understanding the flow is important to..

Agents talk to BOTH Fleet and Elasticsearch and the certs need to be correct for both...

per the images on This pages (probably without the load balancer)

In short you need to get fleet setup correctly with the Correct Certs between Fleet and Elasticsearch

Then You need to Install Agents / Fleet Correct you will noticed in the Examples here if you look closely some of the cert setting related to Elasticsearch and Some the Fleet Server you have to get that all right...

If you GET the Fleet server all correct (which is an Agent that has a Fleet Server In It) them it will go mostly smooth after that.

Yes I have got this all working without the --insecure I did it on linux and it took me a try or two.

1 Like

Thanks Stephen! These pages do improve my understanding. I will definitely be going over them extensively later again.
For now my initial setup is running and starting to produce some nice graphics and insights. I look forward to diving into that some more too

1 Like

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