Fix GoHighLevel Domain SSL Pending and DNS Errors

by Fahim

You mapped a custom domain to a funnel or website in GoHighLevel, but the dashboard has been stuck on “SSL Pending” for hours. Worse, hitting the URL in a browser throws NET::ERR_CERT_COMMON_NAME_INVALID or a generic 525 SSL handshake error.

I’ve run into this dozens of times across client setups. Here is how to diagnose the actual DNS bottleneck, clean out bad records, and get Let’s Encrypt to provision your certificate without waiting around for support.

Terminal interface showing DNS dig commands and SSL status for GoHighLevel domain configuration
Terminal interface showing DNS dig commands and SSL status for GoHighLevel domain configuration

Why GoHighLevel Domains Get Stuck on SSL Pending

When you add a domain in HighLevel, the platform checks your public DNS records. If the target records resolve cleanly, HighLevel fires an HTTP-01 challenge against Let’s Encrypt (or its edge SSL provider) to provision and bind your certificate.

In practice, this validation pipeline usually breaks for four specific reasons:

  • Cloudflare Proxy (Orange Cloud): HighLevel needs direct access to the edge server. Leaving the Cloudflare proxy enabled hides your origin and intercepts the validation token.
  • Stale AAAA (IPv6) Records: Many registrars drop in default IPv6 records automatically. Let’s Encrypt prefers IPv6 by default, so if an AAAA record exists and doesn’t point to HighLevel, verification fails silently.
  • Conflicting CAA Records: Certificate Authority Authorization records that restrict issuance to specific vendors like DigiCert will block Let’s Encrypt entirely.
  • Multiple A Records: Pointing your apex domain to both an old host (like an abandoned WordPress box) and HighLevel simultaneously.

If you’re configuring app-level branding instead of a funnel, make sure you verify your baseline settings against our guide on setting up a custom whitelabel domain in GoHighLevel.

The Exact DNS Records GoHighLevel Requires

HighLevel supports both apex domains and subdomains, but they use different record types. Don’t mix them up.

For Root Domains (example.com)

Root domains need an A record pointed at HighLevel’s load balancer IP. You’ll also want a CNAME for the www variant so traffic doesn’t get dropped when visitors type the full URL.

  • Type: A | Name: @ (or blank) | Value: 34.68.234.4 | TTL: Auto or 300 seconds
  • Type: CNAME | Name: www | Value: flash.funnels.msgsndr.com | TTL: Auto or 300 seconds

For Subdomains (go.example.com or funnels.example.com)

Subdomains don’t need the A record. Point a single CNAME record directly to HighLevel’s routing edge.

  • Type: CNAME | Name: go | Value: flash.funnels.msgsndr.com | TTL: Auto or 300 seconds

For more nuances on routing rules across pages, check our walkthrough on connecting custom domains and subdomains to GoHighLevel funnels.

Diagnose Your DNS Propagation in the Terminal

Don’t rely on the HighLevel UI to tell you what DNS looks like. Query public nameservers directly using dig so you can see what edge resolvers are actually returning.

Check your root A record using Google’s public resolver:

dig @8.8.8.8 example.com A +short

If this returns anything other than 34.68.234.4—or if you see multiple IP addresses listed in the answer section—HighLevel will fail the SSL challenge.

Next, check for rogue IPv6 (AAAA) records that could be hijacking the Let’s Encrypt validation request:

dig @8.8.8.8 example.com AAAA +short

If this command returns any IP address at all, delete that AAAA record in your DNS manager immediately. HighLevel does not route via IPv6 for custom funnel domains.

Finally, check whether you have restrictive CAA records blocking certificate generation:

dig @8.8.8.8 example.com CAA +short

You can also reference the official HighLevel Knowledge Base if you want to verify that default IP addresses haven’t shifted during an infrastructure update.

Fix Cloudflare Proxy and SSL Mode Conflicts

If your DNS runs through Cloudflare, the default settings will break HighLevel’s SSL provisioning every single time.

Cloudflare proxies traffic through its orange cloud by default. That terminates SSL at Cloudflare’s edge using their universal certificate, which blocks HighLevel from completing its own handshake behind the scenes.

