GitHub Pages HTTPS Certificate Stuck? Community Finds Workarounds for Custom Domains

Many developers leveraging GitHub Pages for custom domains are encountering a significant roadblock: prolonged delays in HTTPS certificate issuance. This issue, where certificates remain stuck in a "new" or "authorization_created" state for days, severely impacts development productivity and site security. A recent GitHub Community discussion highlighted the frustration and shared potential workarounds.

The Persistent Problem: HTTPS Certificates Stuck in "New" State

The core of the issue revolves around GitHub Pages failing to provision HTTPS certificates for custom domains. Users report that while their sites serve correctly over HTTP, HTTPS connections present the generic *.github.io wildcard certificate, leading to browser errors like ERR_CERT_COMMON_NAME_INVALID. The "Enforce HTTPS" checkbox in repository settings remains greyed out, indicating the certificate isn't ready.

One user, hidenori-tani, detailed their experience with www.hidenoritani.com. Despite extensive troubleshooting, the API response for their site's certificate status consistently showed:

"https_certificate": {
  "state": "new",
  "description": "This domain was recently added. The certificate request process will begin shortly.",
  "domains": ["www.hidenoritani.com"]
}

This state persisted for over 56 hours, with no change in the description string.

Extensive Troubleshooting Yields No Internal Solution

The original poster performed a thorough check of their setup:

• DNS Configuration: Verified A records for the apex domain and CNAME for www pointing to GitHub Pages IPs.
• CAA Records: Confirmed no restrictions on certificate issuance.
• DNSSEC & HSTS: Checked for potential conflicts.
• GitHub Pages Health Check: The /pages/health API endpoint reported is_valid: true, is_served_by_pages: true, and is_https_eligible: true for both apex and www domains.
• Remedial Actions: Removed and re-added the custom domain multiple times, a documented troubleshooting step, which only reset the state to "new" again.

Crucially, several other community members reported identical symptoms, some for domains that had previously worked (renewal failures). GitHub Support tickets opened for this issue were closed and redirected back to the community discussions, despite githubstatus.com reporting GitHub Pages as "operational." This strongly suggests a systemic problem with GitHub's certificate provisioning queue, impacting overall git activity deployments.

Community-Driven Workarounds & External Solutions

Given the lack of a native resolution, the community proposed workarounds:

1. Cloudflare Flexible SSL

This method involves routing your site through Cloudflare to handle HTTPS externally. Key steps include:

• Cloudflare DNS: Configure CNAME (www) and A records (apex) to point to GitHub Pages, with Proxy Status set to "Proxied" (orange cloud).
• SSL/TLS Encryption Mode: Set to "Flexible" in Cloudflare. This secures traffic between users and Cloudflare, while Cloudflare communicates over HTTP with GitHub Pages, bypassing the stuck certificate.
• Redirection: Enable "Always Use HTTPS" in Cloudflare's Edge Certificates.
• GitHub Settings: Keep "Enforce HTTPS" disabled on GitHub Pages to prevent redirect loops.

2. Complete Validation Reset (Less Effective)

This involves temporarily disabling Cloudflare proxying, deleting the custom domain from GitHub Pages, waiting 15-30 minutes, and then re-adding it to trigger a fresh ACME challenge. However, this often resulted in the certificate getting stuck in the "new" state again.

The Author's Resolution: Moving Off GitHub Pages

After 56 hours with no progress, the original poster moved their site from GitHub Pages to Netlify. A certificate was issued within 7 minutes of the DNS change. Further investigation revealed that other "resolved" cases in the discussion also involved moving off GitHub Pages to services like Vercel or Cloudflare Pages. No instances were found where GitHub itself eventually issued the certificate after being stuck.

This experience underscores a critical gap in GitHub Pages' reliability for custom domain HTTPS. While GitHub Pages remains a popular choice for static sites, developers needing immediate and reliable HTTPS for custom domains may need to consider external CDNs or alternative hosting platforms to ensure consistent development productivity and secure deployments.