GitHub Pages HTTPS certificate provisioning stuck in “new” state

[zhuyuting-cmd]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Repository: https://github.com/zhuyuting-cmd/haohan-tea-site

Custom domain: hhdhjsy.cn

The custom domain has been correctly configured for GitHub Pages, but the HTTPS certificate has remained in the “new” state for several days.

The GitHub Pages API returns:

• certificate state: new
• description: “This domain was recently added. The certificate request process will begin shortly.”
• https_enforced: false

The GitHub Pages DNS health check confirms:

• dns_resolves: true
• is_pointed_to_github_pages_ip: true
• is_non_github_pages_ip_present: false
• is_served_by_pages: true
• is_valid: true
• is_https_eligible: true
• caa_error: null

The same valid result applies to www.hhdhjsy.cn. However, HTTPS still reports “peer_failed_verification”, and HTTPS enforcement cannot be enabled because a certificate has not been issued.

Please investigate the stalled certificate provisioning job and restart or complete certificate issuance for hhdhjsy.cn.
The custom domain was last re-added on July 17, 2026, but certificate provisioning has still not started.

[initial-d]

I checked the public DNS/HTTP side and your diagnosis looks right: this does not look like a normal DNS misconfiguration.

What I see from outside:

hhdhjsy.cn A
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

www.hhdhjsy.cn CNAME
zhuyuting-cmd.github.io.

HTTP is already being served by GitHub Pages:

HTTP/1.1 200 OK
Server: GitHub.com
X-GitHub-Request-Id: 54BA:100D26:4D73F:6E1CE:6A5CD35A

But HTTPS currently fails with a certificate-name mismatch:

SSL: no alternative certificate subject name matches target host name 'hhdhjsy.cn'

Given that your Pages DNS health check says is_valid: true, is_https_eligible: true, and caa_error: null, this sounds like the Pages certificate provisioning/binding job is stuck rather than the domain being pointed incorrectly.

A few things I would include if you reopen/escalate the support ticket:

1. Domain: hhdhjsy.cn
2. Repository: zhuyuting-cmd/haohan-tea-site
3. Date custom domain was re-added: July 17, 2026
4. Pages API result: certificate state still new
5. DNS health check result: valid + HTTPS eligible + no CAA error
6. External evidence: HTTP is served by GitHub Pages, HTTPS fails only because the issued/served certificate does not include hhdhjsy.cn

Relevant docs:

• GitHub Pages HTTPS troubleshooting: https://docs.github.com/en/pages/getting-started-with-github-pages/securing-your-github-pages-site-with-https
• Custom domain troubleshooting: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/troubleshooting-custom-domains-and-github-pages
• Pages REST API, including Pages site and DNS health check endpoints: https://docs.github.com/rest/pages/pages

If you want one safe self-service retry before waiting on support, I would do this only once: remove the custom domain from Pages settings, wait a few minutes, add hhdhjsy.cn back, then wait for the Pages API certificate state to move away from new. Repeating that many times can make timing harder to reason about, so after one clean retry I would leave the configuration stable and ask GitHub Support to restart/check the certificate provisioning job.

[zhuyuting-cmd]

Thank you for confirming the diagnosis.

I am using GitHub Free, and the GitHub Support portal does not provide a GitHub Pages or HTTPS certificate ticket category for my account.

Since the DNS health check reports that the domain is valid and HTTPS eligible, but the certificate state has remained “new” since July 17, could a GitHub staff member or community moderator please escalate this certificate provisioning issue internally, or advise the correct supported escalation path?

I will keep the current DNS and custom-domain configuration unchanged.

[initial-d]

Keeping the DNS and custom-domain settings unchanged is the right next step. A normal community member or moderator cannot directly restart the Pages certificate provisioning job, and I would not recommend repeatedly removing/re-adding the domain now that the DNS health check is valid.

For GitHub Free, this Community Discussion is the appropriate public escalation path when the Support portal does not expose a Pages/HTTPS ticket category. Keep the thread updated with the repository, domain, the date the domain was last added, and a fresh Pages API result showing the certificate still in new. Also check https://www.githubstatus.com/ for a broader Pages incident.

At this point the remaining action requires GitHub staff or the Pages backend to advance or restart provisioning; there is no additional DNS change indicated by the evidence you posted.

[SayemSamir]

Hi! This is a known issue where GitHub Pages certificate provisioning gets stuck in "new" state even when DNS is correctly configured. Here are a few things to try:

1. Remove and re-add the custom domain
Go to your repo → Settings → Pages → remove hhdhjsy.cn → save → then re-add it again. This often triggers a fresh certificate request.

2. Check your CAA DNS records
Even though caa_error is null, make sure you don't have any CAA records that block Let's Encrypt (the CA GitHub uses). Run:

