What “Pre-generate SSL certificates” actually does
Vercel’s pre-generation flow stages a Let’s Encrypt certificate against a domain while that domain is still served by a third party, so that the moment you flip the A or CNAME record, HTTPS is already browser-valid. The premise in the Vercel docs is explicit: the domain “should be serving content from 3rd party servers that are unrelated to Vercel.” Validation happens through DNS-01 TXT records, not by pointing the domain at Vercel first. That inverts the usual assumption that the cert comes after cutover.
By default, Vercel does not issue a certificate for a domain until that domain’s DNS records point at Vercel and have propagated, at which point it kicks off the Let’s Encrypt challenge automatically. That is fine for a greenfield domain. The gap it leaves is the migration path: if issuance waits until after the DNS flip, then the longest part of your downtime window is the stretch between “DNS now resolves to Vercel” and “the cert is issued and live.” Pre-generation moves issuance ahead of that window, so the only thing that has to happen at cutover is the DNS change itself.
One constraint is worth stating plainly. The pre-generate button is unavailable the moment any certificate has already been issued for the domain. If a prior project ever auto-issued against the same apex, pre-generation is off the table until that cert is cleared. The domain also has to belong to a team; a personal-scoped domain does not expose the flow.
Dashboard or CLI: how do you actually run it?
Both the Vercel Domains dashboard and the Vercel CLI expose pre-generation, and the CLI splits the operation into two steps so you can stage the challenge before committing.
Through the dashboard, the path is: open the domain management page, scroll to “SSL Certificates,” and click “Pre-generate SSL certificates.” Vercel returns a set of TXT records. You paste them at your registrar, wait for propagation, and click “Verify” to finalize issuance.
The CLI equivalent is a two-command sequence. The first produces the challenge records without issuing anything:
vercel certs issue "*.example.com" example.com --challenge-onlyThe --challenge-only flag is the staging step: it returns the TXT values you need to publish, and it does not request the cert. After the TXT records propagate, re-run the same command without the flag to issue:
vercel certs issue "*.example.com" example.comThe result is a single certificate that covers both the wildcard and the apex form, *.example.com and example.com. That detail matters for operators who were planning to issue separate certs; one issuance covers both.
Whether you use the dashboard or the CLI, the bottleneck is the same: TXT propagation. Vercel’s note is that “DNS records can take time to propagate, so if it doesn’t work immediately, it’s worth waiting.” There is no fast-path around registrar TTLs.
Why DNS-01 and not HTTP-01?
Pre-generation works because Vercel uses the DNS-01 challenge type for this flow, which proves domain control by writing a TXT record rather than serving a file over HTTP.
The HTTP-01 challenge that Vercel uses for non-wildcard domains in the normal path requires the validation request to actually reach Vercel’s infrastructure. That works once the domain resolves to Vercel, but it is impossible while the domain still points at a third party, because the request would land on the third party’s server, not Vercel’s. DNS-01 sidesteps that: the proof of control is a TXT record at the authoritative nameserver, which Let’s Encrypt can check without the apex resolving anywhere in particular.
Per Vercel’s SSL documentation, all certificates are issued through Let’s Encrypt. Non-wildcard domains use HTTP-01; wildcard domains use DNS-01. The same page explains the nameserver coupling that follows from that split.
There is a related constraint that bites people doing HTTP-01 elsewhere: the /.well-known path is reserved on Vercel and cannot be redirected or rewritten. Anyone who tried to front Vercel with a custom HTTP-01 handler on that path would find it blocked. Only Enterprise teams can configure custom SSL at all.
Why does the wildcard catch you?
Wildcard domains on Vercel require the nameservers to live with Vercel, because DNS-01 for a wildcard means Vercel has to write the validation record itself, not just read it.
The working-with-domains doc states that wildcard domains “must be configured with the nameservers method.” The reason is in the SSL doc: to solve the ownership challenge for a wildcard, Vercel requires nameservers to be with Vercel, because if the DNS is not with Vercel it “can’t make the DNS record to approve it.” For a pre-generation flow that covers *.example.com, this is the constraint that matters. You cannot pre-generate a wildcard cert against a domain whose DNS is still hosted at a third-party registrar, because Vercel has no way to publish the TXT record for the DNS-01 validation.
This is where the zero-downtime framing starts to fray. A plain apex migration can be staged entirely behind a third party. A wildcard migration may require moving the nameserver first, which is a more visible change than flipping an A record and which some registrars process slowly.
The constraint is not Vercel lock-in, despite how it reads. It is an ACME / Let’s Encrypt property. Traefik’s ACME documentation states the same thing independently: “Wildcard certificates can only be verified through a DNS-01 challenge.” Any provider that offers wildcard TLS through Let’s Encrypt hits the same wall. What differs is who owns the DNS-01 automation. Vercel’s position is that it owns it, so the nameservers must be Vercel’s. A self-hosted setup with acme.sh or Certbot and a DNS API plugin can keep the nameserver anywhere, at the cost of running that automation yourself.
How do you verify the cert before flipping DNS?
Run a curl that sends the request directly to Vercel’s edge, ignoring the domain’s current DNS, and confirm the TLS handshake succeeds.
The pre-generate doc gives the exact command:
curl https://example.com --resolve example.com:443:76.76.21.21 -IThe --resolve flag forces curl to connect to 76.76.21.21 for example.com:443, regardless of what the domain’s actual A record says. Because TLS carries the hostname in the handshake, Vercel’s edge presents the staged certificate and curl validates it as if the domain already resolved there. A successful response means the cert is live in Vercel’s infrastructure and browser-trustable, and at that point it is safe to change the A or CNAME record at the registrar.
This is the single most useful step in the flow, and it is the one most operators skip. It collapses the “did the cert actually issue correctly” question into a deterministic check before any production traffic is at risk. The flip itself is then left with one failure mode: DNS propagation speed, not certificate correctness.
What does pre-generation change about migration risk?
Pre-generation removes TLS issuance from the cutover-critical path, but it does not remove the assumptions baked into Vercel’s default SSL model, and it changes who needs what access at what time.
Compared to providers that validate ownership only at cutover, the operator trade is: do the validation work earlier, against a domain still in production, in exchange for a shorter cutover window. The cost is that pre-generation requires registrar-level DNS access before cutover, the ability to publish arbitrary TXT records, and either a non-wildcard target or a nameserver already on Vercel. A team whose registrar access is gated by a change-advisory process will find that the pre-generation step inherits that gate, just earlier in the timeline.
There is also a subtle change to the blast radius. With cutover-time validation, a failed ownership challenge happens during the migration and is immediately visible. With pre-generation, the challenge happens ahead of time, which is the point, but it also means the cert is staged and waiting. If anything about the staged cert is wrong, the curl test is the only thing standing between you and a bad cutover. The discipline of running it, not just having the option, is what makes the flow safe.
How does this compare to Cloudflare and standard ACME flows?
Vercel’s pre-generation is a managed convenience over the same DNS-01 mechanism that Cloudflare, Traefik, and self-hosted ACME clients use; the differentiator is the dashboard two-step and the curl check, not the cryptography.
The wildcard-needs-nameserver constraint is the same across managed platforms, because they all issue through Let’s Encrypt and all hit the DNS-01-only rule for wildcards. What Vercel adds is the staged-but-not-yet-serving posture: the cert is issued while traffic still hits a third party, and a verification curl pointed at a known Vercel IP confirms it before the flip. What Vercel removes is the operator’s freedom to keep the nameserver elsewhere for wildcard certs, because Vercel’s DNS-01 automation runs only against Vercel-held DNS.
For a team already standardized on Vercel for hosting, the pre-generation flow is the right tool, and the curl test alone justifies knowing it exists. For a team that needs wildcards across providers and wants to keep DNS at a third party, the same ACME constraint means none of those providers offer an easier path, only a different one.
Frequently Asked Questions
Can you upload your own certificate instead of using pre-generation?
Only Vercel Enterprise teams can configure custom SSL uploads. Hobby and Pro accounts are bound to Let’s Encrypt certificates that Vercel issues and rotates automatically, which makes pre-generation the only mechanism a non-Enterprise team has to control when a cert is issued relative to cutover.
What separates the —challenge-only flag from the full issue command, and why does the split matter?
The —challenge-only flag decouples TXT publication from cert issuance, so an operator can confirm the TXT records have propagated at the registrar before requesting the cert. Without that split, a failed DNS-01 challenge would consume an issuance attempt against Let’s Encrypt’s rate limits (five duplicate certs per week per registered domain) and force a wait.
Do you need to whitelist Let’s Encrypt in CAA records for pre-generation to work?
Vercel issues all certificates through Let’s Encrypt, so if your domain has a restrictive CAA record set (a common hardening step), it must include the letsencrypt.org issue record or issuance will fail. Pre-generation surfaces this CAA check earlier in your timeline, exposing a misconfiguration that would otherwise have appeared as a failed auto-issuance at cutover.
Why does Vercel require its own nameservers for wildcard certs when Certbot does not?
Vercel’s DNS-01 automation only writes to DNS it controls, so it cannot publish the _acme-challenge TXT against a third-party registrar. Certbot and acme.sh instead use a DNS provider API credential (Route53, Cloudflare, DigitalOcean) that you store in plaintext or a secrets manager, taking on the token storage and rotation burden in exchange for keeping the nameserver anywhere you like.
Is the wildcard nameserver requirement likely to change?
No, because it is not a Vercel product decision but an ACME protocol property: Let’s Encrypt only permits DNS-01 challenges for wildcards. Vercel could in principle add DNS API integrations like Certbot’s plugins to relax the nameserver requirement, but that would mean storing and rotating third-party DNS credentials, which it has chosen not to do.
