Pages HTTPS blocked after migration: public DNS points to GitHub, health check still sees Cloudflare

[vatsal18]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

My portfolio migrated to GitHub Pages on October 19, 2026. HTTP serves the new site, but HTTPS fails with NET::ERR_CERT_COMMON_NAME_INVALID, and Enforce HTTPS is unavailable. Could someone help identify why the Pages DNS check differs from public DNS, or whether GitHub staff can refresh validation and retry certificate provisioning?

Repository: https://github.com/vatsal18/early-human
Domain: hiremeifucan.com; alternate: www.hiremeifucan.com
Source: master branch, / (root)
Successful deployment: https://github.com/vatsal18/early-human/actions/runs/39259513123

Public DNS

Hostinger nameservers: horizon.dns-parking.com and orbit.dns-parking.com. Checks against both authoritative nameservers, 1.1.1.1, and Google public DNS return:

hiremeifucan.com A 185.199.108.153 TTL 300
hiremeifucan.com A 185.199.109.153 TTL 300
hiremeifucan.com A 185.199.110.153 TTL 300
hiremeifucan.com A 185.199.111.153 TTL 300
www.hiremeifucan.com CNAME vatsal18.github.io TTL 300

No apex AAAA or CAA records were found. The old hosting records pointed to 162.159.143.30 / 172.66.3.26 and custom-domains.chatgpt.site. Those routing records have been replaced, and both custom-domain attachments have been removed from the old host.

GitHub results

GET /repos/vatsal18/early-human/pages reports status=built, cname=hiremeifucan.com, https_enforced=false, and no https_certificate object.

After the health check completes, GET /repos/vatsal18/early-human/pages/health still reports for both names:

{
  "is_cloudflare_ip": true,
  "is_proxied": true,
  "is_pointed_to_github_pages_ip": false,
  "is_non_github_pages_ip_present": true,
  "is_https_eligible": false,
  "caa_error": null
}

HTTPS curl requests fail with SEC_E_WRONG_PRINCIPAL; HTTP returns the expected new portfolio with GitHub.com response headers. The missing certificate also blocks reliable social-preview fetching.

Already tried

• Compared authoritative and public DNS results.
• Removed and re-added the custom domain following GitHub documentation.
• Ran the support portal Pages SSL virtual assistant; it reported a missing valid certificate and recommended Enforce HTTPS, but that control is unavailable until issuance.

I understand DNS propagation may still be involved because the migration happened today. Is there a way to determine what DNS addresses the certificate service is actually resolving, and refresh a stale validation result if that is the issue? Any help getting HTTPS working promptly would be appreciated.

[DYNOSuprovo]

Root Cause Analysis

There are two distinct mechanisms causing this issue:

1. Cloudflare for SaaS (Custom Hostname) Edge Interception:
   The old hosting addresses you mentioned (162.159.143.30 / 172.66.3.26 via custom-domains.chatgpt.site) are Cloudflare for SaaS (SSL for SaaS) endpoint IPs.
   When a third-party platform registers a domain as a custom hostname, Cloudflare's edge routing takes precedence over public DNS across Cloudflare's Anycast network. If the previous host did not purge the domain via the Cloudflare API (DELETE /zones/:zone/custom_hostnames/:id), Cloudflare edge continues to route HTTPS requests to the old SaaS tenant. This explains why HTTPS curl fails with NET::ERR_CERT_COMMON_NAME_INVALID / SEC_E_WRONG_PRINCIPAL (the edge serves the old host's fallback certificate rather than Let's Encrypt).

2. GitHub Pages Health-Check Cache Invalidation:
   GitHub's /pages/health endpoint caches domain validation state for up to 24 hours. When you re-add the domain immediately without clearing the cached session, GitHub continues to see the stale is_cloudflare_ip: true flag from the initial migration window.

---

Step 1: Force a Hard Cache Purge in GitHub Pages

To force GitHub's backend to drop the cached health check:

