Verifying a custom domain and activating SSL are separate steps because they answer two different questions: verification proves you control the domain, while SSL activation is a Certificate Authority independently issuing an encryption certificate for it. A content management system (CMS) — the platform that stores and publishes your site, such as WordPress, Webflow, or a hosting layer like Netlify or Firebase — can mark a domain "verified" before HTTPS works, which is why the two statuses often appear minutes or hours apart.
In practice the split is usually sequential and automatic rather than two manual chores. The platform confirms ownership first, then a Certificate Authority re-checks control and issues the certificate — and the second stage cannot start until your DNS points correctly. According to Vercel's domain configuration docs, ownership confirmation precedes certificate issuance for exactly this reason.
Official resources:
- Read Let's Encrypt's ACME challenge types (HTTP-01 vs DNS-01) — See how a Certificate Authority independently re-verifies domain control before issuing a certificate, and why DNS-01 is required for wildcards.
- Check Netlify's HTTPS/SSL provisioning requirements — Confirm that automatic Let's Encrypt certificate issuance is gated on DNS records already pointing at the platform, separate from adding the domain.
Table of Contents
- What verification and SSL activation each prove
- Why DNS is the gate for both
- Why "verified" can show green while HTTPS is still broken
- What to do before pointing production traffic
- Frequently Asked Questions
What verification and SSL activation each prove
Verification answers "do you control this domain?" The platform asks you to add a DNS record or point your domain at its servers, then checks that the record exists. Once it does, the domain is bound to your account and cannot be claimed by someone else. ssl activation answers a stricter question: "should this domain get an encryption certificate?" Here a Certificate Authority — an organization trusted by browsers to vouch for domains, such as the free provider Let's Encrypt — runs its own check.
Per the Let's Encrypt challenge-types documentation, it uses an ACME challenge, either an HTTP-01 token file served at `/.well-known/acme-challenge/<TOKEN>` or a DNS-01 TXT record at `_acme-challenge.<domain>`. Because the CA validates independently, your platform trusting you is not enough. The certificate is only issued after the CA confirms control on its own terms, which is the technical reason the two steps are distinct.
Why DNS is the gate for both
both steps depend on DNS, the system that maps your domain to servers and records. Verification needs a record to read; SSL needs your traffic actually arriving at the platform. If DNS is wrong or incomplete, the certificate simply cannot issue.
Netlify states this plainly: it auto-provisions a Let's Encrypt certificate, but that step "cannot be completed until the DNS records for your custom domain are pointing to Netlify's servers," according to Netlify's HTTPS documentation. Firebase goes further — per Google's Firebase Hosting docs, conflicting A or CNAME records pointing to another provider block certificate provisioning entirely. DNS also explains why platforms favor TXT records for verification. The DNS-01 challenge is the only ACME method that can issue wildcard certificates like `*.example.com` and works without a public web server on port 80, as noted by Let's Encrypt.
Why "verified" can show green while HTTPS is still broken
The gap you notice is timing. Verification reads a record and finishes quickly; certificate issuance is a separate job that runs afterward and can retry for a long time.
A dashboard showing a verified domain is not the same as a working `https://` address. The published timelines make the lag concrete:.
- Firebase: TXT propagation can take up to 24 hours, and SSL provisioning can take up to 24 hours after DNS points correctly — usually faster, per Google's docs.
- Netlify: the certificate step retries every 10 minutes for the first 24 hours, then hourly for two more days, according to Netlify's SSL troubleshooting guide.
- Webflow: it shows a per-domain SSL status — green for active, pending for up to 24 hours after DNS connects — in Publishing → Custom Domains, per the Webflow Help Center.
What to do before pointing production traffic
The safe rule is to wait for the certificate's "active" status, not just verification, before sending live visitors to a custom domain. A cutover that trusts the verified badge alone can serve browser security warnings until HTTPS finishes.
Work through these checks in order: If SSL stays pending well past those windows, the usual cause is DNS, not the platform: a missing record, a conflicting one, or propagation that has not finished. Fix the DNS state and the certificate step will retry on its own schedule.
- Add the exact DNS record the platform specifies, and leave a permanent ownership TXT record in place if required — Firebase needs its TXT record to stay for certificate renewal.
- Remove any conflicting A or CNAME records that point the domain at a different host.
- Confirm the platform's SSL panel reads "active" or green, not "pending," before the switch.
- Allow up to 24 hours for both DNS propagation and certificate issuance, and expect automatic retries rather than instant success.
Frequently Asked Questions
Does verifying my domain automatically turn on HTTPS?
Not instantly. Verification proves ownership, then a Certificate Authority issues the certificate as a separate step that can take up to 24 hours after DNS points correctly.
Why is my domain "verified" but the browser shows an insecure warning?
The certificate has not issued yet. Confirm your DNS points to the platform with no conflicting A or CNAME records, then wait for the SSL status to read active.
Why do platforms ask for a TXT record instead of a file upload?
The DNS-01 TXT challenge works without a public web server on port 80 and is the only method that can issue wildcard certificates like `*.example.com`.
