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 acme.sh because I couldn't get the certbot working with the v02 of old Ubuntu. So we need to get update certs one more time
@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 acme.sh command. The help for acme.sh says this:
--insecure Do not check the server certificate, in some devices, the api server's certificate may not be trusted.
This acme.sh 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.
I've often wondered why something like --insecure can't more simply be addressed by just switching: https://acme-v02.api.letsencrypt.org/directory
to http://acme-v02.api.letsencrypt.org/directory
@rg305 Clever. Though I get a curl error 56 (connection reset by peer) when I tried it just now Guess LE acme insists on the flows being encrypted at least.
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 ?
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
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 acme-v02.api.letsencrypt.org:443 | 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 = acme-v01.api.letsencrypt.org
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=acme-v01.api.letsencrypt.org
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
---
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...
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.
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
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.
Guess LE acme insists on the flows being encrypted at least.