GitHub Pages custom-domain HTTPS certificate stuck in "new" for convcomp.it

[solyarisoftware]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

My GitHub Pages custom-domain certificate has remained in state "new", and HTTPS serves the default *.github.io certificate.

Repository: https://github.com/solyarisoftware/solyarisoftware.github.io
Custom domain: convcomp.it

The site is built and serves HTTP successfully (200). The Pages API reports:

• status: built
• protected_domain_state: verified
• https_certificate.state: new
• description: "This domain was recently added. The certificate request process will begin shortly."

Both authoritative nameservers publish the four recommended GitHub Pages A records and four AAAA records. www.convcomp.it is a CNAME to solyarisoftware.github.io; there
is no CAA record blocking issuance. The GitHub Pages health check reported the domain as valid and HTTPS-eligible.

On September 28, 2026 at 17:27 CEST, I removed and re-added the custom domain through the Pages API. At 19:04 CEST the certificate was still "new"; HTTP returned 200
and HTTPS still served *.github.io.

GitHub Support ticket #4802082 was closed by the virtual assistant, which directed me to Community Discussions.

Has anyone seen this Pages certificate provisioning state remain "new" after the documented remove-and-re-add procedure? Is there another diagnostic or recovery step
that keeps the site on GitHub Pages?

thanks
Giorgio

[2171001]

Hey Giorgio! It is incredibly frustrating to get caught in this provisioning limbo, but what you are experiencing is a known backend glitch where the certificate handshake gets permanently stuck; and unfortunately, repeatedly removing and re-adding the custom domain actually pushes you to the very back of GitHub's internal Let's Encrypt queue! Since there is no magical API toggle to force-clear this on your end, the only real solution is to reopen your support ticket and explicitly request an engineer to perform a "manual backend clearance" to re-queue the handshake. To ensure the virtual assistant doesn't auto-close your request this time, you need to provide the raw API evidence proving the domain is frozen.

Here is the complete CLI guide to grab exactly what Support needs to see:

• Step 1: Open your terminal and ensure you are authenticated by running gh auth login.
• Step 2: Fetch your repository's exact Pages configuration state by running: gh api /repos/solyarisoftware/solyarisoftware.github.io/pages
• Step 3: Copy the entire JSON output returned, paying special attention to the https_certificate object showing the "state": "new" status.
• Step 4: Paste that JSON directly into your new GitHub Support ticket along with a clear note stating: "My DNS is fully verified, but my Pages certificate provisioning is permanently stuck in the 'new' state. Please manually re-queue the Let's Encrypt handshake on the backend."

That should bypass the bots and give the human engineers exactly what they need to fix it for you in minutes!

[kurupdevs]

The key detail here is the timestamp: you removed and re-added the domain at 17:27 CEST today. Every time you remove and re-add the domain, the certificate provisioning timer resets to zero, and issuance can take up to 24 hours from that point. So the "new" state you're seeing is most likely just the clock restarting, not a permanent stuck state.

Since your DNS is already verified (protected_domain_state: verified) and there are no blocking CAA records, I'd recommend:

1. Stop removing/re-adding the domain — each cycle restarts the wait.
2. Wait a full 24 hours from the last add, i.e. until after 17:27 CEST on Sep 29, and check whether the certificate has been issued.
3. If it's still in "new" after 24–48 hours, open a new GitHub Support ticket with the repo name, the custom domain, and the https_certificate JSON you already have — that should be enough for an engineer to kick off provisioning manually.

The re-add dance feels like it's fixing something, but for this particular state it's the most common way people accidentally keep resetting the process.

[solyarisoftware]

Thanks both — resolved, and I wanted to close the loop because the outcome was
more interesting than the question.

Resolution

The certificate was issued with no support intervention:

• 17:27 CEST — last remove/re-add of the custom domain
• 19:04 CEST — still state: "new" (what I posted about)
• 20:16 CEST — Let's Encrypt issues it: CN = convcomp.it, valid to 2026-12-27
• ~21:20 CEST — the edge starts serving it
• 21:22 CEST — Enforce HTTPS enabled

So roughly three hours from the last re-add, no ticket needed. The
"stop re-adding and wait" answer was the correct one: it was the queue, not a
stuck state, and each remove/re-add does restart the clock.

The part that might save someone else an evening

The site still looked broken for another hour after the certificate existed.

Between issuance (20:16) and edge rollout (~21:20), https://convcomp.it was
still presenting the *.github.io certificate. My browser hit the warning and I
clicked "Proceed anyway". That decision lives in the browser session, together
with the pooled TLS connection — not on disk, so it survives every cache purge:

• Ctrl+F5 / Ctrl+Shift+R — no effect
• "Disable cache" in DevTools — no effect
• clearing cached files — no effect
• extensions, proxy, policy checks — all clean

What it looked like: correct content, broken-HTTPS warning, in the normal
window but not in a private window (separate socket pool and session). The
only thing that cleared it was quitting the browser completely — all processes,
not just the window — and reopening.

The diagnostic I should have read first: DevTools → Security tab says either
"This page is not secure" (you are on http) or "This page is not secure (broken
HTTPS)" (you are on https and the certificate received is wrong). Those are
opposite diagnoses and very easy to confuse. I spent hours on DNS and cache
before reading that one line.

Takeaways

1. state: "new" really can just be the queue — waiting beats re-adding.
2. Issuance is not rollout. Check which certificate your edge actually serves:
   openssl s_client -connect <edge-ip>:443 -servername <domain> may still show
   the *.github.io one hours after issuance.
3. If you clicked through a certificate warning during that window, fully
   restart the browser before concluding anything else is broken.

Thanks again — no support ticket needed in the end.