Site name: triplelayeredbmc.netlify.app
Site ID: 702702f5-b214-419c-ba25-2c4077ec0fc9
Domains to remove: icebug.com and www.icebug.com (currently set as primary domain, stuck in “Pending DNS verification” since this domain was added by mistake and its DNS doesn’t point here, it’s our company’s main site hosted elsewhere)
Desired primary domain: tlbmc.icebug.com (already shows a verified green “Netlify DNS” status as a domain alias)
The stuck icebug.com is blocking Let’s Encrypt certificate provisioning for the whole project. Both the dashboard’s “Remove”/“Set as primary domain” actions and a direct API PATCH to custom_domain are blocked with: {“code”:422,“message”:“We’re provisioning a certificate for your site, you cannot change custom domains until that process completes”}
Deadline: we need tlbmc.icebug.com live with a valid certificate for a public event presentation on September 4.
Would appreciate a manual unstick on Netlify’s side. Thanks!
Confirmed this isn’t a domain-conflict issue: I fully removed the old project (triplelayeredbmc, site_id 702702f5-b214-419c-ba25-2c4077ec0fc9) and its domains, including tlbmc.icebug.com. The new project (tlbmc) still gets ‘certificate parameter is required when updating an existing certificate’ when clicking Provision certificate, even though DNS verification shows successful. Seems like an orphaned certificate record tied to tlbmc.icebug.com persisting independently of either project.
This sounds like a provisioning lock rather than a normal DNS propagation issue. Since tlbmc.icebug.com is already verified, the main blocker seems to be the certificate process still holding icebug.com as the primary domain.
I’d avoid making repeated API changes while that lock is active, since the 422 response indicates Netlify is preventing domain changes until provisioning finishes. Given the September 4 deadline, a manual intervention from Netlify support to remove the incorrect domain or reset the certificate provisioning state seems like the right path. Providing the site ID and the exact 422 response in the support request should help them identify the stuck deployment quickly.