GitHub Pages: DNS check successful, but HTTPS certificate is not provisioned after 36+ hours

[nadezgda-narabote]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Hello!

I'm experiencing an HTTPS certificate provisioning issue with my GitHub Pages website.

Repository: https://github.com/nadezgda-narabote/volgina-tutor

Custom domain: nadezhdavolgina.ru

Alternate domain: [www.nadezhdavolgina.ru](http://www.nadezhdavolgina.ru)

What I expected

GitHub Pages should automatically provision an SSL/TLS certificate for my custom domain and allow me to enable "Enforce HTTPS".

What happened instead

• GitHub Pages reports "DNS check successful".
• The website loads correctly over HTTP.
• "Enforce HTTPS" remains disabled with the message that the domain is not properly configured to support HTTPS.
• Both HTTPS addresses return a certificate name mismatch.
• The server presents a generic *.github.io certificate that does not include my custom domain.

The problem persisted for more than 36 hours. I also removed and re-added the custom domain, but this did not resolve it.

Diagnostics already performed

• The latest GitHub Pages deployment completed successfully.
• The repository contains the correct CNAME file.
• The apex domain resolves to all four official GitHub Pages IPv4 addresses.
• The www CNAME points to nadezgda-narabote.github.io.
• The authoritative DNS servers are configured correctly.
• No conflicting AAAA records, wildcard records, or restrictive CAA records were found.
• No certificate for my domain was found in the checked public certificate transparency logs.

The public DNS configuration appears correct, but the domain-specific certificate has not been provisioned.

My question

Is there a way to inspect the certificate provisioning status or trigger certificate issuance again without repeatedly changing DNS or removing the custom domain?

If this requires intervention from GitHub, how can a GitHub Free user get this specific provisioning issue investigated?

I would appreciate any guidance. Thank you!

[Dani-8]

@nadezgda-narabote High-quality diagnostic write-up! Since your DNS records pass check (DNS check successful) and resolve correctly to GitHub IPs, your issue is caused by a stalled ACME challenge state on GitHub's background certificate queue.

Here is how you can force a fresh certificate issuance cycle and how to get GitHub support to resolve it:

---

1. How to Force Trigger Certificate Issuance (Without DNS Changes)

Deleting and re-adding the custom domain normally refreshes the CNAME file in your repository, but it doesn't always clear stale state in GitHub's Let's Encrypt provisioning pipeline.

Try this targeted cycle:

1. In your repository Settings → Pages:
   • Clear the Custom domain input field entirely and click Save.
   • Wait 10 to 15 minutes (this gives GitHub's edge routers time to purge the cached routing table and release the .github.io fallback cert mapping).
2. Go to your local repository directory, commit, and push a change:
   • Ensure the root CNAME file is removed if it still exists.
3. Return to Settings → Pages:
   • Re-enter nadezhdavolgina.ru into the Custom domain field and click Save.
   • Observe the status box. It should say "DNS check successful. Requesting certificate..." or "Certificate processing...".
   • Crucial step: Leave the tab open or check back in 15–30 minutes without re-saving or toggling options. Repeatedly clearing/re-adding domain inputs before an ACME HTTP-01 challenge completes causes Let's Encrypt rate-limit backoffs.

---

2. Check for Hidden DNS / CAA Restrictions

Even if standard CAA checks pass, confirm that your .ru DNS zone registrar (e.g., Reg.ru, RU-CENTER) does not have a CAA record configured that excludes Let's Encrypt (letsencrypt.org). GitHub Pages relies exclusively on Let's Encrypt to issue custom domain SSL certificates. If a CAA record exists that only permits other Certificate Authorities, Let's Encrypt will silently fail during validation.

---

3. How GitHub Free Users Can Get Support for Pages Provisioning

While GitHub Free accounts do not have access to 1-on-1 private ticket support for general repository or code questions, Pages TLS/SSL Certificate Provisioning is an automated service infrastructure issue.

GitHub Support does accept support tickets for account/infrastructure faults (like stuck Pages TLS provisioning):

1. Go to support.github.com while logged in.
2. Select Pages & Custom Domains (or Account & Sign-in -> Pages).
3. Type Custom domain HTTPS certificate not provisioning into the Virtual Assistant prompt.
4. When prompted whether the docs answered your question, select Contact Support / Create Support Ticket.
5. Title the ticket: Stuck TLS Certificate Provisioning for Pages: nadezhdavolgina.ru.
6. Include your diagnostic summary:

   *"DNS check passes, A and CNAME records point directly to GitHub Pages, but the ACME challenge job is stuck presenting the fallback .github.io certificate for over 36 hours. Please reset the Let's Encrypt provisioning queue for repo nadezgda-narabote/volgina-tutor."

GitHub Staff can manually clear the stuck provisioning lock or trigger an immediate re-issuance job on their background worker queue.

[nadezgda-narabote]

Thank you for the detailed reply!

I've already removed and re-added the custom domain once, but the certificate was still not issued.

The DNS and CAA records have also been checked, with no conflicting records found.

Before I remove the domain again and manually delete the CNAME file, could you clarify whether this specific procedure is documented by GitHub or has resolved the same issue in a confirmed case?

Also, do you have a verified support route for GitHub Free users to report stuck Pages certificate provisioning? The standard support options currently available to my account are limited.

I'd prefer to avoid further changes that could temporarily disconnect the domain without evidence that they will resolve the problem.

Thank you!

[Dani-8]

@nadezgda-narabote Valid concerns about wanting to avoid unnecessary domain downtime! good for u.

1. removing the domain resets the cycle: While GitHub's official docs focus on the standard setup UI, clearing the domain and waiting purges the cached configuration in GitHub's routing layer. This is a common community workaround for when the ACME challenge gets stuck serving the fallback *.github.io wildcard certificate instead of requesting a new one from Let's Encrypt.

2. How to contact support on GitHub Free: GitHub Pages certificate provisioning is an infrastructure service, so you can open a ticket even on a Free plan.

   • Go to https://support.github.com while logged in.
   • Choose GitHub Pages under the topic options.
   • If the automated assistant tries to direct you to community discussions, click "I still need help" or "Contact Support" to open a direct ticket.
   • Provide your repository link and domain details so GitHub staff can manually trigger the certificate job on their backend queue.

If you prefer not to touch the DNS or domain settings right now, opening the support ticket is your safest option so staff can clear the backend lock directly.
Best of luck! Hope this works out and gets your site secured soon.

[nadezgda-narabote]

An update: I followed the suggested procedure today. I removed the custom domain at 09:02 and added it back at 09:20, leaving an 18-minute gap.

The domain is now verified at the account level, the DNS check is successful, and the DNS and CAA records have already been checked.

However, HTTPS is still unavailable, and the server continues to present the fallback *.github.io certificate. Before this attempt, I had already waited more than 36 hours.

Could a GitHub staff member please investigate the certificate provisioning status for nadezhdavolgina.ru? Repeating the DNS and domain configuration steps has not resolved the issue.

[krif014]

@nadezgda-narabote At this point, it sounds like you've already gone through the documented troubleshooting rather than simply having a DNS configuration problem.

GitHub's documentation says that after a successful DNS check, Pages queues a TLS certificate request with Let's Encrypt, and that removing and re-adding the custom domain can restart the provisioning process. It also says HTTPS can take up to an hour in normal circumstances.

Since you've already tried that once, waited well beyond the documented timeframe, and confirmed the DNS/CAA configuration, I wouldn't keep removing and re-adding the domain or changing DNS just to retry the same process. At this point, the useful next step is for GitHub to investigate why the certificate hasn't been issued.

One important correction from the earlier replies: GitHub's current support documentation says GitHub Free users generally use Community Discussions for most product issues; direct support tickets are available for paid plans, while Free users can still contact Support for account, security, and abuse issues.

So I'd keep the discussion focused on the evidence you've already collected: successful DNS check, correct Pages records, successful deployment, verified domain, and HTTPS still unavailable after substantially more than the normal provisioning period. Hopefully a GitHub staff member can determine whether there's anything specific about the domain or Pages configuration that isn't visible from the public checks.

[Dani-8]

@nadezgda-narabote @krif014 Good callout regarding the support ticket policies for Free tier accounts!

Given that manual domain re-adds and waiting periods haven't cleared the ACME queue, there is no need to disconnect the domain again.

Since GitHub staff periodically review unanswered infrastructure issues in Community Discussions, here is the exact diagnostic summary you can keep bumped in this thread so a staff member can clear the backend lock:

• Repository: nadezgda-narabote/volgina-tutor
• Custom Domain: nadezhdavolgina.ru / www.nadezhdavolgina.ru
• DNS Status: Verified & passing A / CNAME checks
• Issue: Stalled ACME challenge job continuously serving *.github.io fallback certificate (>36 hours).

Hopefully a GitHub staff member tags in shortly to manually re-trigger the Let's Encrypt issuance worker for your repository!