GitHub Pages custom domain: HTTPS certificate stuck at state "new" for 6+ hours

[hidenori-tani]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

(Reposting the body — my first paste lost all Markdown formatting, and the topic area was wrong. Same content, now readable.)

Repo: hidenori-tani/hidenori-tani.github.io (user site, public, build_type: legacy)
Custom domain: www.hidenoritani.com (apex hidenoritani.com points at the Pages IPs)
Plan: GitHub Free

What happens

I moved this domain from another host to GitHub Pages on 2026-08-29 ~01:45 JST.
The site is served correctly over HTTP (200 from 185.199.108-111.153), but the HTTPS
certificate has never been issued. Over HTTPS the edge presents the *.github.io wildcard
certificate, so browsers show ERR_CERT_COMMON_NAME_INVALID.

GET /repos/hidenori-tani/hidenori-tani.github.io/pages has returned the same thing for
more than 6 hours:

"https_certificate": {
  "state": "new",
  "description": "This domain was recently added. The certificate request process will begin shortly.",
  "domains": ["www.hidenoritani.com"]
}

The Enforce HTTPS checkbox in Settings → Pages stays greyed out.

What I have already checked

GET /repos/hidenori-tani/hidenori-tani.github.io/pages/health reports no problem for
either host:

field	www.hidenoritani.com	hidenoritani.com
dns_resolves	true	true
is_served_by_pages	true	true
is_valid / reason	true / null	true / null
is_https_eligible	true	true
caa_error	null	null
https_error	peer_failed_verification	peer_failed_verification

DNS, queried against the authoritative nameservers directly (not a cached resolver):

www.hidenoritani.com.  CNAME  hidenori-tani.github.io.        (TTL 600)
hidenoritani.com.      A      185.199.108.153 .109.153 .110.153 .111.153
hidenoritani.com.      AAAA   2606:50c0:8000::153 .. 8003::153

• CAA: NOERROR with no CAA records at both hidenoritani.com and
  www.hidenoritani.com, so issuance is unrestricted. www is a CNAME to github.io,
  whose CAA permits letsencrypt.org.
• DNSSEC: no DS record.
• HSTS preload: hstspreload.org reports status: unknown (not preloaded).
• CNAME file: present in the repo root, exactly www.hidenoritani.com — 20 bytes,
  no BOM, no trailing newline.

What I have tried

I removed and re-added the custom domain twice (02:03 and 04:55 JST), which is the
documented remedy after changing DNS. The first time moved the state from no certificate
to new; the second time it stayed at new. I have not touched DNS since, so as not to
restart provisioning.

This does not look like an isolated case

Three other reports with the same symptom have appeared in the last four days:

• Pages custom-domain certificate never issued — stuck in "new"/"authorization_created" for 56 days (pontonniersbex.ch) #205765 (2026-08-25) — stuck at authorization_created; the author reports that
  GitHub Support ticket #4703929 was closed on 2026-08-27 and redirected here
• GitHub Pages custom domain stuck on default *.github.io certificate despite clean DNS and successful DNS check #206017 (2026-08-27) — certificate never issued for a custom domain
• GitHub Pages SSL certificate stuck in bad_authz — cannot renew for custom domain #206054 (2026-08-28) — remove/re-add does not help either

githubstatus.com currently shows All Systems Operational with GitHub Pages
operational, so whatever this is, it is not being surfaced there.

Question

Is there anything left on my side, or is this waiting on certificate provisioning at
GitHub's end? If someone from the Pages team can nudge issuance for www.hidenoritani.com
(and hidenoritani.com), that would be much appreciated.

Happy to provide anything else that helps.

[hienvanla5]

Hi @hidenori-tani,

Based on the information you've provided, it sounds like you've already completed the common troubleshooting steps on your side.

The part that stands out to me is that:

is_valid is true
is_served_by_pages is true
is_https_eligible is true
DNS appears to be resolving correctly to GitHub Pages
The certificate state remains new

Given those results, I don't see any obvious DNS or Pages configuration issue in your setup.

I would avoid removing and re-adding the custom domain again for now. Since certificate provisioning has already entered the new state, additional changes could potentially restart whatever process is currently happening behind the scenes.

The fact that you've also linked several recent discussions describing similar certificate issuance problems makes me wonder whether this is related to a broader Pages certificate provisioning issue rather than an individual repository misconfiguration.

Unfortunately, Community members cannot directly inspect or trigger certificate issuance, so I don't think anyone here can manually "nudge" the process. From what you've shown, this looks more like something that would need attention from the GitHub Pages infrastructure team if the certificate continues to remain in the same state.

For now, I would monitor the Pages API response and avoid making further DNS changes unless new evidence points to a configuration problem.

Thanks for including the health-check output and DNS details. That makes the issue much easier to evaluate.

