GitHub Pages: custom-domain certificate stuck in bad_authz — expired cert not renewed (dragonswim.org)

[becki01-dev]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Pages

Body

Repository: Dragon-Swim/dragonwebsite (public, Pages published from the gh-pages branch, CNAME = dragonswim.org)
Site: https://dragonswim.org

Our Let's Encrypt certificate for the custom domain expired on 2026-09-23T02:19:17Z and GitHub Pages
has not renewed it. The Pages API reports the ACME authorization in an unrecoverable state:

GET /repos/Dragon-Swim/dragonwebsite/pages returns:
"https_certificate": {
"state": "bad_authz",
"description": "The ACME authorization is in a bad state. We need to start over.",
"domains": ["dragonswim.org", "www.dragonswim.org"],
"expires_at": "2026-09-22"
}

The certificate GitHub Pages is still serving:
Subject : CN=dragonswim.org
Issuer : CN=YR1, O=Let's Encrypt, C=US
NotBefore: 2026-06-25T02:19:18Z
NotAfter : 2026-09-23T02:19:17Z <-- expired
SANs : dragonswim.org, www.dragonswim.org

This was the first renewal for this certificate. Because our Cloudflare zone uses SSL/TLS mode
Full (strict), the invalid origin certificate made the site return HTTP 526 for all visitors.

What we have already done, following GitHub's documented procedure:

1. Corrected DNS to the documented GitHub Pages values and verified from public resolvers:
   • dragonswim.org CNAME -> dragon-swim.github.io (Cloudflare apex CNAME flattening)
     -> 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153
   • dragonswim.org AAAA -> 2606:50c0:8000::153, 2606:50c0:8001::153,
     2606:50c0:8002::153, 2606:50c0:8003::153
   • www.dragonswim.org CNAME -> dragonswim.org -> same GitHub Pages addresses
   • No extra or conflicting A / AAAA / CNAME records
   • No CAA records exist for the domain (nothing blocks letsencrypt.org)
2. Removed and re-added the custom domain twice (Settings > Pages > Remove, retype, Save) to cancel
   and restart provisioning. The domain was restored successfully each time and a new Pages build was
   triggered. The certificate state never leaves bad_authz.
3. Verified the ACME HTTP-01 challenge path is served by GitHub and is not intercepted:
   curl http://dragonswim.org/.well-known/acme-challenge/probe-token -> 404 from GitHub.com
   curl http://www.dragonswim.org/.well-known/acme-challenge/probe-token -> 404 from GitHub.com (no redirect)
   http://www.dragonswim.org/somepage -> 301 to the plain-HTTP apex (no HTTPS redirect)
   Enforce HTTPS is off (https_enforced = false).
4. Re-polled https_certificate.state for over an hour; it never changes.
5. Our GitHub Support ticket form has no Pages/HTTPS topic at all (only Copilot, Codespaces,
   Repositories, Education, Sign-in issues, Billing), which is why we are reporting this here.
   We have stopped repeating the remove/re-add cycle, since we now understand that repeating it
   before an ACME HTTP-01 challenge completes can trigger Let's Encrypt rate-limit backoff.

We have seen several reports of this exact failure and understand it needs a server-side reset:
#199413, #199774, #204388 (even a full Pages recreation does not clear it), #206054, #208319,
#208551.

Could a GitHub staff member please reset the stuck ACME authorization for this Pages site so a new
certificate order can be issued for dragonswim.org and www.dragonswim.org?

Impact: the site is unreachable over HTTPS for our swim club members as long as the origin
certificate remains invalid.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Harshul1484]

The cause is the Cloudflare proxy. Public DNS for both dragonswim.org and www.dragonswim.org returns Cloudflare's addresses (104.21.33.246, 172.67.151.252 and the matching AAAA records), not GitHub's. To renew the certificate, GitHub has to validate the domain against its own servers, and with the proxy on, that check reaches Cloudflare instead. That's why the Pages API is stuck at bad_authz and GitHub is still serving the certificate that expired on September 23 at 02:19 UTC. I checked just now, and both are still the case.

To get a new certificate:

