HTTPS certificate for one custom domain stuck in "new" for over a week; a different name on the same repo works in seconds

[jeroenjanssens]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Code Search and Navigation

Body

The HTTPS certificate for the custom domain rush.jeroenjanssens.com on my project site jeroenjanssens/rush has been stuck since 2026-10-28. The Pages API keeps showing:

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

It never gets past new, and certificate transparency logs show that no certificate has ever been issued for this name.

The same setup works with other names. On 2026-11-02 I set rush-test.jeroenjanssens.com on the same repo and Pages site. It went new → authorization_pending → approved in 27 seconds. My other project sites (flash, kana, quarto-term, raylibr, …) use exactly the same setup, and all of them got certificates within minutes. So the problem seems tied to the name rush.jeroenjanssens.com itself.

Setup (identical to the sites that work):

• DNS: CNAME rush.jeroenjanssens.com → jeroenjanssens.github.io, DNS-only (not proxied) on Cloudflare. The Pages DNS check passes.
• CAA: allows letsencrypt.org.
• Deployed with GitHub Actions (actions/deploy-pages) from main. Plain HTTP works fine.

What I've tried:

• Removed and re-added the custom domain many times, with gaps from a few seconds to a few minutes, and waited up to several hours each time.
• Deleted and re-created the DNS record.
• Switched from a gh-pages branch deploy to GitHub Actions, and deleted the gh-pages branch.
• Deleted the Pages site entirely and re-created it, twice (2026-11-01 and 2026-11-04), followed by a fresh deploy and setting the domain again. It stayed in new both times.

My guess is that a stale certificate request is stuck on GitHub's side, left over from the many add/remove cycles in the first days. It survives even deleting and re-creating the Pages site.

Questions:

1. Has anyone seen this and found a way to clear it themselves?
2. Could someone at GitHub clear the certificate state for rush.jeroenjanssens.com? I opened a support ticket, but it was closed with a referral to this forum.

The domain is currently set and I'm leaving it unchanged, so the stuck state can be inspected.

Thanks!

[azlanabdulla]

Hi @jeroenjanssens,

You've already done the usual things (DNS-only CNAME, CAA, remove and re-add, recreating the site), and the fact that rush-test.jeroenjanssens.com got a certificate in 27 seconds on the same repo points to something tied to that one hostname. I haven't seen a way for a user to clear it themselves. A few things I'd still check before waiting on GitHub:

1. Run the health endpoint and look at every field, not just the DNS check:
   gh api repos/jeroenjanssens/rush/pages/health
   Look at caa_error, is_https_eligible, is_non_github_pages_ip_present and is_proxied for rush.jeroenjanssens.com.

2. Check for a CAA record on the exact name rush.jeroenjanssens.com. A CAA record on a subdomain overrides the parent domain's, so one stray record there could block issuance even though the parent allows letsencrypt.org. It would be worth checking for stale A, AAAA or CNAME records on that name too, and whether DNSSEC is enabled and valid.

3. Check whether that hostname is still claimed elsewhere, for example by another repo, organization or an old CNAME file, or by a verified-domain entry under another account. A leftover claim could produce this kind of stuck state.

4. Please keep the domain set and unchanged, as you're doing. More add/remove cycles don't seem to help, and the earlier ones may be part of what got it stuck.

This looks like several other recent "stuck in new" threads where nothing on the user's side fixed it, and staff had to restart issuance, e.g. #206108, #205333, #202318 and #205765. It's likely to need someone on the Pages team.

When you reply on your closed support ticket, it may help to include:

• the repo and hostname: jeroenjanssens/rush and rush.jeroenjanssens.com
• the date it got stuck (2026-10-28) and the dates of the two site recreations (2026-11-01 and 2026-11-04)
• the output of the /pages and /pages/health calls
• that rush-test.jeroenjanssens.com on the same repo went new -> authorization_pending -> approved in 27 seconds
• a request to escalate to the Pages engineering team

If you need HTTPS working in the meantime, you could serve the site under another hostname that issues fine, such as rush-test, or put it behind Cloudflare's proxy with SSL mode set to Full. The proxy route needs care, so check that your redirects and "Enforce HTTPS" still behave as expected.

Hopefully someone from GitHub can inspect the stuck request. Good luck!

[jeroenjanssens]

Hi @azlanabdulla,

Thanks a lot for the detailed help, this was really useful!

I went through everything you suggested. The /pages/health check is clean (is_https_eligible: true, caa_error: null, is_proxied: false, is_non_github_pages_ip_present: false). There's no CAA record on rush.jeroenjanssens.com itself, no stale A, AAAA or CNAME records, DNSSEC isn't enabled, and no other Pages site of mine claims the hostname. So, as you expected, nothing seems to be wrong on my side.

I've reopened my support ticket with the details you listed: the timeline, the /pages and /pages/health output, the rush-test comparison, and a request to escalate to the Pages engineering team. I'll keep the domain unchanged in the meantime and will post an update here once it's resolved, in case it helps others with the same problem.

Thanks again!

[azlanabdulla]

Hi @jeroenjanssens,

Glad it helped, and thanks for going through every check and reporting back. Your results rule out the usual DNS, CAA, DNSSEC and hostname-claim causes, so escalating to the Pages team is the right next step. Reopening the ticket with the full timeline and the rush-test comparison should give them what they need.

Keeping the domain unchanged is a good call. Adding and removing it again could disturb whatever state the stuck request is in.

Please do post an update when it's resolved, since it'll help others who hit the same "new" state.

If the checks and escalation steps above were useful to you, please mark my reply as the answer so others with the same problem can find it more easily.

Good luck!