Apex cert stuck in Awaiting certificates + rolling LE rate limits

Questions / Help
1

Hi Fly team/community, need help on a prod TLS issue.

App/domain:

What I see:

  • fly certs list:

  • fly certs check arpitdalal.dev repeatedly shows:

    • Too many certificate requests for this hostname

    • rate-limit window keeps moving

  • TLS on apex fails before cert is presented:

    • curl -Iv https://arpitdalal.dev => LibreSSL SSL_connect: SSL_ERROR_SYSCALL

    • openssl s_client … -servername arpitdalal.dev => unexpected eof while reading, no peer certificate available

  • www TLS is healthy on same IP/app.

DNS:

What I already tried:

  • fly certs add / fly certs remove + add for apex

  • Waited across cooldown windows

  • Verified app health/machines/checks are passing

  • Verified fly.toml has only [[services]] (no [http_service] overlap), with:

    • port 80 handler http + force_https=true

    • port 443 handlers [“tls”,“http”]

Question:

  • Could this be a stuck edge/SNI binding or ACME order loop for apex on Fly side?

  • Any recommended reset path besides add/remove that won’t keep extending LE rate limits?

3

:waving_hand: This is a common case of Cloudflare’s certificate pipeline conflicting with ours.

This is not what I see, I see Cloudflare IPs returned for the A record, which means Let’s Encrypt can’t issue an ALPN certificate for the domain since it resolves to Cloudflare.

The DNS certificate will also be failing as Cloudflare responds to TXT queries to _acme-challenge.arpitdalal.dev with their own challenge records. If you dig TXT _acme-challenge.arpitdalal.dev you’ll typically get different records than if you look up the TXT records of the CNAME target. The certificate issued for the www. subdomain fine, as Cloudflare does not inject any records on _acme-challenge.www.arpitdalal.dev.

The two options are:

  1. If you aren’t using any Cloudflare features, you can disable “orange cloud” proxying and point your app at Fly.io directly
  2. To work with the existing setup, import an origin certificate. See our Cloudflare guide for steps.
4

Thanks for the reply, but I have never configured Cloudflare for this domain. It is completely on fly. I had configured ALIAS DNS record before, here’s what I received from curl -Iv https://arpitdalal.dev before

╰─ curl -Iv https://arpitdalal.dev
* Host arpitdalal.dev:443 was resolved.
* IPv6: (none)
* IPv4: 66.241.124.237
*   Trying 66.241.124.237:443...
* Connected to arpitdalal.dev (66.241.124.237) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to arpitdalal.dev:443
* Closing connection
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to arpitdalal.dev:443

Since www was working, I configured URL forwarding from apex to www temporarily.

I have now reverted DNS back to direct Fly A and AAAA, but it’s still failing on apex.

What I changed:

  • Removed the previous apex ALIAS/URL-forwarding setup I had temporarily enabled (that was only a fallback because www is working).

  • Set apex directly to Fly:

  • Kept:

Current state:

╰─ curl -Iv https://arpitdalal.dev
* Host arpitdalal.dev:443 was resolved.
* IPv6: (none)
* IPv4: 66.241.124.237
*   Trying 66.241.124.237:443...
* Connected to arpitdalal.dev (66.241.124.237) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to arpitdalal.dev:443
* Closing connection
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to arpitdalal.dev:443

Can you check if apex has a stuck ACME order / SNI binding on Fly’s side and reset it? DNS now resolves to Fly IPs on public resolvers.

5

This is what I see when I try to dig TXT _acme-challenge.arpitdalal.dev:

[peter@frmwk ~]$ dig TXT _acme-challenge.arpitdalal.dev

; <<>> DiG 9.20.19 <<>> TXT _acme-challenge.arpitdalal.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21538
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_acme-challenge.arpitdalal.dev.	IN	TXT

;; ANSWER SECTION:
_acme-challenge.arpitdalal.dev.	429 IN	TXT	"y7RMTjdD8OHZyW7j2yDi62rSQmBofh4SAhlaybu7-hA"
_acme-challenge.arpitdalal.dev.	429 IN	TXT	"jNKldraeytESw9TgmRou5PLUkbOkqutFYGpdIKClDLk"

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Mar 09 10:37:07 EDT 2026
;; MSG SIZE  rcvd: 171

These two records are not from Fly. For reference, this is what dig arpitdalal.dev.l9n051.flydns.net shows:

[peter@frmwk ~]$ dig TXT arpitdalal.dev.l9n051.flydns.net

; <<>> DiG 9.20.19 <<>> TXT arpitdalal.dev.l9n051.flydns.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20627
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;arpitdalal.dev.l9n051.flydns.net. IN	TXT

;; ANSWER SECTION:
arpitdalal.dev.l9n051.flydns.net. 286 IN TXT	"_k0GZYVjgraeQlm-SylTQfv6m2cK0j93VZ5Mez6YY4A"

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Mar 09 10:37:10 EDT 2026
;; MSG SIZE  rcvd: 117

I do indeed see a CNAME record on your domain if I dig CNAME directly

[peter@frmwk ~]$ dig CNAME _acme-challenge.arpitdalal.dev

; <<>> DiG 9.20.19 <<>> CNAME _acme-challenge.arpitdalal.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26623
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_acme-challenge.arpitdalal.dev.	IN	CNAME

;; ANSWER SECTION:
_acme-challenge.arpitdalal.dev.	600 IN	CNAME	arpitdalal.dev.l9n051.flydns.net.

;; Query time: 33 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Mar 09 10:37:04 EDT 2026
;; MSG SIZE  rcvd: 105

This seems to suggest that something about your DNS provider or domain registrar is inserting their own TXT records (which takes precedence over the ones over CNAME). You’ll need to contact them to have them remove these if that is the case.

6

Yes, that was the issue, seems like the TXT records were there from earlier, not sure why I added them. But it is resolved now. Thank you very much for your help!

1 Like