GitHub Pages custom domain HTTPS stuck — apex cert not issued

[PYastreboff]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Pages

Body

Summary

Custom domain DNS has been correct for 12+ hours, but apex HTTPS never provisions. www already has a valid Let's Encrypt cert; apex still serves CN=*.github.io (hostname mismatch). Pages DNS check keeps failing with conflicting errors.

Repo / domain

• Repo: https://github.com/PYastreboff/AMC-Website
• Custom domain tried: australianmalechoir.com.au and www.australianmalechoir.com.au
• Publishing via GitHub Actions → github-pages environment

DNS (verified via dig @8.8.8.8 and both Crazy Domains NS)

Apex A records:

• 185.199.108.153
• 185.199.109.153
• 185.199.110.153
• 185.199.111.153

www:

• CNAME www.australianmalechoir.com.au → pyastreboff.github.io

No apex CNAME. No CAA records blocking Let's Encrypt. www is a CNAME (not an A record).

What works / what doesn't

• ✅ http://australianmalechoir.com.au/ serves the site (Server: GitHub.com)
• ✅ https://www.australianmalechoir.com.au/ has a valid cert for www.australianmalechoir.com.au and redirects to apex
• ❌ https://australianmalechoir.com.au/ fails TLS: cert is still CN=*.github.io (SAN mismatch)
• ❌ Pages DNS check fails overnight with:
  • NotServedByPagesError
  • later InvalidARecordError claiming www is an A record (dig shows CNAME only)

What I've already tried

1. Fixed typo domain (had accidentally used .com.au.au)
2. Set all 4 GitHub Pages A records + www CNAME
3. Waited overnight
4. Removed and re-added custom domain (apex and www)
5. Confirmed both Crazy Domains nameservers return the same correct records

Ask

Can someone from Pages help re-run DNS validation / force apex certificate issuance? Happy to provide dig output or screenshots.

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

[iheblaswd]

A few things I'd check, based on the details you posted (I can't see your DNS or repo, so these are suggestions, not confirmed causes):

1. AAAA records. Your dig output only covers A and CNAME. If the apex or www has an AAAA record pointing somewhere else (a leftover from registrar parking or forwarding), Let's Encrypt validation can reach the wrong server. Run dig AAAA australianmalechoir.com.au @8.8.8.8 and remove any AAAA record that isn't one of GitHub's Pages IPv6 addresses (2606:50c0:8000::153, 2606:50c0:8001::153, 2606:50c0:8002::153, 2606:50c0:8003::153).
2. 2. Forwarding or parking at the registrar. Some registrars add their own A records or a forwarding host when URL forwarding is enabled. Turn that off so the apex only has the four GitHub A records.
3. 3. The CNAME file in the deployed artifact. You deploy via Actions, so Pages reads the custom domain from the uploaded artifact. If the CNAME file isn't included in what you upload, the domain can be dropped or reset on deploy. Make sure the build output contains a file named CNAME containing only australianmalechoir.com.au.
4. 4. Keep Enforce HTTPS off until the apex certificate appears. Once DNS is correct, issuance can take a while. Check Settings → Pages for the status before turning it on.
      If none of these change anything, the exact error text and the AAAA dig output would be the most useful details to send to Pages support.

[PYastreboff]

Thank you!

I have tried all these things and still no luck! not sure where to go now.

[scolastico]

Yeah he is also obviously an ai bot, not a personal response. Check how he writes all his comments in the exact same pattern, all useless and ignoring basic facts like github's current known issue from the status page.

let tmp = new Set();
document.querySelectorAll('a[href="/iheblaswd"]').forEach(x => tmp.add(x.parentElement.parentElement.parentElement.parentElement.parentElement.children[0].children[0].children[0].href));
console.log(tmp);

Set(5) [ "https://github.com/orgs/community/discussions/212772", "https://github.com/orgs/community/discussions/212689", "https://github.com/orgs/community/discussions/212589", "https://github.com/orgs/community/discussions/212774", "https://github.com/orgs/community/discussions/212773" ]