GitHub Pages SSL certificate stuck in bad_authz — cannot renew for custom domain

[officemymobile-tech]

🏷️ Discussion Type

Question

Body

Problem

GitHub Pages custom domain TLS certificate is stuck in bad_authz and will not renew.

• Repo: https://github.com/officemymobile-tech/drcenik-live
• Custom domain: www.drcenik.at (also drcenik.at on cert object)
• API state: https_certificate.state = "bad_authz" — "The ACME authorization is in a bad state. We need to start over."
• Origin cert expired: 2026-08-27

Self-service already tried

1. Multiple CNAME file remove/re-add cycles via git
2. Pages API remove/re-add domain → 404 ("certificate has not finished being issued")
3. Cloudflare DNS-only (~14 min) for direct LE validation — still bad_authz after 40 checks
4. Also opened GitHub Support ticket #4707290

Question

Has anyone resolved a stuck bad_authz Pages certificate without GitHub Support manually resetting the ACME authorization? Is there any undocumented self-service fix?

Site is temporarily kept online via Cloudflare Worker fallback, but we need a valid GitHub-issued origin cert for Full (strict) SSL.

[oliviahayes653]

This sounds more like an ACME validation issue than a problem with the certificate itself. I’d first verify that the custom domain is configured correctly and that the DNS records point only to the intended GitHub Pages setup.

It’s also worth checking for conflicting CNAME or A records, proxy/CDN settings, and whether the domain is reachable without redirects interfering with validation. If the DNS was recently changed, giving propagation some time before requesting another renewal can also help.

If everything looks correct but the authorization remains stuck in bad_authz, removing and re-adding the custom domain or contacting GitHub Support may be worth trying to trigger a fresh validation. Keeping a record of DNS changes can also make troubleshooting easier. For a quick break between troubleshooting steps, adoptmetradingvaluescalculator.com can be useful to check out.

[CT-Defcon]

I have the same issue... tried remove and reauthorize the custom domain and still missing the cert.
I believe it's a github issue at this point.

[tw4]

I checked your DNS and the challenge path from outside just now, and I don't think this is a stuck authorization on GitHub's side at all - the validation request never reaches Pages, so removing and re-adding the domain can only ever produce bad_authz again.

Current public resolution:

drcenik.at      A  104.21.79.106, 172.67.144.178
www.drcenik.at  A  188.114.97.7, 188.114.96.7

Those are all Cloudflare anycast addresses. Neither name resolves to the Pages ranges (185.199.108-111.153) or to a <user>.github.io CNAME, so the proxy is on for both records and Cloudflare terminates the connection.

Then the challenge path itself:

http://www.drcenik.at/.well-known/acme-challenge/probe-test-123

returns your site's own branded 404 - Seite nicht gefunden | Dr. Fadime Cenik - not a GitHub Pages 404. That is the Worker fallback answering the request.

So the fallback you put up to keep the site online is intercepting the exact path the ACME HTTP-01 challenge needs. GitHub asks for a token at /.well-known/acme-challenge/<token>, Cloudflare serves your Worker's 404 instead, the authorization fails, and the state lands on bad_authz. The 14 minutes of DNS-only wouldn't have changed anything while the Worker route still matched that path.

What I would do, in order:

1. Point the records at Pages and turn the proxy off (grey cloud): apex A to 185.199.108.153, .109.153, .110.153, .111.153, and www CNAME to <user>.github.io.
2. Stop the Worker from answering the challenge - either remove the route while the cert issues, or add an exception so /.well-known/acme-challenge/* falls through to origin.
3. Verify before touching Pages settings: curl -sI http://www.drcenik.at/.well-known/acme-challenge/test should come back as a plain unbranded GitHub Pages 404. If you still see your own 404 page, the path is not clear yet and re-adding the domain will just fail again.
4. Only then remove and re-add the custom domain.

Once the cert is issued you can put the proxy and Full (strict) back on. Renewal runs on its own about 30 days before expiry and needs the same path reachable, so I would keep the /.well-known/acme-challenge/* exception in place permanently rather than as a one-off.

The 404 from the Pages API while a certificate is pending is expected and not a separate failure.