Custom Domain Stuck on SSL Validation

You added the record. dig shows it. The platform still says pending, and has said pending for an hour. A custom domain stuck validating is maddening precisely because every check you can run yourself appears to pass.

There are four causes, they are all mechanical, and the order below finds them fastest.

First: what validation is actually doing

Before a certificate authority issues a certificate, it has to establish that you control the name. There are two common ways, and which one your platform uses changes what can break it:

• HTTP-01 — the CA requests http://your-domain/.well-known/acme-challenge/<token> and expects a specific string. This requires that plain HTTP requests to your domain reach the platform.
• DNS-01 — the CA looks for a TXT record. This requires that the record exists and is visible to the CA's resolver, which is not necessarily the one you queried.

Almost every stuck validation is something standing between the CA and one of those two things.

Cause 1: a proxy in front of the challenge

This is the most common cause when the domain sits behind a CDN, and it is genuinely confusing because the proxy is usually the thing you wanted.

If your DNS record is proxied rather than pointing directly at the platform, the CA's HTTP-01 request terminates at the proxy. The proxy serves its own certificate, applies its own rules, and may return a redirect, a challenge page, or a 404 — none of which contain the token the CA is waiting for.

The fix is to let the challenge through:

• Turn the proxy off (grey-cloud the record) until the certificate issues, then turn it back on.
• Or exclude /.well-known/acme-challenge/* from any redirect or access rule.

The trap here is that "Always Use HTTPS" and "Under Attack" style protections both break HTTP-01 while looking, from your browser, like the site is working perfectly.

Cause 2: the wrong record type

Two mistakes account for most of the rest:

A record pointing at an address that moves. If the platform gave you a hostname, use a CNAME. Copying the current IP into an A record works right up until the address changes underneath you.

A CNAME at the zone apex. example.com cannot legally hold a CNAME alongside its SOA and NS records. Some providers offer ALIAS, ANAME, or "CNAME flattening" to work around this; some do not. If yours does not, use a subdomain — app.example.com — and redirect the apex.

# What the world actually sees, not what your dashboard shows
dig +short app.example.com CNAME
dig +short app.example.com A

If both come back empty, nothing else on this list matters yet.

Cause 3: propagation you are not measuring

dig with no arguments asks your resolver, which may have cached the answer you just created — or worse, cached the NXDOMAIN from before you created it. A negative cache entry with a long TTL is a genuinely common reason for a validation that fails for an hour and then succeeds with no intervention.

Query the authoritative servers directly, and query a public resolver, to see what the CA is likely to see:

# Ask the zone's own nameservers
dig +short app.example.com @$(dig +short NS example.com | head -1)

# Ask a resolver outside your network
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8

If the authoritative answer is right and the public resolvers are wrong, you are waiting on TTL and there is nothing to fix.

Cause 4: CAA is refusing the issuer

This one is rare, invisible in normal DNS checks, and completely silent when it bites.

A CAA record on your domain lists which certificate authorities may issue for it. If you have one — often inherited from an old setup, or set by a security scan recommendation — and it does not include the CA your platform uses, issuance fails and the only place it says so is in the CA's logs, which you cannot see.

dig +short example.com CAA
dig +short app.example.com CAA

Empty output means no restriction, which is fine. If you get records back, either add the CA your platform uses or remove the restriction.

The order that finds it fastest

1. dig the record against a public resolver. No answer means the record is wrong or has not propagated — stop here.
2. Check whether the record is proxied. If it is, un-proxy it or exclude the ACME path.
3. Check CAA on both the apex and the subdomain.
4. Then, and only then, consider that the platform is at fault.

Ninety per cent of stuck validations end at step 1 or step 2.

How this works on Dockup

Two design choices remove most of the guesswork.

The DNS record is created for you. If your zone is on Cloudflare and you have connected the account, adding a domain writes the record itself rather than leaving you to hand-copy a value:

dockup domain add app.example.com my-project/my-api --port 3000 --cloudflare

That eliminates the entire class of typo and record-type mistakes — the platform knows whether it needs a CNAME or an A record and creates the right one.

The grant is two permissions. Zone:Read and DNS:Edit, and nothing else. Dockup cannot read your other zones, change account settings, or touch anything it was not given. Connecting DNS automation should not require handing over an account.

Verification and certificate state are visible per domain rather than as one aggregate status, so "DNS verified but TLS pending" reads as what it is — two separate steps, one of which finished.

Frequently asked questions

How long should certificate issuance take? Usually under a minute once DNS resolves correctly. If it has been pending for more than about fifteen minutes, something is blocking it rather than being slow.

Why does my domain work in the browser but fail validation? Because your browser follows redirects and uses HTTPS, and the challenge does neither. A proxy that serves your site perfectly can still swallow the plain-HTTP ACME request.

Can I use a CNAME on my root domain? Not in standard DNS. Use a provider feature like ALIAS or CNAME flattening, or point the apex at a subdomain with a redirect.

What is a CAA record and do I need one? It restricts which certificate authorities may issue for your domain. You do not need one, but if you have one that omits your platform's CA, issuance fails silently.