Awaiting certification 11 hours?

Questions / Help
1

My domain feder.is is waiting certification too long. When I first deployed, certification was a matter of seconds. Then I changed some configurations and replaced the deployment. Now it says 11 hours. I tried reading other threads with similar problems, changing app name and replacing deployment again but futile. What did I miss?

~/feder % fly certs show feder.is
The certificate for feder.is has not been issued yet.

Hostname                  = feder.is

DNS Provider              = isnic

Certificate Authority     = Let's Encrypt

Issued                    = 

Added to App              = 11 hours ago

Source                    = fly

Your certificate for feder.is is being issued. Status is Awaiting certificates. Make sure to create another certificate for www.feder.is when the current certificate is issued.

Given IPs

Screen Shot 2022-10-04 at 8.52.50

Screen Shot 2022-10-04 at 8.54.16
Screen Shot 2022-10-04 at 8.54.161274Ă—872 78.6 KB

ISNIC Setting

Screen Shot 2022-10-04 at 8.42.38
Screen Shot 2022-10-04 at 8.42.38706Ă—280 19.9 KB

Screen Shot 2022-10-04 at 8.54.46
Screen Shot 2022-10-04 at 8.54.461114Ă—798 67.8 KB

fly.toml

# fly.toml file generated for feder-is on 2022-10-03T18:52:15-04:00

app = "feder-is"
kill_signal = "SIGINT"
kill_timeout = 5
processes = []

[env]
  DATABASE_URL = "data/app.db"
  PUBLIC_FULLSTORY_ID = "o-1CJYM6-na1"
  PUBLIC_GOOGLE_OAUTH_ID = "1078468840440-uctnen8r63i2ksd0g2cial7fjsitkfcp.apps.googleusercontent.com"

[experimental]
  allowed_public_ports = []
  auto_rollback = true

[mounts]
  destination = "/data"
  source = "data"

[[services]]
  http_checks = []
  internal_port = 3000
  processes = ["app"]
  protocol = "tcp"
  script_checks = []
  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    force_https = true
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

  [[services.tcp_checks]]
    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"

Screen Shot 2022-10-04 at 8.54.16
Screen Shot 2022-10-04 at 8.54.161274Ă—872 78.6 KB

2

Looking into it now. This might be our mistake.

1 Like
3

Looks like there were too many certificates created for this hostname.

I see there were 4 records for it and 2 of them issued certificates. This means we’ve reached the limit for the hostname with Let’s Encrypt.

I’m going to manually fix the issue for this instance and see what might’ve caused it to happen too much.

Sometimes it takes minutes for a certificate to be issued depending on DNS and our queues. Sometimes seconds, sure :slight_smile: Definitely not hours unless the hostname is misconfigured.

4

Ok, I fixed this.

Looks like your hostname is not pointed at your IPs, unfortunately.

1 Like
5

Wow I was tinkering WORKDIR in Dockerfile in the meantime to see if it’s related. And I thought I fixed it for a moment. But you fixed it manually right? I appreciate it.

It’s weird I never kept multiple certifications not to mention apps. I was replacing them frequently though. If is it wrong to request certification too frequently, some guide or rate-limiting would have been useful.

6

I think part of it is on our end.

If you created multiple apps trying to fix the issue in the past day, it’s possible we created certificates for deleted apps and reached the limit.

1 Like
7

@jerome I may have the same issue as I’ve tried to “reboot” the certificate process and am still waiting for them to be issued. I have the check and AAAA records currently added to Cloudflare unproxied but it’s still just sitting waiting for issue. Can you advise if it can be fixed on your end or what I can do?

8

Unfortunately you seem to have hit a Let’s Encrypt limit here. Did you create a bunch of apps with the same hostnames? We reached the limit of 5 issues certificates per hostname in the last 7 days. Next time we can retry is in a while.

For now I’ve reassigned the already-issued certificates from your deleted app to your new app. I believe that works now.

9

Thank you Jerome! This will work for now. We had a problem rotating Rails’ secret where I couldn’t deploy the latest code because the secret didn’t match on the server and I couldn’t update the secret because then the app couldn’t boot :dizzy_face: I tried a bunch of things in the process which resulted in the multiple certificate requests.

10

Hey @jerome, I think I have the same issue. Testing some things I recreated some instances many times. Now the certificates doesn’t work. Can you help me restoring a past cert?

My app: prod-kipo
Host: api.

Right now it is not pointing to where it should, but to prod-api. since I had to do that workaround since I have live apps with that endpoint.

Thanks!

11

Hey @jerome, I think I have the same issue. Testing some things I recreated some instances many times. Now the certificates doesn’t work. Can you help me restoring a past cert?

My app: hyosakura
Host: blog/@

Thanks!

12

Looks like you deleted / recreated this app a lot. This can cause issues with certificates.

For example, we’re getting an error for your blob. certificate because too many certificates were issued for it in the last week.

I’ve manually fixed the situation this time :slight_smile:

We should make this error bubble up to our users, it’s confusing when it happens.

13

I encountered the same problem. In fact, Fly.io does not clearly tell people that, in general, it is not necessary to add the CNAME of _acme. The DNS requirements on Dashbord are somewhat misleading. Instead, only A and AAAA records need to be created (for example.com), as well as, a CNMAE pointing to appname.fly.dev (for www.example.com). Remember, make sure to configure DNS correctly before creating the certificate, otherwise you will have to wait a long time to get it.

14

Hey @jerome, here is another one who deleted/recreated his apps multiple times and now issuing the certificates takes forever, sorry! :sweat_smile: Can you please help me restoring those?

App 1: snipavatar-api-avatar
App 2: snipavatar-api-app

Just to be sure; I don’t need the A record if I just use subdomains but would just point the AAAA records to the correct ipv6 addresses, right? Because the root is a static site hosted on Cloudflare. But I still need to add the acme challenge CNAME I think?

Thanks!

15

Can someone please look into this? :confused: I would really like to fix it by myself, but the certificate just won’t get issued at all and my apps are basically down since then.

16

Sorry I didn’t see this before.

Are things working now?

1 Like
17

Thanks, it’s working now