GitHub Pages custom domain TLS certificate stuck at 1 of 3 with successful DNS check

[itzaryan44]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Hello GitHub Community,

I am having an HTTPS/TLS certificate provisioning issue with my GitHub Pages custom domain.

GitHub account: itzaryan44
Repository: Aryanbuilds
Custom domain: www.aryanbuilds.qd.je

Current Pages status:

• DNS check: Successful
• TLS certificate: Certificate Request Error
• Certificate provisioning remains stuck at 1 of 3
• Enforce HTTPS: Unavailable

GitHub's Virtual Assistant also detected:
"www.aryanbuilds.qd.je isn’t replying with a valid SSL certificate (return code: bad_certificate)."

I have already:

• Confirmed www is a CNAME pointing to itzaryan44.github.io.
• Confirmed there are no AAAA records.
• Confirmed there are no CAA records.
• Removed and re-added the custom domain.
• Waited for certificate provisioning to retry.
• Confirmed the GitHub Actions deployment succeeds.
• Confirmed GitHub Pages reports DNS check successful.

The certificate request briefly changed to:
"Certificate Requested: Detected a change to DNS settings. Requesting a new certificate."

It then returned to:
"Certificate Request Error: Certificate provisioning will retry automatically in a short period, please be patient."

Could someone please advise what could be causing the certificate provisioning to fail despite the successful DNS check?

Thank you.

[PromptFed]

Did you delete unneeded DNS settings, Is the domain sharing any other DNS settings or maybe a subdomain that have unedited settings?

[Jyotir2004]

The likely issue is not your GitHub Actions deployment. A successful DNS check only means GitHub can see the expected DNS configuration; GitHub then has to obtain a TLS certificate from its certificate authority. GitHub documents that certificate provisioning is a separate step and can fail even after DNS validation succeeds.

For your specific setup, I would check these in this order:

Make sure www.aryanbuilds.qd.je has exactly one CNAME

Do not point it to the repository name or a *.pages.github.io address.

Check for hidden/indirect DNS records.
GitHub warns that additional A, AAAA, ALIAS, ANAME, or conflicting CNAME records can prevent certificate generation. You already checked AAAA and CAA, but also check whether your DNS provider has forwarding, proxying, wildcard records, or another record associated with www.
Check the domain's current HTTPS response.
The bad_certificate message suggests the certificate currently being presented for the hostname is not valid for the requested domain. If the DNS points correctly but an external DNS proxy/CDN or forwarding service is answering HTTPS requests, temporarily disable that and let the CNAME point directly to GitHub.
Remove and re-add the domain once more, then wait.
GitHub explicitly recommends removing and re-adding the custom domain to restart certificate provisioning. HTTPS availability can take up to an hour after configuration changes, and DNS changes themselves can take longer to propagate.
Check the domain length.
GitHub documents a certificate limitation requiring the complete Pages domain name to be under 64 characters. Your www.aryanbuilds.qd.je is well below that limit, so this particular restriction should not be the cause.
Most important point

Because your status is DNS check: Successful → Certificate Request Error → bad_certificate, I'd focus on what is actually answering HTTPS for www.aryanbuilds.qd.je, rather than changing your GitHub Actions workflow.

[krif014]

@itzaryan44 The important distinction here is that DNS validation and TLS certificate provisioning are separate steps. A successful DNS check confirms that GitHub can see the expected DNS configuration, but it doesn't by itself mean the certificate has been successfully issued.

Since you've already confirmed the CNAME, ruled out AAAA/CAA conflicts, removed and re-added the domain, and seen the status move from “Certificate Requested” back to “Certificate Request Error,” I wouldn't keep changing the GitHub Actions workflow. The deployment itself is unlikely to be the relevant part.

I'd focus on what is actually answering HTTPS for www.aryanbuilds.qd.je:

• Make sure the www hostname has the intended CNAME and no competing DNS record.
• Check for DNS forwarding, proxying, CDN configuration, or wildcard records at the DNS provider.
• Verify that the hostname resolves directly to GitHub Pages rather than another service.
• If all of that is clean, give the automatic retry some time rather than repeatedly removing/re-adding the domain.

GitHub's Pages documentation notes that certificate provisioning can take some time after the custom domain is configured, and recommends removing and re-adding the custom domain when HTTPS provisioning doesn't complete. Since you've already tried that, the useful next step is to gather the exact DNS and HTTPS response details and, if the error persists, report it to GitHub rather than repeatedly changing a configuration that already passes the DNS check.

The bad_certificate result is particularly useful evidence because it shows that the HTTPS certificate currently presented for the hostname isn't valid for that hostname. That makes the TLS/provisioning stage the part I'd investigate next.

[Dani-8]

@itzaryan44 Since you've verified the standard CNAME setup and cleared CAA/AAAA records, a "bad_certificate" error during GitHub Pages TLS provisioning almost always points to an issue during the Let's Encrypt ACME HTTP-01 challenge.

Here are the exact diagnostic steps to pinpoint the issue:

1. Verify ACME Challenge Path Routing
   • GitHub's certificate authority (Let's Encrypt) attempts to validate ownership by making an HTTP request to http://www.aryanbuilds.qd.je/.well-known/acme-challenge/.
   • If your DNS provider or domain Registrar (qd.je) forces an automatic HTTP-to-HTTPS redirect on the apex/subdomain or wraps the domain in an iframe/stealth forwarder, the ACME validator receives a invalid SSL cert (bad_certificate) or a 301/302 loop before it can complete.

2. Run a direct DNS/HTTP test (Terminal / Command Prompt)
   Run these commands to verify what is actually responding:

   dig www.aryanbuilds.qd.je CNAME
   curl -I -v http://www.aryanbuilds.qd.je/.well-known/acme-challenge/test

   • dig should output ONLY itzaryan44.github.io. as the CNAME target.
   • curl should return a response directly from GitHub's servers (look for headers like Server: GitHub.com), not your domain provider's parking page or proxy.

3. Fix for free/dynamic subdomain providers (.qd.je)
   • Some free subdomain providers automatically insert hidden A records or DNS parking proxies for root subdomains. Ensure any "URL Forwarding", "Web Redirect", or "DNS Proxy" features in your .qd.je control panel are explicitly set to Disabled or DNS-only.

4. Final Provisioning Step
   • Once you confirm curl routes cleanly to GitHub, go to Repository Settings → Pages.
   • Remove www.aryanbuilds.qd.je, save, wait 5 minutes, and re-enter www.aryanbuilds.qd.je.
   • Check the box for Enforce HTTPS once the green checkmark appears.