SSL Certificate Not Provisioning: Diagnosing a Stalled Issuance

Every stalled issuance is a proof of domain control failing somewhere specific, and there are only three places to look.

SSL certificate not provisioning: what the issuing process is waiting for

Adding a custom domain to a hosted platform normally ends with a padlock appearing by itself. When it does not, the status sits at pending, issuing or something similarly vague, and there is usually no explanation attached. The temptation is to press retry until something changes, which is the one action that reliably makes it worse.

Issuance is not magic and it is not arbitrary. A certificate authority will only sign a name once it has proved you control that name, and every stalled provisioning is that proof failing somewhere specific. Once you know which of the three steps is failing — resolution, validation, or installation — the cause is usually obvious within a minute. What the visitor sees while all of this is unresolved is a separate question, covered in reading the browser warning itself; this article is about the machinery behind it.

The proof of control, in outline

Whatever the platform, the shape is the same. The authority issues a challenge for the exact hostname, and you satisfy it in one of two ways:

• An address-based challenge. The authority requests a specific path on the hostname over plain HTTP and expects a specific response. This requires the name to resolve to the platform already, and requires the request to reach the platform unaltered.
• A record-based challenge. The authority asks for a specific record to appear in the domain’s DNS zone. This works before any traffic is pointed anywhere, which is why it is the one used for wildcard names and for issuing ahead of a cutover.

Almost every stall is one of these being unable to complete, and the two fail for completely different reasons. Knowing which one your platform uses narrows the search immediately.

Step one: does the name resolve where you think?

Look up the hostname from outside your own network and read the answer, rather than reading the registrar’s control panel. The panel shows intent; resolution shows reality, and the gap between them is where several days can go.

The IPv6 case is worth calling out because it is invisible in normal use. Many networks prefer an IPv6 answer when one exists, so a leftover record can quietly capture exactly the requests that matter while everything else looks fine.

Editing the zone is the same operation as adding mail authentication records, and the same discipline applies: make the change in the zone the domain is actually using, wait for it to be visible from outside, and verify before moving on. Anyone who has worked through the mail authentication records or set up a sending domain already has the habit.

Step two: can the challenge complete?

If the name resolves correctly and issuance still stalls, something is interfering with the proof itself. The usual suspects, in the order they turn up:

• A redirect that catches everything. A blanket rule sending all traffic to another host, or forcing every request to HTTPS, will also catch the authority’s plain-HTTP request. The challenge path has to be reachable unredirected.
• A restriction record on the domain. Domains can carry a record naming which authorities are permitted to issue for them. If one exists and does not name the authority your platform uses, every request is refused, politely and permanently, until the record is changed.
• Another service answering first. A parking page, an old host still serving the name, or a proxy in front of the platform can respond to the challenge with its own content.
• The hostname was never added on the platform. Pointing DNS does not by itself tell the platform to request a certificate for that name. Both sides have to name the host.
• A wildcard was expected where a single name was requested. A certificate for one host does not cover its subdomains, and a wildcard normally requires the record-based challenge rather than the address-based one.

Why pressing retry makes it worse

Certificate authorities apply rate limits, and repeated failures for the same name count against them. A stalled request that is retried every few minutes can reach a limit that then blocks issuance for a period measured in hours, long after the underlying cause has been fixed. At that point the configuration is correct and the certificate still will not appear, which is a genuinely confusing place to be.

So the discipline is: diagnose first, change one thing, then request once and wait. If you have already been retrying, expect a delay after the real fix and do not treat that delay as evidence the fix did not work.

Step three: issued, but still not serving

Occasionally a certificate exists and the site still does not present it. Three causes account for most of these.

The wrong name is being served

A visitor reaching a hostname the certificate does not cover gets a name mismatch even though a valid certificate exists on the same server. Check which hostname the browser is actually on after any redirects, not the one you typed.

An incomplete chain

A certificate is presented along with the intermediate certificates that connect it to a trusted root. If those are missing, some clients accept it and others refuse, which produces the maddening pattern where it works on your desktop and fails on a phone or inside an app.

Caching in front of the origin

