My app is an Elixir Phoenix app.
I seemingly cannot get an SSL certificate to issue for my app, and using letsdebug.net I think it might be because the
fly launch creates a fly.toml with
force_https = on in the fly.toml before it was ready for it, and therefore letsencrypt cannot verify due to 301 redirects on http to https. This is according to letsdebug.net
I’ve taken off the
force_https=true for now, letsdebug doesn’t detect any issues now, and hopefully over the next few hours letsencrypt will work and fly will recognize the SSL cert and I can launch the app.
However, after things are working, I’m worried about reenabling force_https in fly.toml. So, maybe my question is: why use
force_https=true in fly.toml versus configuring Phoenix’s endpoint to force_ssl? ie
force_ssl: [rewrite_on: [:x_forwarded_proto]] in config/prod.exs
Domain is ectoinproduction.com fly app is
We actually use the tls verification challenge, so the redirect is fine!
It looks like you might have a
txt record setup for
_acme-challenge.ectoinproduction.com, which is preventing us from validating. Will you double check that? I get it about every third query for this:
dig txt _acme-challenge.ectoinproduction.com +short
weird, I don’t have a txt record for _acme-challenge in my DNS settings at all. I’ll try adding one and then deleting it? Cloudflare is weird sometimes.
Ok, seems others have seen this to when using Cloudflare:
I’ll turn on development mode in Cloudflare and turn off SSL (I had it on flexible)
I’ll edit the title to reflect a little better what the problem is and give it a couple minutes to see if that phantom txt record disappears. Thanks @kurt
Here is what’s putting those TXT records: Universal SSL in Cloudflare.
Turning it off removes those phantom TXT records.
Ok, I’ll wait a bit to see if that fixes things. Thanks again @kurt. I’ll open a PR against the fly docs to add a troubleshooting section that includes this scenario.
Oh my gosh, you are amazing. This has hit several people over the last few weeks.