GitHub Pages custom domain HTTPS certificate not issued despite valid DNS

[k4hvecii]

🏷️ Discussion Type

Question

Body

Hello,
I need help troubleshooting a GitHub Pages custom domain SSL issue.
Repository: k4hvecii/k4hvecii.github.io
Default Pages URL: https://k4hvecii.github.io
Custom domain: k4hveci.info
The default GitHub Pages URL works correctly and the latest Pages deployments are successful.
DNS configuration:

• k4hveci.info A → 185.199.108.153
• k4hveci.info A → 185.199.109.153
• k4hveci.info A → 185.199.110.153
• k4hveci.info A → 185.199.111.153
• www.k4hveci.info CNAME → k4hvecii.github.io

The domain is also verified successfully under my GitHub account using the GitHub Pages TXT verification record.
I checked both authoritative nameservers and both return the correct four GitHub Pages A records.
In Repository Settings → Pages:

• the DNS check sometimes becomes DNS check successful
• after refreshing, it can return to DNS Check in Progress
• Enforce HTTPS remains disabled
• GitHub says a certificate has not yet been issued for k4hveci.info

GitHub’s own Pages SSL troubleshooting assistant also reports that the domain is not replying with a valid SSL certificate.
This has persisted for more than 24 hours. I already removed and re-added the custom domain once, re-verified the domain, and confirmed the DNS configuration.
Is there anything else I should check, or does this look like a stuck GitHub Pages DNS health check / certificate provisioning issue?
Thanks.

[Sagargupta16]

Your DNS is right, and the public API shows where it is stuck: no certificate request exists yet.

GET /repos/k4hvecii/k4hvecii.github.io/pages returns cname: k4hveci.info, protected_domain_state: verified, https_enforced: false, and no https_certificate object at all. Sites where GitHub has started provisioning carry that object with a state (new, authorization_created, authorized, issued, approved, or an error like bad_authz). Yours has not reached the first step. The gate before it is GitHub's own DNS health check, which is the "DNS Check in Progress" you see flapping.

From outside, everything answers. Both dns1 and dns2.hostingdunyam.net return the four A records, the www CNAME and your challenge TXT; no AAAA, no CAA; 60 of 60 queries (UDP, EDNS0, TCP) answered from my side. http://k4hveci.info already serves Server: GitHub.com, and crt.sh has never seen a certificate for the name, so this is not an expired or mis-issued certificate, it is one that was never requested.

One thing stands out: both nameserver names resolve to the same single IPv4 address (91.151.95.152) with no IPv6. GitHub's checker gives each lookup 5 seconds and two retries, and a single timeout flips the check back to "in progress". That matches the flapping you describe.

Run the check yourself (needs push access, so only you can):

gh api repos/k4hvecii/k4hvecii.github.io/pages/health --jq '.domain | {dns_resolves, caa_error, https_eligible, is_a_record, is_pointed_to_github_pages_ip}'
gh api repos/k4hvecii/k4hvecii.github.io/pages --jq .https_certificate

If dns_resolves is true on every run, wait: the request appears within an hour of a stable pass. If it alternates, or caa_error shows Dnsruby::ResolvTimeout, the pattern in this week's stuck-certificate threads was the authoritative DNS host; the domains that moved DNS hosting to Cloudflare (free plan, records set to DNS only) got certificates within a day, with one exception still waiting. Do not remove and re-add again unless you change DNS; each cycle restarts the check.

[k4hvecii]

Thanks. I checked both endpoints.

GET /repos/k4hvecii/k4hvecii.github.io/pages/health now returns 200 OK with:
dns_resolves: true
is_pointed_to_github_pages_ip: true
is_non_github_pages_ip_present: false
is_served_by_pages: true
is_valid: true
is_https_eligible: true
caa_error: null
responds_to_https: false
https_error: "peer_failed_verification"
I also checked GET /repos/k4hvecii/k4hvecii.github.io/pages.
It returns:
status: built
cname: k4hveci.info
protected_domain_state: verified
pending_domain_unverified_at: null
https_enforced: false

There is still no https_certificate object in the response.
So the DNS health check is succeeding now, but certificate provisioning still does not appear to have completed.
Would you recommend waiting for GitHub to create the certificate request, or moving authoritative DNS hosting at this point?