Im trying update certs with but it do not work anymore

My domain is:

I ran this command: --issue -d --server -w /var/www/htmlsacme

It produced this output:
[Thu Nov 11 16:23:36 EET 2021] Please refer to libcurl - Error Codes for error code: 60
[Thu Nov 11 16:23:38 EET 2021] Can not init api for:
[Thu Nov 11 16:23:38 EET 2021] Sleep 10 and retry.

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

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

We will update this old linux server next January. A few months ago I switched to cert V01 -> V02 and had to switch to because I couldn't get the certbot working with the v02 of old Ubuntu. So we need to get update certs one more time :slight_smile:

This next command worked last time when I need to use it but it do not work any more. Can some one help me please? --issue -d --server -w /var/www/htmlsacme

@Jukka The Lets Encrypt acme server changed the cert chain it uses on Sept 30 to better address the expiration of the DST Root CA X3 root cert.

The LE acme server chain now ends with ISRG Root X1 which your Ubuntu 14 probably does not have in its CA certificate store. The best solution would be to get this added to your system but I could not find a thread that described this. If you had LTS ESM there were updates but without you have to update the cert store manually.

Since you plan to update your server in 2 months there is another way that is normally a very bad practice. But, since this is a one-time thing it may be easier for you. This is to add the --insecure option to your command. The help for says this:

--insecure  Do not check the server certificate, in some devices, the api server's certificate may not be trusted.

This option causes it to use the --insecure option for the curl commands it uses to communicate with the LE acme server.

I repeat, this is normally a very bad practice and can be a danger to your server certificates. This is a special case where it might be useful.

1 Like

I've often wondered why something like --insecure can't more simply be addressed by just switching:

1 Like

@rg305 Clever. Though I get a curl error 56 (connection reset by peer) when I tried it just now :frowning: Guess LE acme insists on the flows being encrypted at least.

1 Like

I'm not saying that solution has been implemented (yet).
I'm just wondering why it hasn't been.
They go through the effort of coding the "insecurity" but isn't that equal to HTTP ?

1 Like

No. Because http the traffic is in the clear. With --insecure it is still https encrypted traffic - just curl does not care what cert the server sends (in this case the LE acme server). Much like the LE acme server does not care what cert it might see from the client if the http challenge is redirected to https (but I digress).

We can validate the certs after they are issued to ensure they came from the right source. It's really a rare case with a one-off need which can be validated independently.

I guess "equal" is relative.
Effectively using HTTPS with (let's say) some unknown self-signed cert negates the benefit of HTTPS.
HTTP also negates (all) the benefits of HTTPS.
So they are very close in my eyes.

I mean ACME protocol covers most of the issues.
Even when using a MITM proxy.
The private key is never sent to anyone or from anyone.
I guess the registration may be at risk...
The LE account keys.

I understand your point. I see https providing two benefits - validating the sender and encrypting the traffic. Encryption avoids sniffers. Having the client ignore the cert so does not validate the server makes it vulnerable to MITM. But, in this case we can validate the result (the fresh certificate created) independently.

So, in general I agree with you but I think this is a rare case where such a solution is helpful.

Update: "I mean ACME protocol covers most of the issues." You know that better than I :slight_smile:

1 Like

They could also use openssl to look at the cert from LE acme server before using --insecure. That at least manually verifies if they talking to the right server (at that moment) - reducing any security exposure considerably. Like:

echo | openssl s_client -connect | head

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN =
verify return:1
Certificate chain
 0 s:/
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
1 Like

We digress...
[off topic]

But your solution would imply some form of validating that cert (each and every time).
OR grabbing it and adding it to the trusted roots (where it should already be).
round and round we go...

This person has a one-off problem. They are updating their server in Jan so just need one fresh cert to replace the one that expired yesterday.

The --insecure option is a quick path to restore their site and manual efforts I showed can add validation.

1 Like

Yes, there is no other option available today.
On that we are agreed.

1 Like

Wouldn't it be easier to just add ISRG Root X1 to the trust store? I was hoping that somebody would have already put together instructions to add it for the more-common operating systems that should have new trust stores but don't.

1 Like

I could not find any post that described it for Ubuntu 14. Besides, they said they just needed one more renewal before a server replacement in Jan. Their cert already expired. A quick and dirty seemed a viable solution here.

It is all academic. They have a fresh cert now. I think we have talked about it amongst ourselves longer than it took them to refresh :slight_smile:


Come to think of it, I think Ubuntu released a statement that they would start supporting ALL their releases for 10 years.
That means Ubuntu 14 would be "good" (at least for this type of "patch") until 2014.

"news" is sketchy...
Some say only the non-expired releases will be extended.
Some are not sure if it will required a paid subscription or not.

1 Like

Yeah, I saw similar but Ubuntu 14 needed ESM subscription to get that. I aggregated the below Ubuntu posts here about 2 weeks ago

Here is a post from xnox, a Canonical / Ubuntu developer:

The Ubuntu site says the same more formally here and here

If someone does not mention ESM I assume they do not have it. Seems like something they would know they paid for.

1 Like

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