Hello,
System Sophos SG 125 Rev. 3 with Business License:
Let's Encrypt Terms of Use
The last attempt to activate Let's Encrypt failed: the current Terms of Use could not be found. Please try again or check your internet connection if the problem persists.
Sounds like something you should take up with Sophos? I'm not sure what you're expecting of this Community to be honest 
Or do as the error message says: check your internet connection.
The directory has a link to the terms of service:
https://acme-v02.api.letsencrypt.org/directory
Which works fine:
So the problem is likely something on the Sophos side. Is this a web UI? Can you check the developer console? If it’s trying to load the subscriber agreement from inside the browser, we may get a more informative error in the network tab there.
If it’s trying to load the document from the SG itself, then it’s probably a network connectivity problem on the SG, which I think you’ll need to find somewhere more Sophos specific for help.
Hello,
sophos:/home/login # wget https://acme-v02.api.letsencrypt.org/directory
--2022-11-26 21:50:02-- https://acme-v02.api.letsencrypt.org/directory
Resolving acme-v02.api.letsencrypt.org... 172.65.32.248
Connecting to acme-v02.api.letsencrypt.org|172.65.32.248|:443... connected.
ERROR: cannot verify acme-v02.api.letsencrypt.org's certificate, issued by /C=US/O=Let's Encrypt/CN=R3': unable to get issuer certificate To connect to acme-v02.api.letsencrypt.org insecurely, use --no-check-certificate'.
Unable to establish SSL connection.
sophos:/home/login #
sophos:/home/login # wget https://acme-v02.api.letsencrypt.org/directory --no-check-certificate
--2022-11-26 21:50:22-- https://acme-v02.api.letsencrypt.org/directory
Resolving acme-v02.api.letsencrypt.org... 172.65.32.248
Connecting to acme-v02.api.letsencrypt.org|172.65.32.248|:443... connected.
WARNING: cannot verify acme-v02.api.letsencrypt.org's certificate, issued by /C=US/O=Let's Encrypt/CN=R3': unable to get issuer certificate HTTP request sent, awaiting response... 200 OK Length: 659 [application/json] Saving to: directory.1'
100%[==========================================================================================================================>] 659 --.-K/s in 0s
2022-11-26 21:50:23 (158 MB/s) - `directory.1' saved [659/659]
sophos:/home/login #
I can open and read the terms of use.
It is displayed:
Version 1.3
September 21, 2022
Page 1 of 6
Then it will probably be a Sophos problem.
Thanks for the help.
Your Sophos device probably hasn't got the ISRG Root X1 certificate in its trust store. Can you perhaps update it?
Sophos shows me under HTTPS CAs
Global verification CAs
Internet Security Research Group ISRG Root X1
Fingerprint: CA:BD:2A:79:A1:07:6A:31:F2:1D:25:36:35:CB:03:9D:43:29:A5:E8
Internet Security Research Group ISRG Root X2
Fingerprint: BD:B1:B9:3C:D5:97:8D:45:C6:26:14:55:F8:DB:95:C7:5A:D1:53:AF
Well, that's weird then.
I searched googel again and found the solution.
Workaround
First check that you have applied the pattern update which removes the expired DST Root CA X3 and applies the correct ISRG Root X1. To do this, proceed as follows:
Open the WebAdmin of the UTM. 1.
Internet Security Research Group ISRG Root X1
Internet Security Research Group ISRG Root X2
If the entries are present, you have already applied the pattern update. 4.
If the pattern update has not yet been applied, navigate to Administration -> Up2Date -> "Overview" tab.
After checking for the pattern update, you must now check whether there are any old root certificates from Let's Encrypt remaining in the certificate management. To do this, proceed as follows:
93:3C:6D:DE:E9:5C:9C:41:A4:0F:9F:50:49:3D:82:BE:03:AD:87:BF.
This was still present:
93:3C:6D:DE:E9:5C:9C:41:A4:0F:9F:50:49:3D:82:BE:03:AD:87:BF.
Funny was just that I have renewed only 2 weeks ago still a Cert.
Nevertheless
Thanks for your help.
It should not have mattered as the ACME API uses the "short chain". Except for buggy implementations I guess, such with Sophos apparently.
Glad you got it fixed tho
I read on the Internet.
If there is still an old certificate with the old fingerprint.
The new query is more or less blocked.
Nothing buggy about this. This error happens with clients that use the old OpenSSL logic, which tend to mostly be on embedded devices and outdated Linux servers. A similar fix is needed for OSX 10.11-10.15 and some windows versions.
The weird thing about this, to me, is that I believe 93:::: is the fingerprint for the old cross-signed ISRG root - the version that expired the same day as the DST root. That should not have been in the trust store to start with. Usually you delete the old DST root.
I don’t know how/why that cert was in the trust store - but since this is a Sophos device, I assume they are using explicit chains and not allowing short circuit logic on purpose.
I thought that was only the case with the "long chain"? The ACME API uses the "short chain", so it shouldn't matter if the client also has the expired DST Root X3 in their root store, right?
It's the most recent one: crt.sh | 3958242236
This is weird, as the top results for the hash (which was what I used to check my guess) all said it was the earlier certificate... but crt.sh does not lie and you are definitely correct.
So... the same hash was used for both?
No. It's the SHA-1 fingerprint. 6th row, far right column:
933C6DDEE95C9C41A40F9F50493D82BE03AD87BF
CABD2A79A1076A31F21D253635CB039D4329A5E8
The fingerprint is calculated on the DER encoding of the whole certificate, so each re-issue/signing is essentially guaranteed a unique value as there is some unique data in each cert such as the precertificate info. The "hash" is computed differently (usually SPKI) and can be repeated across certificates.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
