Can't get certificate

Help
1

My domain is: ao-asp.ru

I ran this command: acme.sh --issue --standalone -d ao-asp.ru

It produced this output:

Using CA: https://acme-v02.api.letsencrypt.org/directory
Standalone mode.
Single domain='ao-asp.ru'
Getting domain auth token for each domain
Please refer to libcurl - Error Codes for error code: 7
Create new order error. Le_OrderFinalize not found.
Please check log file for more details: /root/.acme.sh/acme.sh.log

My web server is (include version): nginx version: nginx/1.18.0

The operating system my web server runs on is (include version): debian 10 buster

My hosting provider, if applicable, is: timeweb

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): i'm use acme.sh. v3.0.6

I checked the availability of the address 172.65.32.248 on port 443. The address is available periodically. About one time out of five.

I am also attaching the output of the test commands

root@aspcom2018:~# curl -v https://acme-v02.api.letsencrypt.org/directory

  • Trying 172.65.32.248...
  • TCP_NODELAY set
  • Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.2 (OUT), TLS header, Certificate Status (22):
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS change cipher, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, server accepted to use h2
  • Server certificate:
  • subject: CN=acme-v02.api.letsencrypt.org
  • start date: May 7 18:19:30 2023 GMT
  • expire date: Aug 5 18:19:29 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 multi-use
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • Using Stream ID: 1 (easy handle 0x55c3039b7ab0)

GET /directory HTTP/1.1
Host: acme-v02.api.letsencrypt.org
User-Agent: curl/7.52.1
Accept: /

}root@aspcom2018:~#dig +short A acme-v02.api.letsencrypt.org
prod.api.letsencrypt.org.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
172.65.32.248

root@aspcom2018:~# telnet acme-v02.api.letsencrypt.org 443
Trying 172.65.32.248...
telnet: Unable to connect to remote host: Connection timed out

Is my ip address blacklisted? My ip: 188.225.80.237

2

Doesn't look like it. If that would be the case, you wouldn't get through 20 % of the time: it would have been blocked completely. You wouldn't be able to see the directory output listed above.

3

Ok, what could it be?

4

I have no clue, maybe connectivity issues between Russia and the Cloudflare CDN?

5

Thanks for the answer. How can I check it?

6

With geographic based issue often you will need to check with the ISP or CDN and possibly the DNS Provider.

7

The problem is only with this ip address in my subnet. If I change the address to another from the same subnet everything starts working. Therefore, I still tend to think that this is a blocking from the LE or Cloudflare CDN.

But I don't know how to check it.

8

The connectivity was already confirmed [one out of about five times].
You should speak with the ISP about why one IP is having this trouble while another is not.