Pages HTTPS certificate stuck at "new" for 48+ hours on an apex custom domain (two remove/re-add cycles, health reports no blocking condition)

[joung2076-cyber1076]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Our GitHub Pages custom domain has been stuck at certificate state "new" for
over 48 hours. It has never reached "errored" - the request simply never
started. We have ruled out every common cause we could find (DNS, CAA, DNSSEC,
domain conflicts, deployment interference) and the health endpoint reports no
blocking condition. Posting the full API output below in case anyone from the
Pages team can see why the request is not being queued - or in case someone
has hit the same thing.

Repository: joung2076-cyber1076/camphive-aeo
Custom domain: aicampingmarketing.co.kr (apex, A records)
First domain add: 2026-08-17 08:42 UTC
Second remove/re-add: 2026-08-19 07:43:42 UTC
(domain removed at 07:43:34 UTC, re-added at 07:43:42 UTC - 8 seconds apart)
Last checked: 2026-08-19 08:44:44 UTC

GET /repos/.../pages returns:

"https_certificate": {
"state": "new",
"description": "This domain was recently added. The certificate request
process will begin shortly.",
"domains": ["aicampingmarketing.co.kr"]
},
"https_enforced": false,
"build_type": "workflow"

GET /repos/.../pages/health reports no blocking condition on either the apex
or the www alt_domain:

is_https_eligible: true (both)
caa_error: null (both)
reason: null (both)
is_served_by_pages: true (both)
is_non_github_pages_ip_present: false (both)
is_proxied: false (both)
https_error: "peer_failed_verification" (both - a result, not a cause; the
edge still serves the *.github.io cert)
is_pointed_to_github_pages_ip: true (apex only; the www alt_domain is a
CNAME, so this is false there as expected)

Verified independently on our side (two public resolvers, 8.8.8.8 and 1.1.1.1):

• A records: 185.199.108/109/110/111.153 only. No stray A records, no AAAA.
• No CAA record at the apex, nor at co.kr or kr.
• No DNSSEC DS record at the apex.
• www CNAME -> joung2076-cyber1076.github.io
• /CNAME is served live and matches the configured domain.
• No other repository in this account has this domain configured.
• protected_domain_state: null, pending_domain_unverified_at: null
• The first re-add on 2026-08-17 was followed by a deployment 24 minutes later.
  The second attempt had 30 minutes of quiet before and 65 minutes after, with
  zero deployments in that window - and the state still did not move.

Note: https_certificate.domains lists only the apex, even though
www.aicampingmarketing.co.kr is a valid CNAME to the user domain and health
reports is_https_eligible: true for the alt_domain as well.

Could you please trigger certificate provisioning for this domain manually,
or tell us what is preventing the request from being queued?

[nirav-gajera]

Hi @joung2076-cyber1076
This matches a known, recurring pattern rather than anything wrong with your DNS — your diagnostic work here (both apex and www correctly checked, no CAA, no DNSSEC, no stray records, health endpoint clean) is genuinely thorough and rules out everything on your side. This is a provisioning job that never gets queued on GitHub's end, not a validation failure.

Two very close precedents worth referencing directly:

• Discussion Pages HTTPS certificate stuck in "new" for ~3 weeks (apex caviar.group), DNS verified correct #200447 (caviar.group, apex) — stuck at "new" for ~3 weeks, identical description text, DNS independently verified clean the same way you did.
• Discussion GitHub Pages HTTPS certificate provisioning stuck in “new” state #202318 (hhdhjsy.cn) — same symptom, same "new" state that never advances, same peer_failed_verification result on the edge.

One thing worth flagging from #200447's own findings: removing and re-adding the domain repeatedly can reset whatever internal timer/queue position exists, so doing it more than once tends to make the stall harder to reason about rather than fixing it — which lines up with what you saw: your second remove/re-add (8 seconds apart) didn't move the state at all, same as the first one didn't over a full day.
also check : #171081, #23184

Given that, I'd stop cycling remove/re-add at this point and leave the domain configuration stable exactly as it is now. This needs someone on the Pages team to look at why the request never entered the provisioning queue — that's not something DNS changes or further add/remove cycles can fix from your side. Open a ticket with GitHub Support(or reply in one of the linked discussions if a staff member is already tracking this pattern) and paste in exactly what you posted here — repo, domain, both API outputs, and the independent DNS verification. That's precisely the evidence needed to identify a stalled backend job rather than a config issue, and it's what got resolution in the similar threads above.