My ip is apparently blocked 86.111.12.92

[linkp]

That is more evidence that the routing problem is on your local network. I'm not sure how you can see it as anything else.

[dmitriykapiton]

root@ucs:~# curl -i --connect-to ::172.253.115.139:443 https://dv.acme-v02.api.p ki.goog/directory
curl: (7) Failed to connect to 172.253.115.139 port 443: No route to host
root@ucs:~# curl https://api.buypass.com/acme/directory curl: (7) Failed to connect to api.buypass.com port 443: Connection timed out

[dmitriykapiton]

It's probably Mikrotik. But I can't touch him right now.

[MikeMcQ]

Looks like you can't reach other Certificate Authorities either. Again, confirms not a Let's Encrypt issue.

Can you even reach this?

curl -4 https://www.cloudflare.com/cdn-cgi/trace

[dmitriykapiton]

Thanks everyone, the problem was in Mikrotik. I restored the settings from Backup and everything worked.

[dmitriykapiton]

@dmitriykapiton

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

Is this the correct report?

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
• successfully set certificate verify locations:
• CAfile: none
  CApath: /etc/ssl/certs
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• 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-v02.api.letsencrypt.org
• start date: Mar 21 18:03:47 2025 GMT
• expire date: Jun 19 18:03:46 2025 GMT
• subjectAltName: host "acme-v02.api.letsencrypt.org" matched cert's "acme-v02.api.letsencrypt.org"
• issuer: C=US; O=Let's Encrypt; CN=R11
• 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 0x5644d96aa750)

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

• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• old SSL session ID is stale, removing
• Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
  < HTTP/2 200
  < server: nginx
  < date: Tue, 08 Apr 2025 14:54:56 GMT
  < content-type: application/json
  < content-length: 1042
  < cache-control: public, max-age=0, no-cache
  < x-frame-options: DENY
  < strict-transport-security: max-age=604800
  <
  {
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
  "caaIdentities": [
  "letsencrypt.org"
  ],
  "profiles": {
  "classic": "Profiles - Let's Encrypt",
  "shortlived": "Profiles - Let's Encrypt (not yet generally available)",
  "tlsserver": "Profiles - Let's Encrypt (not yet generally available)"
  },
  "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.5-February-24-2025.pdf",
  "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert",
  "uxPMm6N18G4": "Adding random entries to the directory"
• Connection #0 to host acme-v02.api.letsencrypt.org left intact

[MikeMcQ]

Yes, that is correct. You can leave off the -v for such connectivity tests. That just adds verbose output for specific debugging purposes