Let's Encrypt certificate is not recognized in curl or api tools

I have requested the certificate from Let's Encrypt and it is not recognized by the curl or command tools. I have confirmed it on various OS(windows, Linux). My Browser is not complaining about the certificate.

My domain is: https://vega-data.nodes.guru:3008

The domain above exposes some GQL API.

I run this command:

curl --cacert cert.pem -v -H  "Content-Type: application/json"  --data '{"query": "{epoch{id}}"}' https://vega-data.nodes.guru:3008/graphql

And it produces this output:

*   Trying 135.181.106.186:3008...
* Connected to vega-data.nodes.guru (135.181.106.186) port 3008 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

However, when I download the certificate from the domain and trust it explicitly, the query works well.

➜  ~ echo | openssl s_client -connect vega-data.nodes.guru:3008 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert.pem
curl --cacert cert.pem  -H  "Content-Type: application/json"  --data '{"query": "{epoch{id}}"}' https://vega-data.nodes.guru:3008/graphql
{"data":{"epoch":{"id":"547"}}}%

I have the same problem when I am trying to use the golang, example script to reproduce the issue:

package main

import (
	"crypto/tls"
	"fmt"
	"net/http"
	"strings"
)

func main() {
	gqlQuery := strings.NewReader(`{"query": "{epoch{id}}"}`)
	// The below line makes connection insecure, then script is working fine, but i want tls
	// http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{InsecureSkipVerify: true}
	client := &http.Client{}
	req, _ := http.NewRequest("POST", "https://vega-data.nodes.guru:3008/graphql", gqlQuery)
	req.Header.Set("name", "application/json")
	res, err := client.Do(req)

	fmt.Printf("Result:\n\n%#v\n\nErr:\n\n%s", res, err)
}

My operating system is: Ubuntu in WSL2

Linux ubuntu-hdd 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux


The server behind https://vega-data.nodes.guru:3008 does not send the intermediary certificate

$ testssl https://vega-data.nodes.guru:3008
[…]
 Chain of trust               NOT ok (chain incomplete)
[…]
 # of certificates provided   1
[…]

It would be great to know how you got the certificate and how you installed it.


Please fill out the fields below so we can help you better.

My domain is: https://vega-data.nodes.guru:3008/

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Your first curl command did not accept the --cacert value for some reason. You can see in the -v output it used the system default value. I have no idea why it would do that.

When I run it the curl -v output looks like

* ALPN, offering http/1.1
*  CAfile: cert.pem
*  CApath: /etc/ssl/certs

But, why are you doing it this way? Can't that service on port 3008 support providing an intermediate chain that your system can verify correctly?

Hello Thank you for your response. I will test the certificate because this is a custom www server implemented in go and I do not manage the server. I am just end user of that server and I am trying to figure out the issue. I will get more info from the owner of the domain and we will try to fix it together. I will post update here