Pages TLS stuck at dns_changed for smc12puls.com despite successful DNS

[junteakim]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Hello GitHub team/community,

The existing Pages site for https://github.com/junteakim/sps-company-website is being moved to the canonical custom domain smc12puls.com. HTTP works, but the custom-domain TLS certificate is still unavailable.

At the time of the initial post, Repository Settings > Pages showed:

• DNS check successful
• TLS certificate is being provisioned, 1 of 3
• Certificate Requested: Detected a change to DNS settings. Requesting a new certificate.
• Enforce HTTPS disabled because certificate issuance has not finished

Configuration:

• Apex ALIAS @ -> junteakim.github.io
• www CNAME -> junteakim.github.io, TTL 14400
• All four authoritative nameservers are ns-cloud-c1/c2/c3/c4.googledomains.com

As verified at 2026-10-07 23:37 UTC:

• All four authoritative nameservers and Cloudflare, Google and Quad9 return the four documented GitHub Pages IPv4 and IPv6 addresses for the apex, and the expected www CNAME/addresses.
• No CAA restriction was found. The .com delegation has no DS, so this is an unsigned domain rather than an observed DNSSEC validation failure.
• HTTP to the apex returns 200 from GitHub on all four IPv4 addresses.
• HTTP to www returns 301 to http://smc12puls.com/ on all four IPv4 addresses.
• TLS with SNI for either custom hostname on all four IPv4 addresses presents the default *.github.io certificate, without either custom hostname in its SANs.
• Direct IPv6 connectivity could not be tested from this probe host; its DNS answers are consistent with the documented values.

The www DNS change was saved on 2026-10-07 at approximately 21:13 UTC. Following the official troubleshooting documentation, the custom domain was removed and re-added once at approximately 22:20 UTC. DNS checks subsequently succeeded, but the certificate remains at 1 of 3. We have not continued resetting it or changing DNS.

Could GitHub staff check whether the certificate-provisioning job is blocked and advise whether an internal retry is needed? We understand that the public DNS and HTTP checks do not establish the internal cause of the delay.

Thank you.

Update: intermittent Pages check failure (observed 2026-10-07 23:55 UTC)

The same unchanged configuration is intermittently reported as successful or unsuccessful by the Pages DNS check. At 23:55 UTC, the UI showed:

Both smc12puls.com and its alternate name are improperly configured.
Domain does not resolve to the GitHub Pages server. (NotServedByPagesError)

Independent checks at 23:56 UTC still returned the expected GitHub Pages A/AAAA records and www CNAME via authoritative DNS, Cloudflare, Google, Quad9, Google TCP DNS, and Google/Cloudflare DNS-over-HTTPS with literal resolver bootstrap. No Squarespace address was observed.

Both normally resolved and GitHub-IP-pinned HTTP requests served the existing SPS homepage (apex: 200, Server: GitHub.com) or redirected www to the apex (301, Server: GitHub.com). The repository main branch CNAME file was also verified to contain exactly smc12puls.com. Normal TLS verification still fails for both custom names.

These external DNS and HTTP results conflict with the intermittent Pages check error; they do not establish its internal cause. No further DNS changes or custom-domain resets were made.

[jovanovic-djo]

I would not remove nor re-add the domain again, since the each time restarts the process, and repeated failed attempts can run into rate limits.
Open a ticket at support.github.com. Include repo junteakim/sps-company-website, domain, and that the status has been "Certificate Requested: Detected a change to DNS settings" since about 22:20 UTC on Oct 7.
It might take a while, but once the certificate is issued, enable Enforce HTTPS.
If the redirect doesn't kick in right away, trigger a new Pages build (you can push a small commit).

I hope this works for you.