Custom domain remains Invalid Configuration after DNS propagation

Help
1

Hello,

I am trying to connect the following custom domain to my Vercel project:

The DNS configuration appears to be correct.

DNS records:

CNAME
operaciondespertarmental
→ 2b5eff67ba5bb412.vercel-dns-017.com

Verification steps completed:

  • DNSChecker confirms global propagation.
  • nslookup returns the correct CNAME.
  • More than 15 hours have passed since DNS propagation.
  • I removed and re-added the domain.
  • I created additional test subdomains and they also remain in “Invalid Configuration”.

nslookup output:

operaciondespertarmental.ventasdigi.com canonical name =

2b5eff67ba5bb412.vercel-dns-017.com

Could you please verify if there is any internal validation issue, account conflict, or domain association preventing verification?

Thank you.

image
image1034×529 76.2 KB

image
image1075×400 36.7 KB

image
image1043×515 67.3 KB

image
image1036×520 80.2 KB

Update:

HTTP works correctly:

The landing page loads.

But HTTPS fails:
curl -I https://operaciondespertarmental.ventasdigi.com

Error:
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

So DNS is working, but SSL certificate generation/validation seems to be failing.
Please check the SSL provisioning for this domain.

2

The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points.

You can also use v0 to narrow down the possibilities.

3

Hi Oscar,

Since HTTP loads but HTTPS fails during the TLS handshake, the CNAME is probably reaching Vercel, but certificate provisioning/selection is not completing.

I’d check the DNS records that can specifically block SSL issuance:

dig CNAME operaciondespertarmental.ventasdigi.com +short
dig AAAA operaciondespertarmental.ventasdigi.com +short
dig CAA ventasdigi.com +short
dig CAA operaciondespertarmental.ventasdigi.com +short
dig TXT _acme-challenge.operaciondespertarmental.ventasdigi.com +short

The CNAME should match the value Vercel shows exactly. AAAA should return nothing for a third-party domain pointed to Vercel. If there are CAA records, make sure they allow Let’s Encrypt, because Vercel uses Let’s Encrypt for automatic SSL certificates. Also remove any stale _acme-challenge record from a previous provider if one exists.

You can compare those checks with Vercel’s domain troubleshooting guide here:

One more useful test is:

openssl s_client -connect operaciondespertarmental.ventasdigi.com:443 -servername operaciondespertarmental.ventasdigi.com -brief

If DNS is clean and the SNI test still fails, then the useful info for Vercel is the domain, timestamp, exact dashboard status, and the openssl output. That would point more toward SSL provisioning being stuck than a normal DNS propagation delay.

4

Hello,

I completed all the additional DNS checks.

Results:

  • CNAME is correctly configured:
    operaciondespertarmental → 2b5eff67ba5bb412.vercel-dns-017.com

  • DNS propagation is complete worldwide.

  • No AAAA record exists.

  • No CAA records exist for ventasdigi.com.

  • No _acme-challenge TXT record exists.

  • HTTP loads the application successfully.

  • HTTPS still fails during the TLS handshake.

  • I already removed the ventasdigi.com DNS Zone from my Vercel account as previously instructed and added the custom domain back to the project.

Based on these tests, there doesn’t appear to be any DNS misconfiguration on my side.

Could you please check the backend status of operaciondespertarmental.ventasdigi.com, verify whether SSL provisioning is stuck, and manually trigger a new certificate issuance or clear any cached validation state if necessary?

Thank you very much.

5

Hi Oscar,

Thanks for running all of those checks. With the CNAME resolving to the Vercel target, no AAAA record, no blocking CAA record, HTTP reaching the app, and HTTPS still failing during the TLS handshake, I agree this no longer looks like a normal DNS propagation issue.

One last thing I’d verify is that the authoritative nameservers are definitely the DNS provider where you edited the CNAME, not an old/stale zone:

dig NS ventasdigi.com +short
dig CNAME operaciondespertarmental.ventasdigi.com +short

If those still show the expected provider and Vercel target, then there probably isn’t much more to fix from your side.

For this specific request:

manually trigger a new certificate issuance or clear any cached validation state

That would need someone with Vercel-side visibility. I can’t trigger that from the community, but the details you collected are the right ones to include: the domain, the exact dashboard status, when you re-added it, and the openssl s_client output. Don’t include any private account IDs, tokens, or project secrets.