We're experiencing similar issues with a client server hosted on gohost.kz in Kazakhstan. We attempted to issue an SSL certificate using Let's Encrypt's ACME API from our web server, but the connection fails with the following error:
curl: (52) Empty reply from server
The output of the Cloudflare trace:
fl=740f191
h=www.cloudflare.com
ts=1744024433.671
visit_scheme=https
uag=curl/7.88.1
colo=SIN
sliver=none
http=http/2
loc=KZ
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
rbi=off
kex=X25519
Key technical details:
Network Configuration
- Client IP:
109.248.170.246(Kazakhstan, JSC "Kazakhtelecom" based on IP lookup) - Cloudflare colo: SIN (Singapore)
- TLS connection: Established via Cloudflare but blocked at ISP level
ACME Failure Logs
{"level":"warn","ts":1744022902.2922828,"msg":"HTTP request failed; retrying",
"url":"https://acme-staging-v02.api.letsencrypt.org/directory",
"error":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"}
{"level":"warn","ts":1744022932.543171,"msg":"HTTP request failed; retrying",
"url":"https://acme-staging-v02.api.letsencrypt.org/directory",
"error":"context deadline exceeded..."}
Connectivity Tests
# Successful TLS handshake but failed HTTP/2 stream
$ curl -Iv https://acme-v02.api.letsencrypt.org/directory
* SSL connection: TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate: CN=acme-v02.api.letsencrypt.org (valid)
* Error: HTTP/2 stream 1 not closed cleanly (curl 18)
Our Observations
- Affects both staging (
acme-staging-v02) and production (acme-v02) endpoints - Occurs despite valid TLS certificate chain
- Cloudflare routing shows traffic exiting through Singapore (SIN) but still blocked.
Could Let's Encrypt investigate this matter further? If there are any regional restrictions or inadvertent blocks impacting Kazakhstan, it would be helpful to understand the cause and explore potential solutions. Thousands of users in Kazakhstan rely on Let's Encrypt for SSL certificates, and resolving this issue would significantly benefit the community.