HTTPS Certificate Domain Validation: HTTP vs DNS Challenges

When you request an HTTPS certificate, the Certificate Authority (CA) won't just take your word for it. It first has to confirm that you actually control the domain. This step is called Domain Control Validation, and there are two mainstream approaches: the HTTP challenge and the DNS challenge. Knowing how they differ helps you pick the right one for each situation and avoid dead ends.

HTTP validation: drop a file on your website

The HTTP challenge is refreshingly simple. The CA hands you a random string, you place it at a specific path on your site (typically http://your-domain/.well-known/acme-challenge/<token>), and the CA fetches that URL over port 80. If it reads back the correct content, you pass.

• Best for: a live site whose domain already resolves to your server and whose port 80 is reachable from the public internet.
• Requirements: DNS is in effect, the firewall allows port 80, and nothing else is squatting on that port.
• Limitations: it won't work if the site isn't online yet or the server isn't publicly exposed — and it cannot issue wildcard certificates.

Issuing with certbot (the --webroot method):

sudo certbot certonly --webroot \
  -w /var/www/html \
  -d example.com -d www.example.com

Here -w points at your web root, and certbot writes the challenge file into .well-known/acme-challenge/.

DNS validation: add a TXT record

The DNS challenge never touches your website. Instead, you add a specific TXT record to the domain's DNS (named like acme-challenge.example.com). The CA looks it up, and if the content matches, you're verified.

• Best for: a site that isn't live yet, a server that isn't publicly exposed, or a wildcard certificate.
• Upside: it doesn't depend on port 80 or on the site being reachable, so even internal services can get a cert.
• Heads-up: DNS changes take time to propagate (governed by TTL), so a manually added record may need a few minutes before it's visible.

Manual DNS validation:

sudo certbot certonly --manual \
  --preferred-challenges dns \
  -d example.com -d www.example.com

certbot pauses and asks you to add a TXT record in your DNS provider's dashboard. Once it has propagated, press Enter to continue.

Wildcard certificates require DNS validation

To issue a wildcard certificate like .example.com, CA rules mandate the DNS challenge — the HTTP challenge is simply not accepted:

sudo certbot certonly --manual \
  --preferred-challenges dns \
  -d "*.example.com" -d example.com

If your DNS provider offers an API, you can install the matching certbot DNS plugin to add the TXT record fully automatically, with no manual steps.

Watch out at renewal time

Certificates are short-lived (often 90 days), so renewal must be automated — otherwise the cert expires and your site starts throwing errors.

• After installation, certbot usually sets up a scheduled job (a systemd timer or cron). Rehearse it first:

  sudo certbot renew --dry-run

• HTTP validation renews silently, as long as port 80 and the web root stay available.
• Manual DNS validation cannot auto-renew — someone has to add a fresh TXT record every time. If you go the DNS route, switch to a DNS plugin (API automation), or you'll be running the command by hand every 90 days.
• After renewal, reload your web server so it picks up the new certificate. Wire this into a deploy hook:

  sudo certbot renew --deploy-hook "systemctl reload nginx"

Summary

• HTTP validation: drop a file, use port 80. Great for a live, publicly reachable site; renews effortlessly, but no wildcards.
• DNS validation: add a TXT record. Ideal for sites that aren't live yet and internal services — and it's the only way to get a wildcard .example.com.
• When using DNS, prefer an API-driven plugin; otherwise you lose automatic renewal.
• Whichever method you choose, verify the renewal path with certbot renew --dry-run and set up a reload hook.