[iawaisahmd]

given the health endpoint says both hosts are valid, served by pages, and https-eligible, i don't see much left to change locally. the useful signal now is whether the certificate state advances from new at all. i'd leave dns and the custom domain untouched for at least another provisioning cycle, then update this thread with the exact duration and current api state. since several recent reports show similar behavior, grouping the affected domains and states here may help github identify a wider certificate queue issue.

[Mohan-I]

To be honest, Run with Cloudflare proxying and Flexible SSL right now. It gets your site up securely in under five minutes, completely insulating you from GitHub's infrastructure outages.
You can use Cloudflare SSL instead to run your GitHub Pages website over HTTPS. To route your site safely through Cloudflare without creating infinite redirection errors, use these exact parameters:

---

Step-by-Step Config :

1. Adjust Cloudflare DNS settings

Log into Cloudflare and ensure your records match the architecture you evaluated, but with the Proxy turned ON (Orange Cloud):

• Type: CNAME | Name: www | Target: hidenori-tani.github.io | Proxy Status: Proxied
• Type: A | Name: @ (apex) | Point to the four standard GitHub IPs (185.199.108.153, etc.) | Proxy Status: Proxied

2. Set SSL/TLS Encryption Mode to "Flexible"

Because GitHub currently lacks a valid cert for www.hidenoritani.com, you must not use Cloudflare's Full or Full (Strict) mode right away, as Cloudflare will reject GitHub's mismatched *.github.io wildcard certificate.

• Go to SSL/TLS > Overview in your Cloudflare dashboard.
• Change the mode to Flexible.
• This forces HTTPS between your users and Cloudflare, while allowing Cloudflare to communicate over port 80/HTTP with GitHub behind the scenes.

3. Handle Redirection at Cloudflare

• Go to SSL/TLS > Edge Certificates.
• Turn Always Use HTTPS to ON. This guarantees users typing http:// instantly transition to a secure tunnel.

4. Leave GitHub "Enforce HTTPS" Disabled

In your GitHub Repo under Settings > Pages:

• Do not check "Enforce HTTPS". (Since the internal provisioning is stuck, it will likely remain greyed out anyway).
• Leaving this unchecked on GitHub prevents GitHub from trying to issue its own redirect commands, which avoids throwing your site into an infinite ERR_TOO_MANY_REDIRECTS loop when combined with Cloudflare's Flexible proxying.

---

The Alternative:

If you strictly want a native GitHub Let's Encrypt certificate without using Cloudflare's edge proxy, the latest community workarounds for this specific systemic glitch require a complete validation reset:

1. Turn your Cloudflare records to DNS Only (Grey Cloud icon).
2. Go to GitHub Pages settings, delete your custom domain entirely, and save.
3. Wait at least 15–30 minutes to ensure GitHub's routing table clears out database artifacts of your site.
4. Re-type www.hidenoritani.com into GitHub Pages and save. This initiates a completely fresh ACME challenge request to Let's Encrypt rather than parsing the stuck "state": "new" payload.

[hidenori-tani]

48-hour update: still state: "new", unchanged.

GET /repos/hidenori-tani/hidenori-tani.github.io/pages at 2026-08-30 16:06 UTC:

"https_certificate": {
  "state": "new",
  "description": "This domain was recently added. The certificate request process will begin shortly."
}

That is 47h21m after the custom domain was added (2026-08-28 16:45 UTC). The description string has not changed once in that window. HTTPS still terminates on the *.github.io wildcard, and Enforce HTTPS is still greyed out. I have not touched DNS or the custom domain since 2026-08-28 19:55 UTC.

Grouping what has been reported, in case it helps identify a queue-side issue rather than five separate misconfigurations:

discussion	domain	reported	state
#205765	www.pontonniersbex.ch	2026-08-25	new / authorization_created, 56 days, 3 attempts
#205765	www.27pm.org	2026-08-27	authorization_created
#206017	www.wirelesssharenotes.com	2026-08-27	default *.github.io served after DNS was cleaned
#206054	www.drcenik.at	2026-08-28	bad_authz — renewal failure, origin cert expired 2026-08-27
#206054	(a second reporter, domain not given)	2026-08-28	same, remove/re-add did not help
#206108	www.hidenoritani.com	2026-08-29	new, 47h

Five named domains across four threads in six days. Every one reports is_valid: true and is_https_eligible: true from /pages/health. Two support tickets have been opened and closed — #4697430 and #4703929 — both redirected to Community. githubstatus.com has shown GitHub Pages operational throughout.

#206054 is worth separating from the rest: that is not a first issuance but a renewal that failed, and the origin certificate has already expired. A site that was working is now broken.

Is anyone from the Pages team able to look at the provisioning queue?