1. Go to repository Settings → Pages.
2. Remove hiremeifucan.com completely and click Save.
3. Go to your local repository, open the CNAME file in the root / source branch, delete it (or commit without it), and trigger a fresh deployment so the site builds once as a raw vatsal18.github.io/early-human URL.
4. Wait 15–20 minutes for GitHub's internal edge and DNS health cache to expire the domain key.
5. In Settings → Pages, re-enter hiremeifucan.com and click Save.
   This forces GitHub Pages to initiate a brand new /health probe rather than reading from the cached validation bucket.

---

Step 2: Ensure IPv6 Parity on Hostinger

A live DNS check against horizon.dns-parking.com shows that www.hiremeifucan.com resolves both IPv4 and IPv6 (2606:50c0:8000::153), but the apex (hiremeifucan.com) only has IPv4 A records.

Let's Encrypt's dual-stack validation servers prefer IPv6 when available. Add the 4 GitHub Pages AAAA records to your Hostinger DNS for @:

• 2606:50c0:8000::153
• 2606:50c0:8001::153
• 2606:50c0:8002::153
• 2606:50c0:8003::153

---

Step 3: Resolving the Cloudflare for SaaS Orphan Lock (If HTTPS still fails)

If after Step 1 GitHub's health check still reports is_cloudflare_ip: true, Cloudflare edge is still hijacking the custom hostname from the old provider. You can break this orphan lock yourself:

1. Create a free account on Cloudflare and add hiremeifucan.com (you do not need to switch your nameservers permanently).
2. Because you control the domain, adding it to your own Cloudflare account claims zone ownership and immediately revokes any third-party Cloudflare for SaaS bindings across Cloudflare's global edge.
3. If you decide to keep Hostinger nameservers, you can contact the support of the old provider (chatgpt.site) and ask them to explicitly delete the custom hostname binding from their Cloudflare tenant.

Once the Cloudflare for SaaS edge lock is severed and GitHub's cache refreshed, the health check will toggle to is_pointed_to_github_pages_ip: true, and the Let's Encrypt certificate will be provisioned within 10–15 minutes.

---

If this explains the Cloudflare edge interception and helps get your HTTPS certificate issued, please consider marking this response as the accepted answer! 🚀

[vatsal18]

Thanks for taking a look. An update from a fresh check: both hostnames now report is_cloudflare_ip=false, is_proxied=false and is_https_eligible=true. The apex reports is_pointed_to_github_pages_ip=true, and www reports is_cname_to_github_user_domain=true. This changed before making any further DNS changes or adding IPv6.

A direct TLS connection to 185.199.108.153 with SNI hiremeifucan.com presents GitHub’s default CN=*.github.io certificate, so the certificate mismatch is reproducible directly at GitHub. The previous host’s two custom-domain attachments were already removed.

Now that validation passes, I have retriggered provisioning using GitHub’s documented remove-and-readd step and verified hiremeifucan.com is restored in Pages settings. Waiting for the domain-specific certificate before enabling Enforce HTTPS. I will update this discussion with the verified result.

[DYNOSuprovo]

Fantastic news @vatsal18! Glad to hear the domain re-add procedure kicked GitHub's certificate provisioning back into gear and that HTTPS is now fully verified and enforced across both hiremeifucan.com and www.

If the investigation and health check steps helped guide you through the stall, feel free to mark the response as the accepted answer so fellow developers experiencing migration cert delays can reference it. Congrats on getting the site live! 🎉

[vatsal18]

Resolved: GitHub’s health check eventually changed to is_https_eligible=true for both hostnames without further DNS changes. After that, removing and immediately re-adding the same custom domain restarted provisioning successfully. The Pages API now reports an approved certificate covering hiremeifucan.com and www.hiremeifucan.com, expiring 2027-01-17.

Enforce HTTPS is now enabled. Verified with certificate validation enabled: the HTTPS homepage and social-preview image return 200; HTTP and HTTPS www both redirect to https://hiremeifucan.com/.

No new Cloudflare account, nameserver migration, IPv6 addition, CNAME-file deletion, or extended domain-removal interval was needed. Thanks for helping investigate.

[ntruonghuynh]

hello how you can help me i need some questions