GitHub Pages custom domain TLS certificate stuck at "Authorization created"

[jackyshenfenghua]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

I am seeing what appears to be another instance of the recent GitHub Pages custom-domain TLS provisioning issue.

Repository and domain

Repository: jackyshenfenghua/fenghuashen.com

Custom domain: fenghuashen.com

The site is deployed successfully and works over HTTP, but GitHub Pages has not issued a TLS certificate for the custom domain.

Pages Settings remains at:

• DNS Check in Progress
• 1 of 3 — Certificate Requested: Authorization created
• Enforce HTTPS is unavailable

The Pages API reports:

status: built
cname: fenghuashen.com
protected_domain_state: verified
https_certificate.state: authorization_created
https_certificate.description: Authorization created
https_certificate.domains:
  - fenghuashen.com
  - www.fenghuashen.com
https_enforced: false

DNS and domain checks

I have verified the public DNS configuration:

• fenghuashen.com resolves to all four current GitHub Pages IPv4 addresses:
  • 185.199.108.153
  • 185.199.109.153
  • 185.199.110.153
  • 185.199.111.153
• www.fenghuashen.com is a CNAME to jackyshenfenghua.github.io
• No AAAA record is present
• No CAA record is present
• No DS record was found
• The repository CNAME contains exactly fenghuashen.com
• GitHub account-level domain verification has completed successfully and the domain is shown as Verified

HTTP requests to the apex domain return 200 OK from GitHub Pages, and www redirects to the apex domain over HTTP.

HTTPS currently presents GitHub's default *.github.io certificate, which does not contain fenghuashen.com, resulting in a hostname mismatch.

Troubleshooting already performed

I have already:

1. Verified the DNS records publicly.
2. Completed GitHub account-level domain verification.
3. Removed and re-added the custom domain once, following the GitHub Pages HTTPS troubleshooting guidance.
4. Left the DNS and Pages configuration unchanged since that retry.

Removing and re-adding restarted provisioning, but it became stuck again at authorization_created.

I also ran GitHub Support's "Troubleshoot Pages SSL issues" assistant, which confirmed that the domain is not currently presenting a valid SSL certificate.

Similar recent reports

Before posting, I searched the Community and found several recent reports describing very similar behavior, including domains stuck at new, authorization_created, or continuing to receive the default *.github.io certificate despite apparently valid DNS.

In particular, discussion #206108 documents multiple affected domains and includes cases stuck at authorization_created.

My domain appears to be another independent data point with the same general provisioning symptom.

Question

Is there anything else that can be corrected on my side, or does https_certificate.state: authorization_created indicate that certificate provisioning is now waiting on GitHub Pages infrastructure?

If someone from the Pages team is able to inspect the certificate provisioning state or queue for fenghuashen.com, that would be greatly appreciated.

For now I am leaving the DNS records and custom-domain configuration unchanged so that I do not restart the provisioning process again.

Thank you.

[SaadShyhan]

authorization_created means the ACME order exists but the HTTP-01 challenge has not validated yet — so the block is at the validation step, not at your DNS, which from everything you listed looks correct.

One thing worth testing before waiting any longer: the certificate covers both fenghuashen.com and www.fenghuashen.com, and both names must answer the challenge over plain HTTP for the order to complete. A redirect on either name stalls the whole order.

curl -sSI http://fenghuashen.com/.well-known/acme-challenge/test
curl -sSI http://www.fenghuashen.com/.well-known/acme-challenge/test

You want a plain 404 served by GitHub Pages on both — not a 301/308 to HTTPS, and not a redirect between apex and www. You mentioned www redirects to the apex over HTTP; if that redirect also applies to the .well-known/acme-challenge/ path, the www authorization can never complete, and because www is on the same order the apex certificate never issues either.

Also worth ruling out: no proxy in front (a Cloudflare orange-cloud record would intercept the challenge), and no stray CAA record at the apex — you have already confirmed the CAA part.

If both curls return 404 from Pages, there is genuinely nothing left on your side and it is queue-side. In that case this discussion cannot move it — support.github.com is the only route that can requeue provisioning.

[jackyshenfenghua]

Thanks — I tested both endpoints as suggested.

Both the apex and www hostnames return a plain HTTP/1.1 404 Not Found directly from Server: GitHub.com, with no 301/308 redirect:

http://fenghuashen.com/.well-known/acme-challenge/test → 404
http://www.fenghuashen.com/.well-known/acme-challenge/test → 404

There is also no proxy in front of the site, and the earlier DNS checks confirmed no AAAA, CAA, or DS records.

So this appears to further rule out a DNS or redirect issue on my side. The certificate state remains authorization_created, and HTTPS is still presenting the default *.github.io certificate.

I’ll leave the DNS and Pages configuration unchanged for now. Thanks for helping narrow this down.

[geekysaksham]

Based on the information you've shared, it doesn't appear that there's anything obviously misconfigured on your end.

The https_certificate.state: authorization_created status means GitHub has already requested the certificate and completed the authorization step. At this stage, the remaining work is the actual certificate issuance and deployment, which is handled by GitHub Pages' infrastructure (and its certificate provider), not by your repository configuration.

Since you've already:

verified the DNS records,
verified domain ownership,
removed and re-added the custom domain,
avoided making further DNS changes,

repeatedly removing and re-adding the domain is unlikely to help. In fact, it can restart the provisioning process and potentially delay issuance further.

The fact that:

HTTP works correctly,
the domain is verified,
Pages is built successfully,
the certificate request has progressed to authorization_created,

all suggest that the remaining step is waiting for GitHub's certificate provisioning pipeline to complete.

If the status remains unchanged for more than 24–48 hours, your best option is to open a GitHub Support ticket (if you're eligible) or wait for a GitHub staff member to investigate, as they can inspect the backend provisioning queue. Several recent Community reports indicate that other users have experienced the same symptom, which suggests this may be an infrastructure-side issue rather than an individual configuration problem.

In the meantime, leaving the DNS records and Pages configuration unchanged is the correct approach.