Here is the fix inside Cloudflare:

  1. Log in to your Cloudflare dashboard and select your domain.
  2. Go to DNS > Records.
  3. Locate the A record (@) and CNAME record (flash.funnels.msgsndr.com).
  4. Click Edit on each record and toggle Proxy status from Proxied (Orange) to DNS only (Grey).
  5. Click Save.

If you’re also routing outbound email for this client, check our guide on how to set up a dedicated email sending domain in GoHighLevel so your MX and SPF records don’t conflict with web routing.

Remove Conflicting CAA and Parked Records

Registrars like GoDaddy, Namecheap, and Squarespace (formerly Google Domains) love dropping default parking records into new domains. These silent entries will kill certificate validation.

Open your registrar’s DNS panel and purge these immediately:

  • Parking A Records: Delete any A records pointing to registrar parking IPs (like 34.102.136.180 or similar placeholder servers).
  • Wildcard Records: Check for * A or CNAME records. Wildcards can silently override subdomain lookups unless explicitly shadowed.
  • Restrictive CAA Records: If you see an entry like 0 issue "sectigo.com", Let’s Encrypt is hard-blocked. Either delete the CAA record or explicitly add: 0 issue "letsencrypt.org".

To inspect what certificate is actually being served right now, run openssl:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -dates

This pulls the certificate metadata directly over port 443 so you can see the issuing authority and validity timestamps in plain text.

Force SSL Provisioning and Clear HighLevel Domain Cache

Even after DNS propagates cleanly in dig, HighLevel’s dashboard will often stay stuck on “SSL Pending” because of internal backoff timers. Here is how I force an immediate retry.

  1. In HighLevel, head to Settings > Domains (or Sites > Domains depending on your interface version).
  2. Find the stuck domain and click the Trash / Delete icon.
  3. Wait about 60 seconds for HighLevel’s internal cache to clear.
  4. Click Add New Domain.
  5. Type the domain name without https:// (for example, funnel.clientbrand.com).
  6. HighLevel will run an on-demand DNS check. Once it sees flash.funnels.msgsndr.com or 34.68.234.4, click Verify Domain.

If you manage multiple client setups, make sure you’re doing this in the right sub-account. You can verify your current context with our guide on finding your sub-account location ID in GoHighLevel.

Verify the Live HTTP-to-HTTPS Edge Redirect

Once the dashboard turns green, test the live redirect chain from your terminal to ensure you didn’t introduce an infinite redirect loop:

curl -IL https://example.com

Inspect the returned headers. A healthy HighLevel setup should return an initial HTTP/2 200 or a single 301 Moved Permanently pointing directly to your funnel step:

HTTP/2 200
date: Mon, 15 Jan 2024 14:22:18 GMT
content-type: text/html; charset=utf-8
server: cloudflare
strict-transport-security: max-age=15552000; includeSubDomains

If you see a repeating loop of 301 and 302 redirects bouncing back and forth between http:// and https://, you have an SSL mode mismatch in an upstream CDN or proxy. Keep all DNS records set to “DNS only” to avoid double-proxying.

Frequently Asked Questions

How long does GoHighLevel SSL provisioning take?

Once DNS records propagate, certificate generation takes between 60 seconds and 10 minutes. If your domain has been sitting on “SSL Pending” for more than 30 minutes, DNS is misconfigured or a proxy is actively blocking the HTTP-01 challenge.

Can I use Cloudflare SSL instead of GoHighLevel SSL?

Keep your HighLevel DNS records set to “DNS only” (Grey Cloud). Running Cloudflare’s proxy in front of HighLevel funnels causes origin handshake timeouts and prevents HighLevel’s internal router from mapping requests properly.

Why does my root domain work, but the www version shows a privacy warning?

Both example.com and www.example.com must be added as separate entries in HighLevel under Settings > Domains. Each needs its own certificate. Add the www subdomain as a CNAME pointing to flash.funnels.msgsndr.com and link it to your funnel.

Why am I getting a 404 page after the domain connects?

A green domain status only means DNS and SSL are working. It doesn’t publish any pages by itself. Go to Sites > Funnels (or Websites), open your target funnel, click Settings, and select your domain from the dropdown list.

Next Steps

With your domain resolving cleanly and an SSL certificate active, you need to verify your funnel step routing and path redirects. Continue with our step-by-step guide on connecting custom domains and subdomains to GoHighLevel funnels.

Official resources

all_in_one_marketing_tool