Awaiting Certificates

Hi Fly folks. :wave:

I’m trying to setup MinIO with a custom domain name and I’m hitting a snag. I tried setting up using the speed run instructions from the blog post and added A and AAAA records but that seemed to not issue the certificate. I realized that I probably wanted CNAME instead so switched the DNS records per the docs page but I’m still not seeing it issued.

$ fly certs show
The certificate for has not been issued yet.

Hostname                  =

DNS Provider              = name

Certificate Authority     = Let's Encrypt

Issued                    = 

Added to App              = 22 hours ago

Source                    = fly

Your certificate for is being issued. Status is Awaiting certificates.

I’m sure I’m doing something dumb but I’m not sure what. Do I need to remove the cert and start over? Also, I haven’t seen any instructions regarding an acme challenge mentioned in other posts so maybe that’s what I’m missing?

I believe A/AAAA or CNAME is fine with certs.

Do you use Cloudflare for the DNS? Only its orange-cloud/proxy DNS records can cause issues, I’ve found. The DNS record may need to be grey-cloud/non-proxy.

Failing that, it’s worth trying adding the acme challenge DNS entry too. The CLI does not reveal that as far as I know, so you have to get it from the dashboard. If you sign in to that, click on the app, and look at certificates in there it should show the DNS entry to add. Which again, will need to be non-proxied (if using something like Cloudflare).

Failing that … not sure!

1 Like

We’re checking on this. A/AAAA should be fine, but so should CNAME!

@benbjohnson1 ok we figured it out. Your app doesn’t have a service on port 443, so we can’t issue the certificate (Lets Encrypt only connects to 443). If you add port 443 to your app config, you should be good to go.

Yep, it was the port 443. Thanks!

I’m also having this issue. How do you add the port? If it’s in toml file then it’s already there.

app = my-app

kill_signal = "SIGINT"
kill_timeout = 5
processes = []

  PORT = "8080"

  allowed_public_ports = []
  auto_rollback = true

  http_checks = []
  internal_port = 8080
  processes = ["app"]
  protocol = "tcp"
  script_checks = []

    hard_limit = 25
    soft_limit = 20
    type = "connections"

    handlers = ["http"]
    port = 80

    handlers = ["tls", "http"]
    port = 443

    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"

I have solved the issue with CNAME record temporary, but I would like to do via A & AAAA records.
For that, what to do? I mean on fly side and my application. I have followed the whole documentation.

You can see your app IPs with fly ips list. Set an AAAA record pointing to the IPv6 address, and set an A record pointing to the IPv4 address and you’ll be good!

yeah but I have already done that, it was awaiting for certification (Your certificate for … is being issued. Status is Awaiting certificates.) for a few hours. Then I did research in here, it says

Awaiting Certificates - #4 by kurt

So, say my config is right, no problem? It’s just a matter of time on DNS?

Certificates should be generated within a few minutes. If they aren’t, something is probably misconfigured.

Okay, so, is it safe to remove CNAME record and create A & AAAA records? Will it effect the current certificate?

I’m having similar issues and can’t make sense of what’s going on.

I’ve followed fly’s SSL for Custom Domains guide. It seems like the system can’t decide if certs were applied correctly. Checking the dashboard (Dashboard > Certificates > View) and they are listed as “verified”.

Also via command line:

$ flyctl certs show
The certificate for has been issued.

Hostname                  =

DNS Provider              = iwantmyname

Certificate Authority     = Let's Encrypt

Issued                    = rsa,ecdsa

Added to App              = 2 days ago

Source                    = fly


The certificate for has been issued.

But then:

$ flyctl certs check hostname
Error Could not find AppCertificate

IMO the documentation needs updating because I’m not doing anything extreme or custom and it’s not working as described.

Hey there, taking a look at a few different queries for your hostname I can see that there is an additional A record which points to an IP address outside of our network:

  "ip": "",
  "hostname": "",

There’s another cert that’s been in place since before this was added to the app, which I can see when curling and connecting on

* start date: Apr 21 21:00:29 2022 GMT
*  expire date: Jul 20 21:00:28 2022 GMT
*  subjectAltName: host "" matched cert's ""

But there’s also cert configured for your Fly app from 2 days ago, which you can see when you force a connection over

 curl -vvv --resolve ''
* Added to DNS cache
* Hostname was found in DNS cache
*   Trying
* Connected to ( port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  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:
*  start date: May 24 16:28:26 2022 GMT
*  expire date: Aug 22 16:28:25 2022 GMT
*  subjectAltName: host "" matched cert's ""
*  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 0x55f4b0ee92f0)
> GET / HTTP/2
> Host:

When you run that last command, are you running flyctl certs check hostname or flyctl certs check ?

If you got that response while supplying your domain instead of hostname, then it’s possible that the extra A record is tripping fly certs check up. Thanks for the question!

Just bumping this because I have the same issue. Wildcard certificate is still being issued since yesterday whereas the other one got issued really quick.

╰─$ fly certs list --config  fly.production.toml
Update available 0.0.337 -> v0.0.355.
Run "fly version update" to upgrade.
Host Name                 Added                Status                   20 hours ago         Ready
*                 21 hours ago         Awaiting certificates
╰─$ fly certs check "*" --config fly.production.toml
Update available 0.0.337 -> v0.0.355.
Run "fly version update" to upgrade.
The certificate for * has not been issued yet.
You are creating a wildcard certificate for *
We are using lets_encrypt for this certificate.

Ah, I think I might see the issue. Since you’re moving from a SAN to a wildcard cert, you’d need to create a CNAME record for the DNS-01 challege so that we can validate it.

But It doesn’t look like that’s set up yet when I run that domain against dnschecker.

Sorry, I didn’t really get what you’re saying. How’s it that I’m moving from SAN to a wildcard?

you’d need to create a CNAME record for the DNS-01 challege so that we can validate it.

How exactly do I do that? I’ve already followed everything mentioned here and set A, AAAA and CNAME ( records accordingly for both IPv4 and IPv6.

oh, my mistake with the link! but, I’m not seeing any answers for either:

Is it possible you’re using a DNS provider which is doing something unusual with their CNAME queries? What happens when you dig that subdoman against a large public resolver?

I’m using Namecheap and using their private email, might that be causing the problem here? I can try turning that off and see again.

I’m wondering how I’ve got the other certificate though for Doesn’t it require the same thing? At least the same CNAME is mentioned when I view the certificate status on the UI.

Edit: Turned off the private email service just now.

We use a different ACME challenge (tls-alpn-01) for requesting a cert if the CN only needs to match the apex domain, as it’s way more convenient for this use-case.

But it’s unlikely that tls-alpn-01 will ever support wildcards—if you’d like to know why, this thread goes into a little more detail:

1 Like

I think I’ve figured the problem. In the host name of CNAME record I was typing in the whole thing (i.e. but I was told I am not supposed to do that.

Well, I don’t know much about it, and I believe it was the CLI tool that tricked me into doing that if I recall the output correctly, because if you go to the UI, that shows a different thing which is correct I think but I was following the CLI tool.

My certificate just got issued by the way, thank you @eli !