Pages apex TLS certificate omits arlodobermann.com while www works

[sabrebluedobie]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Goal

Keep www.arlodobermann.com as the canonical GitHub Pages custom domain for Petfluencers/Arlo-Dobermann, while having valid TLS on https://arlodobermann.com so the apex can securely redirect to www.

Observed behavior

• https://www.arlodobermann.com loads normally with a valid certificate for www.arlodobermann.com.
• https://arlodobermann.com still fails normal TLS hostname validation before an HTTP response is available.
• At 2026-10-04 14:46:53–14:47:09 UTC, the apex served GitHub's generic CN=*.github.io certificate. Its SANs covered GitHub domains (*.github.com, *.github.io, *.githubusercontent.com and their roots) but did not include arlodobermann.com.
• Plain HTTP at the apex returned 301 Location: https://www.arlodobermann.com/.
• Pages reported the site built with HTTPS enforced, but the approved certificate domains contained only www.arlodobermann.com.

DNS checks

Read-only checks at 15:57–15:59 UTC showed:

• Apex A and AAAA records: all four documented GitHub Pages addresses.
• No apex CNAME.
• www CNAME: petfluencers.github.io.
• No CAA at the apex/root; the CNAME target's CAA permits Let's Encrypt.
• Wildcard lookup: NXDOMAIN.
• Recursive Google Public DNS checks reported DNSSEC validation. I did not directly query both authoritative nameservers, so I am treating that as recursive-resolver evidence, not proof from every authoritative server.

Troubleshooting already completed

At about 13:46 UTC on October 4, the existing www.arlodobermann.com Pages custom domain was removed and immediately re-added to restart certificate provisioning. More than an hour later, the apex still served the generic certificate. GitHub Support ticket #4821779 was closed with self-service/community guidance and no configuration change or fix.

Question

What is the supported way to trigger or obtain certificate issuance for arlodobermann.com while keeping www.arlodobermann.com as the canonical Pages domain? The records appear consistent with GitHub Pages guidance, but that is an observation rather than a proven GitHub-side root cause. I do not want to repeat the reset or change the canonical-domain strategy without evidence that it is required.

[jayakanthh]

I checked this from outside. Your DNS is correct: both Cloudflare authoritative nameservers return the four GitHub A/AAAA records at the apex and the www CNAME, there's no CAA, and the zone looks unsigned (no DS/DNSKEY), so DNSSEC isn't a factor.

The Pages API shows the approved certificate covers only www. That certificate was issued Sep 3, so your Oct 4 reset reused it instead of ordering a new one. The apex was left out of the original order.

Something worth trying:

Set the apex as the custom domain in Settings → Pages and wait for the certificate to show approved.
Switch the custom domain back to www.

This briefly changes your canonical domain, and I can't guarantee it works, so it's your call. If you'd rather not, reply on ticket #4821779 with the points above (DNS verified at both authoritative servers, certificate issued Sep 3 for www only), since that points to a GitHub-side issuance problem.

[metopism]

The supported way to get Pages to attempt provisioning again without changing your canonical domain strategy is to remove and re-add the custom domain from the Pages settings — but you've already done that once, so the more useful question is whether the provisioner actually sees what you expect it to.

GitHub's cert provisioner does its own DNS resolution independently from what you or public checkers see. The most common silent blocker is a CAA record that doesn't include letsencrypt.org. Run dig CAA arlodobermann.com and dig CAA www.arlodobermann.com — if there are CAA records present and Let's Encrypt isn't in them, that's your answer without needing to touch anything else.

If CAA comes back clean and your A/CNAME records are stable across regions, the provisioning attempt may just be stalled on GitHub's end rather than failing for a DNS reason. At that point the only lever available to you is a support ticket at support.github.com — they can see the provisioner logs and confirm whether it's a GitHub-side issue or whether the DNS check is genuinely failing from their vantage point. That gives you the evidence you're looking for before committing to another reset or changing the canonical domain setup.

[PrithwishDas101]

Since the www hostname works but the apex hostname serves a certificate that doesn't cover it, I'd first verify that both DNS and GitHub Pages' custom-domain configuration are correct.

A few things I'd check:

• Confirm the apex A/AAAA records match GitHub Pages' current documented configuration, and that there aren't stale AAAA records pointing elsewhere.
• Verify that the repository's custom domain configuration includes the intended hostname and that GitHub Pages has finished provisioning HTTPS for it.
• Check the certificate again after any DNS or domain configuration changes; a redirect from the apex to www cannot fix a TLS hostname mismatch because TLS validation happens before the HTTP redirect.

The important distinction is that both hostnames need valid TLS independently if users are expected to visit both over HTTPS. I'd avoid changing the canonical domain until the apex certificate issue is resolved.

GitHub's [custom domain and HTTPS documentation](https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site) is a useful checklist.