Pages custom-domain certificate never issued — stuck in "new"/"authorization_created" for 56 days (pontonniersbex.ch)

[GeeRuoss]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Pages

Body

Repository: https://github.com/GeeRuoss/pontonniersbex (public, Pages legacy build from main, path /)
Custom domain: www.pontonniersbex.ch (alternate name: pontonniersbex.ch)

Problem

The Pages HTTPS certificate for this domain has never been issued. https_certificate.state has never progressed past new / authorization_created, across three attempts over 56 days. The edge still serves the default *.github.io certificate, so https:// shows ERR_CERT_COMMON_NAME_INVALID. GitHub's own /pages/health check is fully green for both names.

I opened support ticket #4697430, which was closed as out of scope for the free plan and redirected here.

Timeline (UTC)

• 2026-06-29 13:51 — CNAME added (pontonniersbex.ch). State went to authorization_created and stayed there for 53 days.
• 2026-08-21 10:06/10:15 — removed the custom domain (PUT /pages {"cname": null}), waited 9 minutes (edge served 404), re-added. State came straight back as authorization_created, never new — the existing record was resumed. No movement for 3h25.
• 2026-08-21 13:40 — changed the primary domain to www.pontonniersbex.ch. A genuinely new record was created: state new. No movement for 66 hours.
• 2026-08-24 08:29/09:06 — removed the domain for 36 minutes (certificate object went to null, edge served 404 throughout), re-added. State new again, still stuck.

Also tried, with no effect: repeated GET /pages/health, POST /pages/builds, re-saving the same cname, and a content push that rebuilt the site successfully.

Current state

GET /repos/GeeRuoss/pontonniersbex/pages:

{"status":"built","cname":"www.pontonniersbex.ch","build_type":"legacy","source":{"branch":"main","path":"/"},"public":true,"protected_domain_state":null,"https_certificate":{"state":"new","description":"This domain was recently added. The certificate request process will begin shortly.","domains":["www.pontonniersbex.ch","pontonniersbex.ch"]},"https_enforced":false}

GET /repos/GeeRuoss/pontonniersbex/pages/health — both domain (www) and alt_domain (apex): is_valid: true, is_served_by_pages: true, is_https_eligible: true, caa_error: null, is_proxied: false, reason: null, https_error: "peer_failed_verification".

DNS (Infomaniak, DNSSEC valid, unchanged since 2026-06-30)

• pontonniersbex.ch A → 185.199.108.153 / .109.153 / .110.153 / .111.153 (no AAAA, no other A)
• www.pontonniersbex.ch CNAME → geeruoss.github.io
• No CAA records, no proxy/CDN.
• http://www.pontonniersbex.ch/.well-known/acme-challenge/<test> returns a GitHub.com 404, so HTTP-01 would be reachable.

Why this looks like a stuck backend job, not a configuration issue

1. Certificate Transparency shows zero issuances ever for this domain (certspotter, include_subdomains) — no ACME order has ever reached Let's Encrypt. It is not a failing validation; the job never starts.
2. The 36-minute purge proves it is not a stale record: fully cleared and recreated from scratch, identical behavior.
3. Both records stall (apex at authorization_created, www at new) — pointing at the domain, not the repo.
4. Two other Pages sites on the same account have approved certificates (carron-deslarzes.ch, www.bikeverbier.ch), so the account pipeline works.
5. No relevant incident on githubstatus.com over the period.

Request

Could someone from the Pages team clear and re-trigger the certificate provisioning job for www.pontonniersbex.ch / pontonniersbex.ch? I will not touch the domain settings in the meantime. (Account-level domain verification is in progress — the _github-pages-challenge-GeeRuoss TXT record is already published.)

This is a volunteer sports club website (Club des Pontonniers de Bex, Switzerland); it currently works over HTTP only.

Thanks!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[ales27pm]

Another affected domain: 27pm.org / www.27pm.org, repository ales27pm/27pm.

GitHub Support ticket #4703929 was closed on August 27 and redirected to Community. The Pages certificate remains stuck at authorization_created; Pages reports the hosts valid, served by Pages and HTTPS-eligible, with no CAA error.

A clean custom-domain remove/re-add at 07:25 UTC and a successful Pages rebuild did not advance provisioning. At 08:46 UTC, GitHub was still serving the generic *.github.io certificate, causing peer_failed_verification.

DNS and the documented Pages records have been verified. We will now leave the DNS and custom-domain configuration unchanged. Could the Pages team inspect and restart the stalled certificate provisioning job?

[hidenori-tani]

A third affected domain: www.hidenoritani.com / hidenoritani.com, repository hidenori-tani/hidenori-tani.github.io (user site, public, GitHub Free).

The custom domain was added 2026-08-28 16:45 UTC. https_certificate.state has read new ever since — over 6 hours — with the description "This domain was recently added. The certificate request process will begin shortly." Enforce HTTPS stays greyed out, and the edge serves the generic *.github.io certificate, so HTTPS fails with peer_failed_verification.

/pages/health reports no problem for either host: dns_resolves true, is_served_by_pages true, is_valid true with reason null, is_https_eligible true, caa_error null.

Checked against the authoritative nameservers rather than a cached resolver: www is a CNAME to hidenori-tani.github.io., the apex has the four documented A records and the four AAAA records, there are no CAA records at either name (NOERROR, empty answer), no DS record, and the domain is not in the HSTS preload list. The CNAME file is 20 bytes, no BOM.

Two clean remove/re-adds (17:03 and 19:55 UTC) did not advance provisioning — the first moved the state from no certificate to new, the second left it at new. DNS and the custom-domain configuration are now untouched.

Details and the full health output: #206108

So that is pontonniersbex.ch (56 days), 27pm.org, and hidenoritani.com, plus #206017 and #206054 reporting the same symptom on 27 and 28 August. githubstatus.com shows GitHub Pages operational throughout. Could the Pages team look at the certificate provisioning queue?