GitHub Pages certificate stuck in bad_authz after domain resets (jarvisserver.org)

[hotboxking09]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

GitHub Pages custom-domain certificate stuck in bad_authz

• Public repository: https://github.com/hotboxking09/jarvis-systems-website
• Custom domain: jarvisserver.org
• Alternate hostname: www.jarvisserver.org
• Deployment status: built

The Pages API still reports this on 2026-11-05:

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

Direct TLS verification against GitHub Pages IP 185.199.108.153, using each hostname as SNI, fails because the origin certificate is expired. The public website remains reachable through Cloudflare; that does not establish valid origin TLS.

Steps already tried

On 2026-11-04:

1. Temporarily disabled Cloudflare proxying for only the four apex A records (185.199.108.153 through 185.199.111.153) and the www CNAME (hotboxking09.github.io).
2. Confirmed through Pages DNS health that both domains pointed to the expected GitHub targets, were HTTPS-eligible, and had no CAA error.
3. Removed and re-added the unchanged Pages custom domain twice. The second attempt was after the positive DNS-health result.
4. Rechecked the certificate state and direct TLS verification: still bad_authz / expired certificate.
5. Restored the original Cloudflare proxy flags rather than leave visitors connecting directly to the expired certificate. Current DNS-health results therefore see the proxy again.

We have not established a successful uninterrupted DNS-only issuance window of a full hour, and do not want to imply otherwise. The failed order appears to remain unchanged even after the domain resets.

Request

Could GitHub staff inspect whether this custom domain has a stuck ACME authorization/certificate order and reset it if appropriate? If an additional DNS-only window is necessary, what duration and observable order-state changes should we expect so we can coordinate this without an indefinite visitor outage?

The account's support portal does not offer technical Pages support, hence this Community request. I have reviewed the custom-domain troubleshooting documentation, including the DNS and remove/re-add guidance.

I understand a Community post is not a support SLA, and will verify both origin hostnames before considering this resolved. Thank you.

[GgauravJ05]

The step that's undoing your fix is #5. GitHub Pages gets its certificate from Let's Encrypt, and the validation request has to reach GitHub's servers for both names. Right now both jarvisserver.org and www.jarvisserver.org resolve to Cloudflare (104.21.19.65, 172.67.185.149) and responses come back with server: cloudflare, so the challenge can't reach GitHub and the authorization stays in bad_authz. The Pages API still shows the certificate expired since 2026-10-21. There are no CAA records on either name, so that isn't the blocker.

Re-adding the domain restarts the ACME order, but it then needs DNS to stay pointed at GitHub until issuance finishes. The docs say it can take up to an hour, and it can take longer when an order has failed before. Restoring the proxy the same day cuts that off.

Order that should work:

1. In Cloudflare, set the four apex A records and the www CNAME to DNS only (grey cloud) and leave them that way.
2. Wait until public DNS shows GitHub's IPs (dig +short jarvisserver.org → 185.199.108–111.153).
3. In Settings → Pages, remove the custom domain, save, then add jarvisserver.org again.
4. Don't touch DNS while you poll:

   gh api repos/hotboxking09/jarvis-systems-website/pages --jq .https_certificate

   Wait for approved/issued with a new expires_at. Then tick Enforce HTTPS.
5. Only after that, turn the proxy back on if you want it, with Cloudflare SSL/TLS mode Full (strict). Note that while proxied, renewals can fail the same way roughly every 90 days. Either stay DNS-only, or plan to repeat steps 1–4 before each expiry.

If it is still bad_authz 24 hours after step 3 with DNS-only the whole time, the order is stuck on GitHub's side, and that's worth reopening the Support ticket with this timeline.