1. In Cloudflare DNS, switch the dragonswim.org and www records to DNS only (grey cloud) and point them at GitHub: A records 185.199.108.153 to 185.199.111.153 for the apex, and a CNAME to dragon-swim.github.io for www.
2. Once public DNS returns GitHub's addresses, go to Settings → Pages, remove the custom domain and add it again. That restarts provisioning, which is what the docs recommend when a certificate is stuck.
3. When the new certificate shows up and "Enforce HTTPS" becomes available, the site works over HTTPS directly from GitHub.

Keep in mind that each renewal (roughly every 90 days) runs into the same problem while the proxy is on. So either leave these records on DNS only, or plan to switch the proxy off before every expiry.

[becki01-dev]

Update: followed the DNS-only advice end to end, waited ~13 hours — still bad_authz

Thanks again for the DNS analysis. We followed it exactly, because if the proxy were the
cause we wanted it gone before retrying. Here is what we did and what happened.

1. Both records moved to DNS only and pointed at GitHub Pages
   • dragonswim.org -> CNAME dragon-swim.github.io (Cloudflare flattens the apex CNAME)
   • www.dragonswim.org -> CNAME dragon-swim.github.io (previously CNAME dragonswim.org)

Verified from two public resolvers (Cloudflare DoH and Google DoH, 2026-10-01 22:46 UTC).
Both names returned only GitHub's addresses — no Cloudflare addresses remained:

dragonswim.org A 185.199.108.153 185.199.109.153 185.199.110.153 185.199.111.153
dragonswim.org AAAA 2606:50c0:8000::153 ... 2606:50c0:8003::153
www.dragonswim.org A 185.199.108.153 185.199.109.153 185.199.110.153 185.199.111.153

There are no CAA records for the domain.

2. Verified the ACME HTTP-01 path is answered by GitHub itself

$ curl -sI http://dragonswim.org/.well-known/acme-challenge/probe-token
HTTP/1.1 404 Not Found
Server: GitHub.com
X-GitHub-Request-Id: B5CA:27FF9:397EB6:45664D:6ABEE2E7

$ curl -sI http://www.dragonswim.org/.well-known/acme-challenge/probe-token
HTTP/1.1 404 Not Found
Server: GitHub.com
X-GitHub-Request-Id: ...

No redirect, and nothing else in front answering that path. Plain HTTP to the apex returns 200
from GitHub's range (e.g. 185.199.109.153).

3. Removed the custom domain, waited, then re-added it exactly once

   • 22:47 UTC — cleared Custom domain in Settings > Pages (cname: null, https_certificate: null)
   • 22:59 UTC — re-added dragonswim.org; first attempt succeeded and a new Pages build triggered
     We deliberately did NOT repeat the remove/re-add cycle this time, since repeated attempts
     before an ACME challenge completes can trigger Let's Encrypt rate-limit backoff.

4. Then we changed nothing and waited 12 h 49 min
   Automated polling (1-minute, then 5-minute intervals) from 22:32 UTC through 11:48 UTC the
   next day — 112+ consecutive checks, every single one identical:

   cert=bad_authz originNotAfter=2026-09-23 https=000

   GitHub Pages is still serving the same expired certificate:

   Subject : CN=dragonswim.org
   Issuer : CN=YR1, O=Let's Encrypt, C=US
   NotBefore: 2026-06-25T02:19:18Z
   NotAfter : 2026-09-23T02:19:17Z <-- expired
   SANs : dragonswim.org, www.dragonswim.org

   and the Pages API still returns the same object:

   "https_certificate": {
   "state": "bad_authz",
   "description": "The ACME authorization is in a bad state. We need to start over.",
   "domains": ["dragonswim.org", "www.dragonswim.org"],
   "expires_at": "2026-09-22"
   }

Current state
Because DNS-only means visitors hit the expired certificate directly, and no certificate was ever
issued, we had to restore the Cloudflare proxy with SSL/TLS mode Full as a stopgap so the site
stays reachable. The origin certificate is still expired, so this is a workaround, not a fix.

Question
With DNS resolving exclusively to GitHub Pages, the HTTP-01 path answered by GitHub, the custom
domain removed and re-added only once, and nothing changed for ~13 hours — is there anything else
we can do from our side?

This looks like the terminal/stuck authorization described in #204388 and #208319. Could a GitHub
staff member please reset the stuck ACME authorization for this Pages site so a new certificate
order can be issued for dragonswim.org and www.dragonswim.org?

Repository: Dragon-Swim/dragonwebsite
Site: https://dragonswim.org

Thanks!