Error while enrolling: fail to execute the HTTP POST request: Post https://A.B.C:443/api/beats/agent/XXX-XXX-XXX-XXX-XXX: x509: certificate signed by unknown authority

[alexus]

Hello World!

@pierhugues am still trying to get an answer to following:

Central Management (Beta)

# filebeat enroll https://A.B.C:443 XYZ Error while enrolling: fail to execute the HTTP POST request: Post https://A.B.C:443/api/beats/agent/XXX-XXX-XXX-XXX-XXX: x509: certificate signed by unknown authority # I use GoDaddy's wildcard certificate. Any ideas?

Is there a work around or ...

Please advise.

[Magnus_Kessler]

You may have to install the CA's intermediate certificate in addition to the server certificate on your server. When using certificates in PEM format (ASCII armoured Base64 encoded), you can append the intermediate certificate to the server certificate (cat server.crt intermediate.crt > chain.crt) and deploy the chained certificate instead.

[alexus]

following are the steps I took in order to get rid of that error:

cd /usr/local/share/ca-certificates/
wget https://ssl-ccp.godaddy.com/repository/gdig2.crt.pem
wget https://ssl-ccp.godaddy.com/repository/sfig2.crt.pem
update-ca-certificates

[Magnus_Kessler]

Thanks for posting your solution. However, usually the better approach is what I tried (badly) to explain previously.

In your environment, assuming that gdig2.crt.pem is the intermediate certificate used to sign your server certificate, concatenate your server certificate and the intermediate

cat server.pem gdig2.crt.pem > server_chain.pem

Then configure Elasticsearch and Kibana to use server_chain.pem instead of server.pem. On each TLS request, the chained certificate will be returned to the client, and there is no need merge these intermediate certificates into the system CA store.

[alexus]

• Encrypting communications in Kibana | Kibana User Guide [6.6] | Elastic
• Configuring Kibana | Kibana User Guide [6.6] | Elastic

---

what was missing is:

server.ssl.certificateAuthorities

List of paths to PEM encoded certificate files that should be trusted.

and there is no need to daisy chain certificates) i believe that is better way to solve this issue)

[Magnus_Kessler]

Thanks again for sharing the missing piece in your solution. Yes, for non-public CAs, the server.ssl.certificateAuthorities setting is required, and it can also be used to make intermediate CA's available to Beats. For certificate chains that are anchored on public CAs, I still prefer chaining the certs on my servers. Whatever works!