GitHub Pages HTTPS cert stuck in bad_authz for custom domain — need ACME reset

[williambdean]

Issue

The HTTPS certificate for wright.germanbakingasheville.com on the 3pm-baking/wright repo is stuck in bad_authz state.

{
  "cname": "wright.germanbakingasheville.com",
  "https_certificate": {
    "state": "bad_authz",
    "description": "The ACME authorization is in a bad state. We need to start over.",
    "domains": ["wright.germanbakingasheville.com"]
  }
}

What I have tried

• Removed and re-added custom domain via API (multiple times)
• Fully deleted Pages site and recreated from scratch
• Waited between removal and re-addition (60s to 5 min)
• Deleted CNAME file from the repo to force a full reset
• Verified DNS is clean — CNAME resolves to 3pm-baking.github.io (no conflicting A/AAAA/CAA records)
• Cloudflare is DNS-only (gray cloud, no proxy)

Current state

• HTTP works fine — site serves correctly
• HTTPS cert state persists as bad_authz across full Pages site deletion/recreation

It looks like the ACME authorization needs a manual reset on the backend. Could a Pages maintainer take a look?

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.

[P-r-e-m-i-u-m]

You've already done great troubleshooting — the bad_authz ACME state persisting through full site deletion/recreation confirms this needs a backend reset that isn't possible from your side.

A few things worth noting:

The DNS setup looks correct. Cloudflare DNS-only (gray cloud) + CNAME pointing to <org>.github.io is the right configuration. No proxy means Let's Encrypt can reach GitHub's servers directly, which is what you want.

Why bad_authz persists:
The ACME challenge state is tied to GitHub's backend ACME account, not your Pages site config. When you delete and recreate the site, GitHub reuses the same ACME registration for your account. If that registration got into a bad state (e.g., a previous challenge failed too many times or timed out in a way that corrupted the authz object), it stays broken across site recreations. This is a known issue.

What will actually fix it:

1. Contact GitHub Support directly — the community forum maintainers can't reset ACME state:
   👉 https://support.github.com/contact
   Choose Pages > HTTPS/TLS and include:

   • Repo: 3pm-baking/wright
   • Domain: wright.germanbakingasheville.com
   • Current cert state: bad_authz
   • That you've already tried full site deletion/recreation and DNS is verified clean

2. Ask specifically for an ACME authorization reset — they know what this means and can trigger it manually.

Temporary workaround while you wait:
Your HTTP site works fine. If you need HTTPS urgently, you could put Cloudflare in proxy mode (orange cloud) temporarily — Cloudflare will issue its own cert for the domain. Just switch back to DNS-only after GitHub fixes the ACME state so GitHub can complete its own challenge.

Refs:

• Managing a custom domain for GitHub Pages
• Troubleshooting custom domain verification
• Let's Encrypt ACME spec