🗒️ Pages Mini Check-in - February

[mecodeatlas]

Alt Text: This banner image shows a moonscape scene with two Octocats standing on the moon posing with the earth in the background. It includes the text "Pages Check-in" in the upper left corner.

🔐 Pages, DNS & the Hidden Layers of HTTPS | Pages Mini Check-in – February

Several discussions this month exposed a recurring pattern in Pages: DNS configured correctly on paper, but misaligned in practice.

Ownership locks, record conflicts, and certificate provisioning timing were the most common blockers.

Here’s a breakdown of what the community uncovered.

👉 Missed January’s check-in? Catch up here!

🛠️ Pros in Pages: Highlights from the community

Two custom domain cases stood out this month.

• Custom domain issue when recreating repo - After recreating a repository, @stark0de hit the “domain already taken” wall. The root cause was domain locking tied to the previous repo. @gebz123 broke down how to fully release the domain, complete TXT verification, and safely attach it to the new project.
• Custom domain HTTPS not available on GitHub Pages even after DNS check successful - DNS looked correct for @piyushahuja7623, but HTTPS refused to enable. The issue was not propagation. @Maulik176 identified conflicting records and configuration mismatches, then outlined how to clean up DNS and retrigger certificate provisioning.

Small DNS misalignments. Clear technical fixes. Strong community debugging.

🤝 Discussions that could use your help

There is an open thread where additional expertise could help clarify certificate edge cases.

• Github Pages custom name.com domain serving invalid certificate
  The user reports successful DNS checks and HTTPS enforcement, yet the domain serves a SEC_ERROR_UNKNOWN_ISSUER. If you have experience with registrar configurations, certificate validation, or domain transitions, your input could help move this forward.

📣 What’s happening around the Community

• Help Us Improve GitHub Community Discussion Categories 🫶 - We are exploring a refresh of the Community’s discussion category structure. If you have ever hesitated when choosing a category, this is your opportunity to help shape the future structure.
• 💘 Code & Commit: what are you saying “yes” to in 2026? - A space to share your learning goals and project commitments for the year.
• 💘 It’s Valentine’s Day - Who’s Your Code Crush? - A lighthearted thread to recognize someone in the Community who has made an impact.

Custom domains, DNS records, and HTTPS provisioning continue to be some of the most nuanced parts of running a Pages site.

What has been the most unexpected DNS or HTTPS issue you have faced recently?

[itxashancode]

I’d start by checking name.com’s DNS dashboard for any registrar-level SSL or proxy toggles. I ran into this exact SEC_ERROR_UNKNOWN_ISSUER error when a registrar’s Auto SSL feature intercepted the request and served its own placeholder cert instead of passing traffic to GitHub’s Let’s Encrypt chain.

Turn off any SSL, CDN, or proxy features in name.com. Make sure you only have the standard A records pointing to 185.199.108.153 through 185.199.111.153, or a CNAME for www pointing to username.github.io. Then go to your repository Settings, Pages section, delete the custom domain, wait ten minutes, and add it back. That forces GitHub to drop the stuck certificate and request a fresh one.

You can verify the chain locally:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | grep -i issuer

If it still shows a non-Let’s Encrypt issuer, name.com is likely still intercepting. Are you routing an apex domain or a subdomain through their dashboard?