Unsticking GitHub Pages: When Custom Domain HTTPS Provisioning Stalls

Deploying a static site with GitHub Pages is often a smooth experience, but what happens when your custom domain’s HTTPS certificate gets stubbornly stuck on the default *.github.io wildcard, even after meticulous DNS configuration? This common frustration highlights a critical point in maintaining engineering efficiency: understanding the underlying processes and knowing when to escalate.

The Case of the Stubborn Certificate

Community member lebamath encountered just such a challenge with their site, www.wirelesssharenotes.com. Initially, a DNS misconfiguration—extra A records injected by a domain registrar's forwarding feature—led to the incorrect certificate. This is a common pitfall, and fixing DNS is usually the first step.

Meticulous Troubleshooting Steps

lebamath diligently corrected the DNS, ensuring:

• Only the 4 official GitHub Pages A records and 4 AAAA records remained.
• No restrictive CAA records were present.
• The CNAME file content was precisely "www.wirelesssharenotes.com", free of whitespace.

Crucially, the GitHub Pages settings UI reported "DNS check successful." Despite this, "Enforce HTTPS" remained unavailable, stating, "Unavailable for your site because your domain is not properly configured to support HTTPS." Direct connections confirmed the issue: SNI requests for www.wirelesssharenotes.com still returned a certificate for CN=*.github.io.

Attempts to "Remove → wait → re-add → Save" the domain multiple times over several days yielded no change, far exceeding GitHub's documented provisioning window of "up to an hour."

Community Validation and Next Steps

Another community member, initial-d, validated lebamath's findings, confirming that the site's state was "past the normal DNS-misconfiguration phase." Their external checks showed:

www.wirelesssharenotes.com CNAME -> wirelesssharenotes.com.
wirelesssharenotes.com A -> 185.199.108.153 / .109 / .110 / .111
wirelesssharenotes.com AAAA -> 2606:50c0:8000::153 / ::8001::153 / ::8002::153 / ::8003::153
CAA -> no restrictive CAA record returned

HTTP requests were successfully reaching GitHub Pages:

HTTP/1.1 200 OK
Server: GitHub.com
X-GitHub-Request-Id: AB90:37E476:129D45:150042:6A90CA3D

However, HTTPS still failed on hostname validation:

SSL: no alternative certificate subject name matches target host name 'www.wirelesssharenotes.com'

initial-d wisely advised against further repeated domain removals/re-additions, as this "churn can make the timeline harder to debug." The typical GitHub Pages HTTPS provisioning flow involves a successful DNS check, followed by GitHub queuing a Let's Encrypt certificate request and then uploading it to their TLS termination layer.

When to Escalate: A Lesson in Engineering Efficiency

This scenario underscores that even with perfect user-side configuration and successful automated checks, underlying platform processes can sometimes stall. When a site remains in this "stuck" state well beyond documented provisioning times, the issue likely resides on GitHub's side, requiring them to manually requeue or repair the certificate issuance/binding for that specific hostname.

For optimal engineering efficiency, the recommended approach is to compile a detailed "support packet" with all verified information:

• Repository: lebamath/lebamath.github.io
• Custom domain: www.wirelesssharenotes.com
• Exact time (UTC) when DNS became clean.
• GitHub Pages UI status (DNS check successful, HTTPS unavailable).
• External evidence (HTTP 200, but SNI HTTPS failure).
• Confirmation of clean DNS (no extra A records, no restrictive CAA, correct CNAME file).

This comprehensive information empowers support teams to quickly diagnose and resolve the issue, minimizing downtime and frustration. It's a reminder that even in highly automated environments, persistent issues sometimes require human intervention and clear communication to get back on track.