Unclear motive for negative server responses

One problem, multiple workarounds.

I was online the day that was posted here.
And I've reposted it dozens of times.
It doesn't apply here.


I've even spun up a similar test system, just to see if it is broken:

cat /etc/issue
Ubuntu 20.04.3 LTS \n \l

But it works just fine.
The problem discussed here was clearly created by some action taken on that system.
Possibly an install or update that went awry or stomped on something it should not have...
I would recommend (get your data out and) flattening it and starting over.
This time make sure curl continues to work after each change.


I see that we have not completely ruled out a .curlrc interfering. Would you try:

curl -CAcert /etc/ssl/certs/ca-certificates.crt https://tuttopepe.saltalafila.online/api/v1/articles/array

It's a easy test and maybe we will get lucky :slight_smile:


This looks like it's a curl build for (old) Apple systems, not Ubuntu. It also seems to be using the OS X TLS stack.

Are you having the connection problems on your Ubuntu server, or on your Apple computer?


[Sorry for being away for so long, but I had to be at my desktop and of clear mind to follow what is an interesting thread.]

  1. the above test returns:
    curl: option -CAcert: expected a proper numerical parameter
  2. yes the curl build is for an older Apple system (sorry, but Apple's OS churn gives old a new meaning). However it is occuring on other clients (I will get the system references)
  3. no, connection problems are not apparent; responses are always occuring.

So, Let's Encrypt made a decision to not drop DST X3 cert; it would be proper of them to illustrate why... en passant. as this is a bigger problem.

The questions now become:

a) '...and starting over. [...] make sure curl continues to work after each change.' Spinning up a new server is perfectly doable. This is an experiment that does require some time to afford it proper attention and will be done in due course.

b) The need for security is on the server side (updates). The clients are connecting with tokens that are not even being communicated to them via the web, so the server is running securely. The clients can run curl with the -k flag and still verify via https that cert validity. What is weak in this scenario, temporary as it may be?

1 Like

This may have way more information that you seek... But it does cover the question you ask.
There is even a link to a video that explains the reasoning.
See: Production Chain Changes - API Announcements - Let's Encrypt Community Support (letsencrypt.org)

I don't really see a question in "a".

For "b": Running curl with -k is not safe at all. It would allow a MITM to use any cert at all and succeed.

1 Like

"For "b": however they would have to posses the token (which is not 2 characters long) to successfully be accepted by the application. Is my risk assessment wrong?

1 Like

Unless the token is being used to encrypt the connection (within the https connection), yes. your assumption is wrong.

Call me (secure call)
I'll call your bank (secure call)
Then anything they ask me, I ask you
You tell me and I tell your bank
Soon I will be into your bank as you.


I stand corrected.