GitHub Pages certificate request error after custom-domain reset

[JustinJIndustries]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Repository: https://github.com/JustinJIndustries/JustinJ_Industries_Website
Domain: www.justinjindustries.com

Please help investigate certificate provisioning for this custom domain. The origin certificate expired on October 25, 2026 at 16:31:22 UTC, and GitHub Pages continues to show “Certificate Request Error” with automatic retry pending.

Checks performed, all on October 25 in UTC:

• DNS uses proxied CNAMEs: apex → www → justinjindustries.github.io. No restrictive CAA records were observed.
• At 22:08–22:10, I removed and immediately re-added the same custom domain once. GitHub confirmed restoration and “DNS check successful.” DNS, proxy and security settings were not changed.
• At 23:10–23:11, the domain remained assigned and DNS passed, but certificate provisioning still failed. Enforce HTTPS remained unavailable; the interface also displayed a notice to allow 24 hours.
• Direct TLS verification against 185.199.108.153 using www.justinjindustries.com as SNI still returned the expired certificate.

The Cloudflare-facing homepage and Services page load normally in Safari without security warnings. Automated public requests encounter Cloudflare challenges, so those checks do not establish origin health. I’m not claiming a site-wide outage or a confirmed cause.

I followed the GitHub Pages HTTPS troubleshooting guidance. Could you advise why issuance is failing and whether any further action is needed while retries remain pending?

I have not repeated the reset.

[rjsgud49]

The proxy is the most likely reason. From here, public DNS for both names returns Cloudflare's addresses, not GitHub's:

www.justinjindustries.com  A     104.21.20.72, 172.67.191.223
justinjindustries.com      A     172.67.191.223, 104.21.20.72
(+ Cloudflare AAAA, no CAA)

GitHub gets the certificate from Let's Encrypt, and Let's Encrypt checks the domain with an HTTP request to http://www.justinjindustries.com/.well-known/acme-challenge/... on port 80. With orange-cloud records that request goes to Cloudflare first. You noted that automated requests get Cloudflare challenges, and the validator is exactly that kind of request, so it never gets the token from Pages and issuance fails. The docs' DNS section also expects the records to point at Pages itself.

The site still looks fine in Safari because browsers get Cloudflare's edge certificate (Google Trust Services, valid until Dec 7), not the GitHub one. If your SSL/TLS mode is "Full" rather than "Full (strict)", Cloudflare keeps accepting the expired origin cert, so nothing looks broken to visitors.

What I'd do:

1. In Cloudflare, switch both the www and apex records to DNS only (grey cloud). www should then resolve as a CNAME to justinjindustries.github.io.
2. Wait until public DNS shows GitHub's 185.199.108-111.153 addresses, then let the retry run. If it is still stuck after that, do one remove/re-add in Pages settings.
3. Once the certificate is issued, turn on Enforce HTTPS.

If you want the proxy back afterwards, use "Full (strict)". Keep in mind that the certificate renews about every 90 days through the same HTTP check, so /.well-known/acme-challenge/* must not be challenged. On the Free plan, Bot Fight Mode can't be exempted with a skip rule, so leaving the records DNS-only is the simpler option.

[rjsgud49]

Community members (me included) can't see Pages' certificate jobs, so the authorization error, IP and timestamp have to come from GitHub Support. Open a ticket at https://support.github.com/contact, pick Pages, and include the repo, the domain and the times of your Oct 25 reset. That's the escalation route.

One thing worth sending them along with it: the troubleshooting page says a certificate can fail when records are "not pointing to the IP addresses for GitHub Pages" (docs, "HTTPS errors"). Public DNS still shows only Cloudflare IPs for both names, so even with the ACME path reachable, a proxied setup isn't one GitHub says it supports for issuance. Support may ask you to go DNS-only before they look further.

If you do try it later, the exposure is short: with DNS-only, visitors would see the expired cert only until the new one is issued, which is usually minutes once DNS has propagated. Doing it at a quiet hour and switching the proxy back on right after "Enforce HTTPS" becomes available keeps your failover for the rest of the time.

[JustinJIndustries]

Thanks, Park! Your suggestion worked. We temporarily switched both hostnames to DNS-only, and GitHub issued the renewed certificate within a few minutes. We then restored Cloudflare proxying for both names and verified the site was working normally. Appreciate you sticking with us and clarifying the recommendation.

[JustinJIndustries]

Additional checks: Cloudflare is in Full mode, and a homepage challenge was attributed to Bot Fight Mode. However, synthetic requests to /.well-known/acme-challenge/ reached GitHub with ordinary 404 responses and no mitigation. The sampled 24-hour ACME Events filter showed no matches. This doesn’t prove real-token validation succeeds. Can GitHub provide the actual certificate-validation error, URL and UTC timestamp? Switching DNS-only would bypass our failover and expose the expired origin certificate.

[JustinJIndustries]

Following up with additional checks for JustinJIndustries/JustinJ_Industries_Website and www.justinjindustries.com.

Pages still reports Certificate Request Error despite a successful DNS check. The origin certificate expired October 25 at 16:31:22 UTC. The configured GitHub target resolves to the documented Pages endpoints, and our checks found no evident restrictive CAA record.

The public site remains accessible through Cloudflare Full mode. We have not changed that configuration or repeated the domain reset performed October 25.

Can a GitHub team member help identify the failed certificate authorization, including the hostname, challenge method, attempted IP, error and UTC timestamp, and confirm whether issuance is retrying? If Community cannot access those details, what is the appropriate escalation route? We’d prefer to diagnose the failure before making another domain or proxy change.