Custom domain HTTPS certificate stuck in "new" for 24+ hours

[Misurugi]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Code Search and Navigation

Body

Custom domain: aikido-practika.ru
Repository: Misurugi/aikido-practika-site (previously Misurugi/aikido-practika)
Source: Deploy from branch, main / (root)

Problem
The HTTPS certificate for the custom domain has been stuck in state "new"
("The certificate request process will begin shortly", UI: "1 of 3") for more than
24 hours. Before that, Settings > Pages showed "DNS check unsuccessful / InvalidDNSError".
Enforce HTTPS is unavailable. The site works over plain http://aikido-practika.ru.

gh api repos/Misurugi/aikido-practika-site/pages returns:
"https_certificate": { "state": "new", "description": "This domain was recently
added. The certificate request process will begin shortly." },
"protected_domain_state": "unverified"

DNS (checked via Google and Cloudflare DoH; both ns1.reg.ru and ns2.reg.ru serve it)

• A @ -> 185.199.108.153, .109.153, .110.153, .111.153
• CNAME www -> misurugi.github.io.
• No AAAA, no CAA (for the apex and for ru.), no DNSSEC
• The apex has one unrelated TXT: _globalsign-domain-verification=...

Domain verification
I added TXT _github-pages-challenge-Misurugi.aikido-practika.ru =
a8f671bcc148efc3446ec37925eccf. The record is visible from both authoritative
servers and from public resolvers, but Verify at github.com/settings/pages still says
"We couldn't find the TXT record".

What I already tried (no change)

• Remove / re-add the custom domain in repo Settings > Pages (twice, a day apart)
• Deleted and re-created GitHub Pages for the repo via the API
• Moved the site to a new repository and re-attached the domain there
  (the old repo's Pages was disabled first, so the domain is not claimed twice)
• Checked the CNAME file: single line "aikido-practika.ru", uppercase filename

Question
Is there anything else that can block certificate provisioning / domain verification
for this domain, or a way to restart the request? GitHub Support closed my ticket as
self-service only, so I'm asking here.

Thanks!

[sknoyon324234234234]

I checked everything from outside just now, and your side really does look correct:

• A for the apex → all four 185.199.108–111.153, no AAAA, no CAA, no DS (no DNSSEC), NS = ns1/ns2.reg.ru
• www → CNAME misurugi.github.io., and http://www.… correctly 301s to the apex
• _github-pages-challenge-Misurugi.aikido-practika.ru TXT = a8f671bcc148efc3446ec37925eccf, resolving publicly
• http://aikido-practika.ru serves the site (200)

So there's nothing left to fix in DNS. A couple of things that might still help:

1. Stop removing and re-adding the domain. Every remove/re-add (and the repo move) throws away the pending request and starts a new one, and Let's Encrypt has per-domain rate limits on repeated/failed requests. Several resets in a day can keep pushing it back. Leave it attached to one repo, untouched, for 24–48h.
2. Verify the domain on the account first, then leave the repo alone. At github.com/settings/pages, "Verify" uses that exact TXT name. If it still says it can't find the record even though it resolves publicly, that's GitHub's verifier, and verification also locks the domain to your account, which helps the cert job.
3. Note the API currently lists only aikido-practika.ru in the certificate's domains, which is normal: www is covered once the apex cert is issued.

If it's still new after a quiet 48h with nothing touched, reopen the support ticket and paste the gh api …/pages output plus the DNS above. "Domain verification fails although the TXT record resolves publicly" is a concrete bug report, not a self-service question, so it's more likely to reach a human.

[KasraK2K]

Your configuration is fine. The blocker is on GitHub's side: the Pages DNS validator cannot get answers out of the reg.ru authoritative nameservers, so neither the DNS check, nor the TXT verification, nor the ACME order can ever succeed.

What I re-checked from outside (all clean)

Check	Result
aikido-practika.ru A	exactly the four GitHub IPs 185.199.108-111.153, no extra or parking records
AAAA / CAA / DS at apex	none - and no CAA on ru., no DS, so no stale DNSSEC in the parent zone
www.aikido-practika.ru	CNAME to misurugi.github.io. to the four Pages IPs
_github-pages-challenge-Misurugi.aikido-practika.ru	TXT a8f671bcc148efc3446ec37925eccf, resolving publicly
Token format	correct - the live challenge records for getbootstrap.com, rust-lang.org, vuejs.org and reactjs.org are all 30 hex characters too, so yours is not truncated
Repo	public, main / root, CNAME contains exactly aikido-practika.ru, github-pages deployment present
Nameservers	ns1.reg.ru / ns2.reg.ru - this is the actual cause

So there is nothing left to fix in your zone, and no CAA / DNSSEC / leftover-record explanation applies here.

Why it is stuck

GitHub's Pages checker (Ruby Dnsruby) queries your authoritative nameservers directly for A/AAAA/CAA/TXT instead of trusting a public recursive resolver. The reg.ru nameservers drop, rate-limit or SERVFAIL those UDP/EDNS queries coming from GitHub's ranges. That maps exactly onto your three symptoms:

• DNS check fails with InvalidDNSError ("Domain's DNS record could not be retrieved")
• the CAA lookup fails, so the ACME order is never submitted to Let's Encrypt - the certificate stays in state: "new" ("1 of 3") indefinitely and nothing ever shows up on crt.sh
• the TXT lookup fails, so Verify reports "We couldn't find the TXT record" and protected_domain_state stays unverified

This is not specific to your domain. Every recent report with these exact symptoms is on reg.ru nameservers:

• GitHub Pages InvalidDNSError despite correct DNS records – HTTPS unavailable #210149 - priyut-drakona.ru (REG.RU), essentially identical to your post
• Pages domain verification and HTTPS fail for a domain on reg.ru nameservers (TXT record is publicly resolvable) #210123 - tarkh.com, TXT resolves on 8.8.8.8 and 1.1.1.1, /pages/health returns 202 with an empty body forever and no https_certificate object is ever created
• GitHub Pages DNS check SERVFAIL for mustship.ru; HTTPS unavailable #210108 - mustship.ru, where the health API reports dns_resolves=false and caa_error: "Dnsruby::ServFail", which is the direct evidence of the failing authoritative query
• GitHub Pages: DNS check and domain verification fail for 13mirrors.ru #209249 (13mirrors.ru, failing since Sep 27), GitHub Pages TLS certificate stuck at "Certificate Requested" (step 1 of 3) for 17+ hours #208837 (b2china.ru), InvalidDNSError for chistov.space: DNS records are correct, REG.RU free plan #209534 (chistov.space)

For contrast, #210269 (peaksel.az) showed the same UI symptoms but sits on Cloudflare nameservers, and it cleared on its own.

This also explains why none of your attempts helped: removing and re-adding the domain, recreating Pages through the API and moving to a new repository all restart a check that cannot pass, and each reset only burns Let's Encrypt's failed-authorization rate limit. Waiting longer will not help either, because the check is failing structurally rather than slowly.

The fix that actually works

Keep the domain registered at reg.ru and move only the DNS hosting to a provider GitHub can reach (Cloudflare Free, deSEC, Bunny DNS, and so on). This is the accepted answer in #209534.

1. Add aikido-practika.ru to Cloudflare on the Free plan.
2. Recreate the records there:
   • A @ to 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153
   • CNAME www to misurugi.github.io
   • TXT _github-pages-challenge-Misurugi with the value shown under Settings > Pages > "Continue verifying" (enter the host without the domain suffix so the panel does not append the zone twice)
   • optionally AAAA 2606:50c0:8000::153 ... 8003::153
3. Set every record to DNS only (grey cloud). An orange-cloud proxy breaks issuance and later renewals.
4. At reg.ru, replace ns1.reg.ru / ns2.reg.ru with the two Cloudflare nameservers and wait roughly 15-30 minutes for the delegation to propagate.
5. Verify the domain at github.com/settings/pages first, then remove and re-add the custom domain in the repository settings once, and leave it alone. The certificate is normally issued within minutes to a couple of hours.

Two corrections to the earlier reply: a quiet 24-48 hours will not help here, and the certificate listing only the apex in domains is not expected - GitHub normally covers both the apex and www on the same certificate, so seeing only one is another sign the order never completed.

If you would rather not move nameservers, the remaining path is a support ticket, and the framing that gets past the self-service filter is the caa_error / Dnsruby::ServFail output from /repos/OWNER/REPO/pages/health plus links to the threads above. "GitHub's validator cannot resolve against reg.ru nameservers" is a concrete platform bug report rather than a configuration question.