dig CAA hhdhjsy.cn

If any CAA records exist, either remove them or add:

hhdhjsy.cn. CAA 0 issue "letsencrypt.org"

3. Temporarily disable HTTPS enforcement
Make sure "Enforce HTTPS" is unchecked while waiting — having it checked with no cert can block provisioning.

4. Contact GitHub Support directly
Since it's been several days and DNS health checks all pass, this is likely a stuck provisioning job on GitHub's side that needs manual intervention. Open a ticket at:
👉 https://support.github.com

Include your repository URL, custom domain, and mention the certificate has been in "new" state since July 17 — they can manually trigger the certificate issuance.

Hope it gets resolved soon! 🙂

[pharos-off]

I've run into this issue before. If your GitHub Pages HTTPS certificate is stuck in the "new" state, it's usually because the certificate hasn't finished provisioning yet or there's a problem with your DNS configuration. The first thing I'd check is that all of your DNS records (A, AAAA, or CNAME, depending on your setup) are correct and have fully propagated. Even if everything looks right, DNS propagation can sometimes take several hours.

If your DNS is configured correctly, try waiting a bit longer and then disable and re-enable Enforce HTTPS in your GitHub Pages settings. In many cases, that triggers GitHub to retry the certificate provisioning process.

If the certificate is still stuck after 24–48 hours, it's likely not something you can fix yourself. At that point, I'd recommend reaching out to GitHub Support with your repository URL and custom domain details so they can investigate the issue on their end.

[albertoridolfi]

I am seeing the same current failure on a second account/site, www.ridf.net and ridf.net. The Pages API remains at certificate state new; both hosts are valid and HTTPS-eligible in the authenticated DNS health check, caa_error is null, all documented A/AAAA records and the www CNAME are present, the domain is verified, and Pages builds succeed. ridf.net still has the prior apex-only certificate, while www.ridf.net serves the generic *.github.io certificate and fails hostname verification. A clean remove/wait/re-add cycle and rebuild did not advance provisioning, and no new certificate appears in CT logs.

To rule out stale repository/site-level state, I duplicated the homepage and its history into a fresh Pages repository, https://github.com/albertoridolfi/ridf-pages-fallback, moved the verified domain binding there, renamed the now-detached original repository, and successfully deactivated the old Pages site (which GitHub had refused to deactivate while it was the special user-site repository). The fresh site built successfully and a new Pages DNS-health run is completely valid, but it immediately inherited the same certificate expiry metadata and remains in state new. HTTP continues to serve the homepage. This strongly points to a domain/account-level Pages certificate backend record or stuck issuance job rather than the repository, build, or DNS.

Possibly relevant: GitHub Status recorded Pages degradation during the July 19–20 incident, whose published root cause was an internal certificate-lifecycle management failure: https://stspg.io/w8d77c7t94zf. Pages was marked recovered, but these certificate jobs may be residual stuck work; that is an inference from timing and the identical backend state, not proof. GitHub staff need to inspect or restart issuance for the domain.

[albertoridolfi]

Status update after more than eight additional hours of uninterrupted observation: the fresh fallback Pages site remains built, both ridf.net and www.ridf.net continue to pass authenticated Pages DNS health as valid and HTTPS-eligible with no CAA error, and HTTP serves the homepage. However, the certificate has not progressed beyond state new, https_enforced remains false, www still serves the generic *.github.io certificate, and no new matching certificate has appeared. Continuous API and edge checks confirm that this is not propagation. All self-service recovery paths have been exhausted; this now requires a GitHub Pages engineer to clear or re-kick the domain-level certificate issuance job.

[nandagopan006]

I've seen this exact issue before and it's super frustrating. The problem is that right when the 3-2-1 timer finishes, the browser sends a command that makes your laptop webcam freak out and try to refocus at the worst possible millisecond.

Instead of fighting with it, here is how you can actually get around it:

Honestly, the absolute easiest way is to just do the verification on your phone. If you log into GitHub on your mobile browser, your phone's camera sensor won't have that same autofocus glitch, and it handles close-up text way better anyway.

If you have to do it on your PC, OBS Studio is a lifesaver. Just add your webcam into OBS and click "Start Virtual Camera." When the GitHub page asks for your camera, pick the OBS one instead of your actual webcam. Because OBS feeds a steady, pre-processed video to the browser, it completely blocks that annoying autofocus bug.

If you don't want to install extra software, try to take your hands out of the equation. Holding the paper causes tiny shakes that trigger the blur. Lay your certificate totally flat on a desk under a really bright light, and tilt your laptop screen down to frame it. Also, if you're using a standalone webcam (like a Logitech), open your camera settings on your PC and switch it from "Auto" to "Manual" focus. Lock it so the text is crisp before you even start the timer.