GitHub Pages HTTPS certificate stuck in "new" for 24h+ (leonida-news.de, apex works, www does not)

[xetrovt2000]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Pages

Body

What I'm trying to do: get the HTTPS certificate for my GitHub Pages custom domain issued so I can enable "Enforce HTTPS".

Setup

• Repository: xetrovt2000/gta6-infoboard, Pages from main / root, builds succeed
• Custom domain: leonida-news.de (plus www.leonida-news.de)
• DNS: apex A 185.199.108.153, AAAA 2606:50c0:8000::153; www is a CNAME to xetrovt2000.github.io. No CAA records. (My registrar only allows one A and one AAAA record for the apex.)

What happens

• GET /repos/xetrovt2000/gta6-infoboard/pages returns https_certificate.state: "new" for leonida-news.de and www.leonida-news.de.
• It has been in this state since 2026-10-01 ~07:18 UTC and was still unchanged on 2026-10-02 ~07:00 UTC (24h+).
• https://leonida-news.de works (older certificate covering only the apex), https://www.leonida-news.de shows a certificate error, and "Enforce HTTPS" cannot be enabled.

What I expected: the certificate to move to approved within an hour or so.

The documented workaround is removing and re-adding the custom domain, but last time that caused a cached 301 redirect for visitors, so I'd prefer a restart on GitHub's side. I've also opened a support ticket.

This looks like the same issue several others reported in the last few days, which may point to a wider provisioning problem:

• https://github.com/orgs/community/discussions/209093 (apex works, www does not)
• https://github.com/orgs/community/discussions/209002
• https://github.com/orgs/community/discussions/209098
• https://github.com/orgs/community/discussions/209317

Is anyone else seeing this, or has a remove/re-add fixed it for you?

[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. ⭐

[bosmdavid-gif]

Two things I can see from outside that may help narrow it down:

• The apex certificate isn't an old one. What GitHub serves for leonida-news.de right now was issued on 2026-10-01 at 05:30 UTC and covers only leonida-news.de, without www. So Pages completed an apex-only order about two hours before your state went to new at 07:18 UTC. The current new is a second order for apex + www, and that's the one stuck in the queue.
• DNS looks fine for that second order: www is a CNAME to xetrovt2000.github.io, the apex has 185.199.108.153 and 2606:50c0:8000::153, and there are no CAA records. A single A record is enough for validation, so your registrar's one-record limit isn't what's blocking it.

So I'd stick with your plan: don't remove and re-add (that restarts the order and risks the cached redirect again), let the support ticket run, and check gh api repos/xetrovt2000/gta6-infoboard/pages --jq .https_certificate.state every few hours. Several Pages certificate orders have been sitting in new since around 29–30 September, so it does look queue-side. Until it flips to approved, https://leonida-news.de (without www) is the link to share.

[xetrovt2000]

Update: resolved. I had also opened a support ticket, and GitHub Support manually re-triggered the certificate request ("gave our system a little nudge to reprocess the TLS certificate request"). The certificate for leonida-news.de + www.leonida-news.de is now approved, without removing or re-adding the domain. "Enforce HTTPS" is enabled and all four variants (http/https, with and without www) end up on https://leonida-news.de/.

For anyone with the same issue: a support ticket helped even on the Free plan (filed under Repositories → Repository features, since there's no Pages category). Also, after enabling "Enforce HTTPS", the HTTP→HTTPS redirect only took effect once I triggered a new Pages build.

@bosmdavid-gif thanks for the analysis, that was spot on: the second order (apex + www) was stuck in the queue.