What commands are you using to create the certs (and in what order?). I can see that there’s currently not a cert for tiffr when I try to curl it. Would you mind sharing your DNS records (you can send them to support@fly.io if you don’t want to post here).
I just removed the certs again via the CLI with fly certs remove tiffr.com.
To add the certs, I had used the web interface the first time, and the CLI the second time around with fly certs add tiffr.com followed by fly certs add "*.tiffr.com".
Relevant DNS records on Cloudflare look like this:
I’m not sure if this is relevant, but I’m moving this domain from pointing at a VPS that was generating Let’s Encrypt certs for this domain to pointing it at Fly. Do you know if I need to explicitly revoke old certs before trying to generate new ones?
Ah, okay, I think there’s probably something else you should try. From that config, it looks like Cloudflare supports wildcard DNS records. I’d try removing those-- the DNS-01 challenge just needs the _acme-challenge.
I removed the wildcard DNS records and revoked the cert from my prev server, then kicked off a new cert request (for non-wildcard, then for wildcard), but still am not receiving certs. Are there logs I can look at from the certificate request handshake? Any other suggestions you can think of?
I have another domain I pointed at the same site that I setup at the end of June, and they came through in a couple of minutes. Also using Cloudflare with the same DNS records.
Hi! We took a look at things on our end-- we’re seeing that you’re getting rate-limited with Let’s Encrypt. Their rate limits docs may come in handy here.
To get both an apex cert and a wildcard on fly, what seems to work best is to create an apex domain, wait a few hours and check that it’s working, then issue your CSR via fly certs for the wildcard.
I suspect that we’re seeing this issue with Cloudflare specifically since they’re flattening the CNAME to our DNS delegation (the *flydns.net target). Conveniently, there’s a (slightly old) list of DNS providers that support CNAME flattening
And as @tomasztomczyk pointed out earlier, an alternate approach for DNS providers that support CNAMEs at the apex is to set the app hostname as the target 
1 Like
I was going deep on this issue this morning, and at some point in the process, the apex domain was verified and the cert was issued! Not sure if it was related to anything I did or if it was just that the rate limit window opened up in that period.
I guess I’ll just try to be a bit patient for the wildcard certificate now, although I have a narrow window to get this sorted out at this point, need it up by Monday.
Given that Cloudflare automatically provisions certs for all domains (and wildcard subdomains) using their DNS, do I even need the certs on Fly? Are the Cloudflare certs sufficient?
the apex domain was verified and the cert was issued!
Glad to hear it!
Given that Cloudflare automatically provisions certs for all domains (and wildcard subdomains) using their DNS, do I even need the certs on Fly? Are the Cloudflare certs sufficient?
If you’re already using Cloudflare’s proxy, and want them to also handle TLS termination, that would also work. Certainly it would be convenient to have your cert and DNS settings in the same place!
Actually, I can’t solely depend on Cloudflare if I want the traffic to be encrypted end-to-end, the origin server still needs to present a cert for traffic that is proxied through.
This system is so opaque, is there a way to see the logs or status of the certificate requests Fly is making? How would I, as an end user, know about the rate limit without you telling me? Also, I’m guessing that there’s some retry functionality on the Fly backend because there’s no way I’m being rate limited based on my personal actions (definitely haven’t been issued 50 certificates for this registered domain this week or created 300 new orders in any 3 hour period).
Does running fly certs show "*.tiffr.com" make a new cert request? What about fly certs check "*.tiffr.com"?
We critically need this working by Sunday, as this is putting our launch in jeopardy at this point, which is a shame as I started this process a week ago. Anything you can do to help is greatly appreciated.
As a follow up, there’s no rate limiting happening from the Let’s Encrypt end, as far as I can tell. I’ve checked with the Let’s Debug tool and it seems that the DNS-01 challenge for the wildcard domain should have no problems and the rate limit is nowhere near being hit with only 3 certs in the last week.
I also successfully generated a cert today for both tiffr.com and *.tiffr.com on another server with no issue, which is the most recent cert created in the above.
So I’m not sure why Fly is having an issue getting these certs, but there does seem to be some problem with your system. If someone can manually run the cert request for me to push this along that would be great. I can also securely send you the cert I generated if you want to just install that instead.
Open to other suggestions as well.
1 Like
Oh, nice-- that Let’s Debug tool is super useful. We did get a rate limit response from Let’s Encrypt for that domain a few days ago, but I don’t think I’ll be able to find the exact reason anymore.But based on that output, I think I might be able to better explain what’s going on here.
At the moment, having certs for *.example.com and example.com doesn’t support acme-dns for both, since it would need different values created for the TXT record that _acme-challenge.example.com resolves to. We could probably check for this and change how we issue CSRs to accomodate this setup better.
And if you used TLS-ALPN for the apex, you’d need to remember that Cloudflare proxying has to be off for the CSR. So this is definitely a bit of a sharp edge, you’re 100% correct there.
1 Like
I’m also having the same issue.
I have these settings on Cloudflare, proxy is off, but my apex is not getting the certs created (www works fine)
Hey there – have you also turned off universal SSL ?
I can see that the certificate for your apex isn’t being created because of an incorrect TXT record, so it’s definitely worth it to check
How long should it take for certificates to get issued?
I tried to setup a cert yesterday and the site was still not up this morning.
I deleted the cert and re-tried this morning.
My cert is verified by it is “Awaiting certificates” for 3 hours now.
The certificate for docs.staging.vex.dev has not been issued yet.
Hostname = docs.staging.vex.dev
DNS Provider = dnsimple
Certificate Authority = Let's Encrypt
Issued =
Added to App = 3 hours ago
Source = fly
Your certificate for docs.staging.vex.dev is being issued. Status is Awaiting certificates. Make sure to create another certificate for www.docs.staging.vex.dev when the current certificate is issued.```Looks like a cert got issued after about 30 hours. In my experience of using LetsEncrypt directly it is usually instantaneous, so I’m guessing that either the Fly machinery got its act together, or someone there gave it a good kick.
For my case, I’ve added and deleted the app numerous times (due to lots of trials and errors in the configuration), with the domain (it’s a subdomain actually) re-added almost each time. The certificate was generated first time. But after a few retries, it stopped issuing certificate. And now my certificate is in awaiting state. How long should I wait before I check it again? The app is ready to use now, but I can’t use it without the domain setup. And, is there any way to clear out the wait time?
Any solution? i’m facing same problem…
I am facing same issue for my side, in my case i am only facing it for naked domain. For another domain with www it has created certificate, while checking for flyctl certs check vishalsadriya.dev i am getting below output
The certificate for vishalsadriya.dev has not been issued yet.
A Record ([MASKED_IP]) does not match app's IP ([MASKED_IP])
AAAA Record ([MASKED_IP]) does not match app's IP ([MASKED_IP])
Address resolution ([MASKED_IP]) does not match app's IP ([MASKED_IP]/[MASKED_IP])
Address resolution ([MASKED_IP]) does not match app's IP ([MASKED_IP]/[MASKED_IP])
Address resolution ([MASKED_IP]) does not match app's IP ([MASKED_IP]/[MASKED_IP])
Address resolution ([MASKED_IP]) does not match app's IP ([MASKED_IP]/[MASKED_IP])
You are creating a certificate for vishalsadriya.dev
We are using lets_encrypt for this certificate.
You can direct traffic to vishalsadriya.dev by:
1: Adding an A record to your DNS service which reads
A @ [MASKED_IP]
You can validate your ownership of vishalsadriya.dev by:
2: Adding an AAAA record to your DNS service which reads:
AAAA @ [MASKED_IP]
Any idea how to fix this?
Hi, would also like to bump this related issue Delayed: awaiting certificates - #3 by justmars which appears to be similar to @msrumon 's issue. Wish there was more transparency other than “awaiting certificate” issuance.