A proxy or content network holding an older certificate, or terminating the connection itself, will keep serving what it has until it is refreshed. If the platform says issued and the world disagrees, look at what sits between them.

Renewal is the same process, running unattended

Automatic renewal repeats the validation. Anything that would block a first issuance will block a renewal, and the failure is silent because the existing certificate keeps working until it expires — typically weeks after the renewal actually stopped succeeding.

The practical consequence is that DNS changes are the risky moment, not the renewal date. Adding a restriction record, moving nameservers, introducing a proxy or adding a broad redirect can all break renewal for a name that has been fine for a year. Treat any change to a domain’s zone as an event that requires re-confirming the certificate for hostnames in it.

A diagnostic order that finishes quickly

• Resolve both the bare name and the www name from outside your network, and check for an unexpected IPv6 answer.
• Confirm the exact hostname is configured on the platform, not just in DNS.
• Request the plain HTTP address and follow every redirect, watching whether anything intercepts before the platform answers.
• Look for a restriction record on the domain, and check that it permits the authority your platform uses.
• Check whether a proxy or content network sits in front, and what it is configured to do with certificates.
• Fix one thing, request issuance once, and wait rather than retrying.
• Once it appears, confirm the served certificate covers every hostname you expect and presents a complete chain.

Make it a step rather than an incident

Almost every stalled provisioning traces back to a change nobody recorded: a redirect added for one campaign, a proxy switched on, a zone edited by someone else. Put the certificate check into the client onboarding checklist as a confirmation with a result, and add a re-check to whatever procedure covers DNS changes, in the same way any other repeatable step belongs in a written procedure rather than in somebody’s memory of how the last one went.

See also: Redirect WWW to Funnel: Choosing One Canonical Host

Frequently Asked Questions

Why is my SSL certificate stuck on pending or issuing?

Because the proof of domain control has not completed. A certificate authority signs a hostname only after verifying you control it, so a stalled request means either the name is not resolving to the platform, the challenge cannot complete, or the platform was never told to request that exact hostname. Work through those three in order and the cause is usually obvious within a minute.

Does pointing DNS automatically get a certificate issued?

No. Both sides have to name the host. DNS tells the internet where the hostname lives, and the platform has to be configured to request a certificate for that exact name. A very common stall is a correctly pointed domain that was never added on the platform side, or where only the bare domain was added while visitors also reach the www version.

Can a redirect stop a certificate from being issued?

Yes, and it is one of the most common causes. An address-based challenge asks for a specific path on the hostname over plain HTTP, so a blanket rule that redirects everything to another host, or forces every request to HTTPS, also catches the authority’s request. The challenge path has to be reachable without being redirected away.

What is a CAA record and can it block issuance?

It is a record in the domain’s DNS zone naming which certificate authorities are permitted to issue for that domain. If one exists and does not include the authority your platform uses, every request is refused and will keep being refused until the record is updated. It is easy to miss because nothing about the platform’s status message points at the domain’s own zone.

Should I keep clicking retry while a certificate is pending?

No. Authorities rate limit requests and repeated failures for the same name count against the limit, so retrying can block issuance for hours after the real problem has been fixed. Diagnose first, change one thing, then request once and wait. If you have already been retrying, expect a delay after the correct fix and do not read that delay as the fix having failed.

Why does the site work on my laptop but fail on a phone?

Most often an incomplete chain. A certificate is presented along with intermediate certificates linking it to a trusted root, and when those are missing some clients fill the gap from their own cache while others refuse outright. That produces exactly this split, where a desktop browser is satisfied and a phone or an in-app browser is not.

Why did renewal fail on a domain that has worked for a year?

Because renewal repeats the same validation, so anything that would block a first issuance blocks a renewal too. The usual trigger is a change in the domain’s DNS zone: new nameservers, a restriction record, a proxy introduced in front, or a broad redirect added for a campaign. The failure is silent because the existing certificate keeps working until it expires, often weeks later.

We build your GoHighLevel account for you

CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.

• Setup (one-time)$850
• Ongoing (per month)$38.80

Get my free setup quote

No obligation quote · reply within 1 business day

This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.