GitHub Pages custom domain TLS certificate stuck with Certificate Request Error

[munsu1726-arch]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Repository: munsu1726-arch/mirjin-info

Custom domain: mir1jin.kro.kr

I'm using GitHub Pages with a custom subdomain.

Current status:

• GitHub Pages deploys successfully.
• DNS check shows "DNS check successful".
• The CNAME file contains only mir1jin.kro.kr.
• DNS has only one CNAME record:
  mir1jin.kro.kr -> munsu1726-arch.github.io
• There are no A, AAAA or www records.
• HTTP works correctly.
• HTTPS serves the default *.github.io certificate.
• Pages has shown "Certificate Request Error" for several days.
• Enforce HTTPS cannot be enabled.

I have already:

• Removed and re-added the custom domain.
• Waited more than 24 hours.
• Confirmed there are no conflicting DNS records.

Can anyone help identify why GitHub Pages is unable to provision the TLS certificate for this domain?

[KrrishSR4]

Based on the information you've provided, I don't think the issue is caused by the visible DNS configuration anymore because GitHub Pages already reports "DNS check successful".

The combination of:

• GitHub Pages deploying successfully
• DNS validation passing
• HTTP working correctly
• HTTPS still serving the default *.github.io certificate
• Continuous "Certificate Request Error" status for several days

suggests that the ACME/Let's Encrypt certificate provisioning process may be failing after domain validation rather than due to a standard DNS misconfiguration.

A few things I would verify:

1. Ensure the CNAME record is truly DNS-only and not being proxied by a CDN such as Cloudflare.
2. Check for any hidden or automatically generated A/AAAA records at the DNS provider.
3. Verify that the domain is not currently attached to another GitHub Pages repository or GitHub account.
4. Remove the custom domain, wait a few minutes, trigger a fresh Pages deployment, and then re-add the domain.
5. Confirm that DNSSEC (if enabled) is healthy and not causing Let's Encrypt validation failures.

The most interesting clue is that:

• DNS validation succeeds.
• HTTP access works.
• GitHub Pages recognizes the custom domain.
• HTTPS never receives a certificate and remains stuck at "Certificate Request Error".

At that point, the problem is often no longer with the public DNS records themselves but with the certificate issuance workflow. Since you've already waited several days and reconfigured the domain multiple times, this may require investigation from GitHub Pages support or staff.

Could you share the output of the following commands?

dig mir1jin.kro.kr CNAME
dig mir1jin.kro.kr A
dig mir1jin.kro.kr AAAA
dig mir1jin.kro.kr CAA

The CAA lookup is particularly important because an unexpected CAA record can prevent Let's Encrypt from issuing a certificate even when DNS validation succeeds.

If the dig output looks correct, I would strongly suspect a GitHub-side certificate provisioning issue rather than a repository or DNS configuration problem.

If this helps identify the root cause or resolves the issue, please consider marking the answer as accepted so other users facing the same problem can find the solution more easily.

[Mr-Nilarnab]

One additional thing that may help isolate the issue is checking whether the domain is consistently reachable from multiple DNS resolvers.

For example, compare the results from Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), and your authoritative nameservers. If different resolvers return different answers, GitHub's certificate provisioning service may still be seeing stale DNS data even though the Pages UI reports "DNS check successful."

I'd also verify:

• Whether the domain or any parent domain publishes CAA records. Even if mir1jin.kro.kr has none, a restrictive CAA record at kro.kr or another parent level can affect certificate issuance.
• Whether the domain has both IPv4 and IPv6 consistency. An unexpected AAAA record pointing elsewhere can sometimes cause ACME validation to fail depending on the validation path.
• Whether curl -I http://mir1jin.kro.kr and curl -I https://mir1jin.kro.kr consistently return GitHub Pages responses from different networks (mobile data vs. home network), helping rule out resolver-specific caching.

Given that:

• Pages deployment succeeds,
• DNS verification passes,
• HTTP serves the site,
• but HTTPS remains stuck in Certificate Request Error for several days,

the remaining possibilities are becoming quite narrow: either an external DNS condition that only affects certificate validation (CAA, inconsistent DNS propagation, IPv6 mismatch) or an issue in GitHub Pages' certificate provisioning pipeline. The output of dig +trace mir1jin.kro.kr would also be useful because it verifies the complete delegation chain rather than just the final DNS response.

[SreeDharshan-GJ]

Since your DNS check is successful, your DNS configuration is probably not the problem.

A few things I'd verify:

Check the CAA records for kro.kr (or your specific subdomain). GitHub Pages uses Let's Encrypt to issue certificates. If a restrictive CAA record exists that doesn't allow letsencrypt.org, certificate issuance can fail.

Verify the CNAME resolves correctly: dig mir1jin.kro.kr CNAME

It should resolve only to: munsu1726-arch.github.io.

Also confirm there are no hidden A/AAAA records or DNSSEC issues.
Wait for DNS propagation if you've recently changed DNS providers or records. Although GitHub says 24 hours, DNS caches can occasionally take longer.

Since you've already:
Removed and re-added the custom domain,
confirmed the CNAME file,
verified the DNS check succeeds,
waited several days,

this may be an issue with the GitHub Pages certificate provisioning service rather than your configuration.

If the certificate continues to show "Certificate Request Error" after several days with a successful DNS check, I'd recommend opening a GitHub Support ticket. Include:

Repository: munsu1726-arch/mirjin-info
Custom domain: mir1jin.kro.kr
The fact that DNS verification succeeds but Let's Encrypt provisioning has remained in the Certificate Request Error state for multiple days.

That should allow the GitHub Pages team to inspect the certificate provisioning logs, which aren't visible to the community.