Error connecting to the letsencrypt server

Help
1

Hello!

We are experiencing problems issuing certificates on ISPmanager. Same error. Many users with this error found that their IP addresses were blocked by LE. Is it possible to check ours?

My domain is: ekrasavin.pp.ua
I ran this command: ISPmanager LetsEncrypt module
The operating system my web server runs on is (include version): Almalinux 8
I can login to a root shell on my machine.
I'm using a control panel to manage my site.

IP - 23.111.120.111

I attach a screenshot of the certificate issuance errors.

Screenshot 2024-01-16 at 12.43.37
Screenshot 2024-01-16 at 12.43.371199×548 76 KB

On another server - 23.111.123.17, with the same panel version and OS, everything works fine.

2

Try running

curl -v https://acme-staging-v02.api.letsencrypt.org/directory
1 Like
3

[root@localhost ~]# curl -v https://acme-staging-v02.api.letsencrypt.org/directory

  • Trying 172.65.46.172...
  • TCP_NODELAY set
  • Connected to acme-staging-v02.api.letsencrypt.org (172.65.46.172) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: none
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS handshake, [no content] (0):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.3 (IN), TLS handshake, [no content] (0):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (IN), TLS handshake, [no content] (0):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.3 (IN), TLS handshake, [no content] (0):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.3 (OUT), TLS handshake, [no content] (0):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
  • ALPN, server accepted to use h2
  • Server certificate:
  • subject: CN=acme-staging-v02.api.letsencrypt.org
  • start date: Dec 26 10:48:09 2023 GMT
  • expire date: Mar 25 10:48:08 2024 GMT
  • subjectAltName: host "acme-staging-v02.api.letsencrypt.org" matched cert's "acme-staging-v02.api.letsencrypt.org"
  • issuer: C=US; O=Let's Encrypt; CN=R3
  • SSL certificate verify ok.
  • Using HTTP2, server supports multi-use
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • TLSv1.3 (OUT), TLS app data, [no content] (0):
  • TLSv1.3 (OUT), TLS app data, [no content] (0):
  • TLSv1.3 (OUT), TLS app data, [no content] (0):
  • Using Stream ID: 1 (easy handle 0x56486cd34620)
  • TLSv1.3 (OUT), TLS app data, [no content] (0):

GET /directory HTTP/2
Host: acme-staging-v02.api.letsencrypt.org
User-Agent: curl/7.61.1
Accept: /

  • OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104
  • Failed receiving HTTP2 data
  • TLSv1.3 (OUT), TLS app data, [no content] (0):
  • SSL_write() returned SYSCALL, errno = 32
  • Failed sending HTTP2 data
  • Connection #0 to host acme-staging-v02.api.letsencrypt.org left intact
    curl: (56) OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104
4

It looks like openssl has issues. I don't know how ispconfig likes to do stuff, tho. Ask them?

2 Likes
5

I don't think it's a software problem. As I pointed out at the beginning, there is a server with the same set of software installed manually on the same day, and it has no errors.

I would also add that if enable vpn or proxy on the problem server, the certificate issues without errors. Only LetsEncrypt support can help here.

We need to understand how it happens that from one subnet 23.111.120.0\24 it is impossible to issue a certificate neither from Linux server nor from windows srver.
But at the same time from the machine 23.111.123.17 on which the same software is installed, everything works.

The only difference is that one VM is created on a Hyper-V and the other on a KVM.

6

Same openssl version, same OS?

You might try and run ip route get 172.65.46.172 to see if the issue is in the routing table. (traceroute -T 172.65.46.172 if it's the routing table of another machine) -- but it doesn't look like it is.

3 Likes
7

Also show:
traceroute -T -p 443 acme-v02.api.letsencrypt.org

2 Likes
8

yes same OS and openssl.

ip route get 172.65.46.172 - nice, its work)

can you tell me how to do the same on windows server? I want to check on my other server where there is a similar problem.

Screenshot 2024-01-17 at 12.24.47
Screenshot 2024-01-17 at 12.24.471420×987 109 KB

9

Not sure but...

2 Likes
10

route print

2 Likes
11

I have a similar problem on subnet 188.42.151.0\24. linux and windows
On the windows server machine on subnet 23.111.120.0\24 seems to be working already.

12

Screenshot 2024-01-17 at 13.22.55
Screenshot 2024-01-17 at 13.22.551684×926 191 KB

13

You have two default gateways:

image
image981×110 36 KB

Is that expected?

3 Likes
14

Yes, I'm trying to change the IP address to a different one.
I want to keep the 2 subnets working for a while until I make sure all my clients have changed IPs in their domains.

Right now, none of my Windows servers are running certificate issuance on both subnets anymore

15

on linux server 23.111.120.111 also stopped issuing certificate

16

You only have one IP on that system: 23.111.120.15
[there is no second IP]

Are both real/Internet IPs behind the same gateway/router?

FYI: DNS is the solution to changing IP problems.

4 Likes
17

23.111.120.15 is a shared ip
Some clients on this server should have dedicated IPs on the same subnet, this is not configured on this server because the server is only used for testing and solving the LetsEncrypt issue

The real IP as I know it is behind the same gateway/router

The second subnet 188.42.151.0\24 was there before and is not used now, but it has the same problem with LetsEncrypt.

18 
[root@localhost ~]# traceroute -T -p 443 acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
 1  23.111.120.2 (23.111.120.2)  1.403 ms  2.012 ms  2.792 ms
 2  se-mo01-s2.servers.ru (188.42.176.62)  0.922 ms  1.693 ms  2.063 ms
 3  xcore-mo1-se-r2.servers.ru (188.42.176.218)  0.508 ms  0.500 ms xcore-mo1-se-r2.servers.ru (188.42.176.204)  0.475 ms
 4  89.188.100.29 (89.188.100.29)  0.832 ms  0.805 ms  0.779 ms
 5  * de-cix-frankfurt.as13335.net (80.81.194.180)  50.180 ms *
 6  172.71.248.3 (172.71.248.3)  44.733 ms  44.470 ms 172.70.248.3 (172.70.248.3)  41.882 ms
 7  172.65.32.248 (172.65.32.248)  38.056 ms  37.987 ms  35.482 ms

But certificates are not issued
Yesterday it literally worked for 30 minutes and then stopped working again

19

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