Sophos SG UTM Lets Encrypt Terms of Use


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

Or do as the error message says: check your internet connection.


The directory has a link to the terms of service:

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.



sophos:/home/login # wget
--2022-11-26 21:50:02--
Connecting to||:443... connected.
ERROR: cannot verify's certificate, issued by /C=US/O=Let's Encrypt/CN=R3': unable to get issuer certificate To connect to insecurely, use --no-check-certificate'.
Unable to establish SSL connection.
sophos:/home/login #

sophos:/home/login # wget --no-check-certificate
--2022-11-26 21:50:22--
Connecting to||:443... connected.
WARNING: cannot verify'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.

1 Like

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.


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.

  1. navigate to Web Protection -> Filter Options -> "HTTPS CAs" tab
  2. check that the following entries are included under "Global Verification CAs":

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.

  1. you should be offered to update now under "Patterns". It is recommended to set the "Interval for pattern download and installation" in the "Configuration" tab not to manual, but to an automatic time interval, unless there is a valid reason not to install the pattern updates automatically

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:

  1. navigate to Webserver Protection -> Certificate Management -> tab "CA".
  2. remove all CA certificates whose expiration date has passed.
    Check for certificates with the following fingerprint and remove them:


  1. check that your Let's Encrypt certificate can now be renewed.

This was still present:

Funny was just that I have renewed only 2 weeks ago still a Cert.

Thanks for your help.

1 Like

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


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



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.