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

Help
1

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
2

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):

3 Likes
3

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?

5 Likes
4

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

2 Likes