Incorrect response code from ACME server: 500

My domain is: larrnet.us

I ran this command: Sophos UTM 9.713-19

It produced this output:
Incorrect response code from ACME server: 500

The operating system my web server runs on is (include version): Sophos UTM9

This is similar to https://community.letsencrypt.org/t/incorrect-response-code-from-acme-server-500/187607

What's different was this was working great till I moved and got a new ip address a couple weeks ago.
I've updated DNS with my provider and the domain name pings to the right address. I tried to renew the certs in UTM but that failed so I turned off LE support in UTM and am now trying to turn it back on.

Here is all I get in the logs:

2023:01:01-21:10:02 larrnet letsencrypt[13858]: I Create account: creating new Let's Encrypt acccount
2023:01:01-21:10:03 larrnet letsencrypt[13858]: E Create account: Incorrect response code from ACME server: 500
2023:01:01-21:10:03 larrnet letsencrypt[13858]: E Create account: URL was: https://acme-v02.api.letsencrypt.org/directory
2023:01:01-21:10:03 larrnet letsencrypt[13858]: E Create account: TOS_UNAVAILABLE: Failed to retrieve the current Terms of Service URL
2023:01:01-21:10:03 larrnet letsencrypt[13858]: E Create account: failed to create account

The output of: curl -v https://acme-v02.api.letsencrypt.org/directory

curl -v https://acme-v02.api.letsencrypt.org/directory >txt.txt
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 172.65.32.248:443...

  • Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
  • TLSv1.0 (OUT), TLS header, Certificate Status (22):
    } [5 bytes data]
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
    } [512 bytes data]
  • TLSv1.2 (IN), TLS header, Certificate Status (22):
    { [5 bytes data]
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
    { [122 bytes data]
  • TLSv1.2 (IN), TLS header, Finished (20):
    { [5 bytes data]
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
    { [19 bytes data]
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
    { [2859 bytes data]
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
    { [264 bytes data]
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
  • TLSv1.3 (IN), TLS handshake, Finished (20):
    { [52 bytes data]
  • TLSv1.2 (OUT), TLS header, Finished (20):
    } [5 bytes data]
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
    } [1 bytes data]
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
    } [5 bytes data]
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
    } [52 bytes data]
  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
  • ALPN, server accepted to use h2
  • Server certificate:
  • subject: CN=acme-v02.api.letsencrypt.org
  • start date: Nov 7 18:45:21 2022 GMT
  • expire date: Feb 5 18:45:20 2023 GMT
  • subjectAltName: host "acme-v02.api.letsencrypt.org" matched cert's "acme-v02.api.letsencrypt.org"
  • issuer: C=US; O=Let's Encrypt; CN=R3
  • SSL certificate verify ok.
  • Using HTTP2, server supports multiplexing
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
    } [5 bytes data]
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
    } [5 bytes data]
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
    } [5 bytes data]
  • Using Stream ID: 1 (easy handle 0x558ac362e960)
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
    } [5 bytes data]

GET /directory HTTP/2
Host: acme-v02.api.letsencrypt.org
user-agent: curl/7.81.0
accept: /

  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    { [57 bytes data]
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    { [57 bytes data]
  • old SSL session ID is stale, removing
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
  • Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
    } [5 bytes data]
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    { [5 bytes data]
    < HTTP/2 200
    < server: nginx
    < date: Mon, 02 Jan 2023 06:27:06 GMT
    < content-type: application/json
    < content-length: 659
    < cache-control: public, max-age=0, no-cache
    < x-frame-options: DENY
    < strict-transport-security: max-age=604800
    <
    { [659 bytes data]
    100 659 100 659 0 0 2643 0 --:--:-- --:--:-- --:--:-- 2646
  • Connection #0 to host acme-v02.api.letsencrypt.org left intact

Do I have to wait for my old certs to expire?
Can I force them to expire so UTM can re-request them?
Is it something else?
Did I miss something?

Looking at this error, your ACME client had trouble retreiving https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf, could you try that manually from the Sophos device?

6 Likes

Thanks @Osiris for the response. Before I could test your suggestion, I found a workaround / fix.

I suspect Sophos UTM is trying to renew, but the certs were still good so LE "said" pound sand.

In Sophos UTM needed to delete all existing LE certs on both the Certificates tab AND the Certificate Authority tab under Certificate Management.
Note this screws up every config where those certs are used.
Once the above were deleted, I enabled LE support and the "account' was created. Then I could recreate the certs needed and the fun part...
Reconfig of the WebServer protection and filtering proxy.
It's all back up as it should be.

For anyone running by this discussion in the future, delete the certs on both tabs and start over.

1 Like

I don’t think you actually needed to delete the certs. There’s been several reports on this forum that there’s a bug in sophos’ path building. Here’s another thread with a less intrusive workaround: Sophos SG UTM Lets Encrypt Terms of Use - #8 by Darksniper

8 Likes

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