That is the failure mode worth taking seriously. Not slowness, not downtime — the CDN cached a page that was personalised for one user and served it to everybody else. And you will not notice, because your browser holds a session and looks fine. The people seeing the broken version are the ones who never contact you.

Getting CDN setup right for a dynamic site is not about finding the right toggle in a dashboard. It is about deciding, per route, what is public and what is personal, and then making the origin say so clearly enough that no edge node has to guess.

Sort your routes before touching any config

Every URL on your site falls into one of three buckets. Write the list out — actually write it, this takes ten minutes and prevents the incident above.

• Static assets. CSS, JS, images, fonts. Identical for everyone, content-addressed if your build is sensible. Cache these hard, for a year.
• Public dynamic. Generated by the application but identical for every anonymous visitor. Blog posts, product pages, category listings. This is where the real performance win lives, and where most people leave everything uncached out of nervousness.
• Private dynamic. Anything personalised or authenticated. Carts, dashboards, checkout, admin, most API responses. Never cached at a shared cache, no exceptions.

The middle bucket is the whole game. If you cache only the first bucket you have built an asset CDN and left the expensive work untouched. If you accidentally cache the third, you have a data leak.

The header that separates the buckets

The single most useful thing to understand is the difference between private and no-store, because people use them interchangeably and they mean very different things.

# Static assets with a content hash in the filename
Cache-Control: public, max-age=31536000, immutable

# Public dynamic: edge caches it, browser revalidates
Cache-Control: public, s-maxage=300, max-age=0, must-revalidate

# Personalised: browser may cache, shared caches must not
Cache-Control: private, no-store

# Genuinely sensitive: nobody stores this anywhere
Cache-Control: no-store

private means “a browser cache may keep this, a shared cache may not”. no-store means “do not write this to disk anywhere”. For an authenticated dashboard you want both. For a bank statement you want no-store alone.

The other key pair is s-maxage versus max-age. s-maxage applies only to shared caches — the CDN — and overrides max-age there. That lets you cache a product page at the edge for five minutes while telling browsers to revalidate every time, so a price change propagates in five minutes rather than living in someone’s browser for an hour.

Set caching headers at the origin, per route, and let the CDN follow them. Configuring cache rules only in the CDN dashboard means the policy lives somewhere your application code cannot see and your staging environment does not have.

Vary, and how it quietly ruins your hit rate

Vary tells caches that the response depends on a request header, so a separate copy is stored per distinct value. Used precisely it is essential. Used carelessly it destroys your cache.

# Fine. A handful of encodings, a handful of variants.
Vary: Accept-Encoding

# Also fine if you genuinely serve different content per language
Vary: Accept-Encoding, Accept-Language

Now the one to avoid:

# Effectively disables caching. Every browser build is a distinct
# User-Agent string, so every visitor gets their own cache entry.
Vary: User-Agent

If you need device-specific responses, most CDNs expose a normalised device-type value with two or three possible values. Use that rather than the raw header.

Vary: Cookie deserves its own warning. It looks like a safe way to separate logged-in from anonymous traffic, and it is not — every visitor carries slightly different cookies from analytics and consent tools, so you get a near-unique cache key per person. The correct approach is to make the presence of a session cookie bypass the cache entirely, rather than varying on it.

Cookies are where sites actually break

Two rules, and between them they prevent most CDN incidents.

Rule one: a session cookie means bypass

If a request arrives carrying your session cookie, it should go to origin uncached. Most CDNs let you express this as a cache rule; in nginx, if you are running your own edge, it is a variable:

map $http_cookie $bypass_cache {
    default                 0;
    "~*wordpress_logged_in" 1;
    "~*woocommerce_items"   1;
    "~*comment_author"      1;
    "~*PHPSESSID"           1;
}

location / {
    proxy_cache            edge_cache;
    proxy_cache_bypass     $bypass_cache;   # do not serve from cache
    proxy_no_cache         $bypass_cache;   # do not write to cache
    proxy_cache_valid      200 301 302 5m;
    proxy_cache_use_stale  error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_lock       on;

    add_header X-Cache-Status $upstream_cache_status always;
    proxy_pass http://origin;
}

You need both directives. proxy_cache_bypass stops a logged-in user being served a cached anonymous page. proxy_no_cache stops their personalised response being written into the cache for everyone else. Setting only the first is a common and dangerous mistake — the read path is protected while the write path is wide open.

That X-Cache-Status header is not decoration. It is how you verify any of this actually works.

Rule two: strip cookies you do not need

Analytics and consent tools set cookies on every visitor. If your CDN treats any cookie as a bypass signal, your anonymous traffic stops being cacheable the moment you add a tag manager. Configure the CDN to ignore everything except the specific cookies that matter, and be explicit about which those are.

Query strings, and the cache-key explosion

By default many CDNs include the full query string in the cache key. Then a marketing campaign starts appending utm_source, utm_medium, fbclid and friends, and one page becomes thousands of cache entries that each miss exactly once.

Decide deliberately which parameters affect the response:

• Include parameters that change the content — ?page=2, ?sort=price, ?category=boots.
• Ignore tracking parameters entirely. They never change what the server renders.
• Normalise order where the CDN supports it, so ?a=1&b=2 and ?b=2&a=1 are one entry rather than two.

An allowlist is safer than a blocklist here. New tracking parameters appear constantly; the set of parameters your application actually reads changes rarely.

Keeping dynamic pages cached without going stale

The usual objection to caching public dynamic pages is that content changes. Two mechanisms solve this, and together they let you cache aggressively without serving stale content for long.

Stale-while-revalidate

Cache-Control: public, s-maxage=60, stale-while-revalidate=600, stale-if-error=86400

Read that as three separate promises. Fresh for sixty seconds. For the following ten minutes, serve the stale copy immediately while fetching a fresh one in the background — so nobody waits. And if the origin is throwing errors, keep serving the stale copy for a day rather than showing a 502.

That last directive turns your CDN into a partial outage shield. It is one of the highest-value headers on this page and it costs nothing.

Purge on change

Time-based expiry is a blunt instrument. If your application knows when a product price changed, tell the CDN immediately rather than waiting for a TTL.

Tag-based purging is the version worth building toward — tag responses by the entities they contain, then purge by tag when an entity changes:

# Origin response for a product page
Cache-Tag: product-1234, category-boots, layout-main

Update product 1234 and you purge one tag, invalidating the product page, every category listing it appears on, and the homepage if it is featured — without knowing any of those URLs in advance. Header name and support vary by provider, so check what yours calls it.

Verifying it before you point DNS

Test with curl, not a browser. Your browser has cookies, a warm local cache and an opinion; curl tells you the truth.

# What headers is the origin actually sending?
curl -sI https://example.com/products/boots | grep -i 'cache-control|vary|set-cookie'

# Twice in a row: second request should show a HIT
curl -sI https://example.com/products/boots | grep -i 'x-cache|age'
curl -sI https://example.com/products/boots | grep -i 'x-cache|age'

Now the test that matters most. Request an authenticated page with a real session cookie and confirm it never returns a cache hit:

curl -sI https://example.com/account 
  -H "Cookie: session=<a-real-session-value>" 
  | grep -i 'x-cache|cache-control'

You want BYPASS or MISS, and Cache-Control: private. If that ever shows HIT, stop and fix it before going further.

The leak test, which is the one people skip: fetch a personalised page with a session, then fetch the same URL with no cookies at all and confirm you get the anonymous version.

# With a session
curl -s https://example.com/account -H "Cookie: session=<value>" | grep -i 'welcome back'

# Immediately after, with nothing. Should NOT show the personalised content.
curl -s https://example.com/account | grep -i 'welcome back'

If the second command finds personalised content, the CDN cached a private response. That is the Monday-morning email, and you have just caught it before your customers did.

Test the edge before DNS points at it

curl -sI https://example.com/ --resolve example.com:443:<edge-ip>

That sends a real request to a specific edge node with the correct hostname and TLS SNI, without changing DNS. It is how you find out whether the whole thing works before any user does.

Things that break in ways nobody expects

Client IPs all become the CDN’s

Your logs fill with edge node addresses, rate limiting starts throttling everyone at once, and geolocation breaks. The real address arrives in a forwarded header, and your origin has to be configured to trust it — but only from the CDN’s address ranges. Trusting X-Forwarded-For from anywhere lets any visitor claim any IP they like, which turns a logging annoyance into an authentication bypass.

Redirect loops

The CDN talks to your origin over HTTP, the origin sees a non-HTTPS request and redirects to HTTPS, which comes back through the CDN, forever. Either terminate TLS at the origin too, or have the origin trust X-Forwarded-Proto when deciding whether to redirect.

POST responses getting cached

Shouldn’t happen by default, but a badly written cache rule can do it, and the result is one user’s form submission response served to the next person. Only cache GET and HEAD. Ever.

Websockets and streaming

Websocket upgrades and server-sent events need to pass through untouched. Buffering breaks streaming responses silently — the connection works, the data just arrives in one lump at the end, which looks like an application bug rather than a proxy setting.

Set-Cookie on a cacheable response

If a public page returns Set-Cookie and gets cached, every subsequent visitor receives that cookie — potentially somebody’s session identifier. Most CDNs refuse to cache responses carrying Set-Cookie, but not all, and not always. Check your origin is not setting cookies on pages you intend to cache.

Rolling it out without a bad week

1. Write down the route list. Three buckets, every path accounted for.
2. Set headers at the origin first, with the CDN not yet in front. Verify with curl.
3. Start with everything bypassed except static assets. A CDN that caches nothing still terminates TLS closer to users and is not a failure.
4. Add public dynamic routes one at a time, with short TTLs. Sixty seconds, then extend once you trust it.
5. Run the leak test after every rule change, not just at the end.
6. Watch origin request volume. It should drop noticeably. If it does not, something is bypassing that you think is caching.
7. Keep a purge command to hand and know how long a full purge takes before you need it.

Common mistakes

• Testing only in a logged-in browser, where cached-private-content bugs are invisible.
• Setting proxy_cache_bypass without proxy_no_cache, protecting reads but not writes.
• Vary: Cookie or Vary: User-Agent, which shatters the cache into near-unique entries.
• Leaving tracking parameters in the cache key.
• Configuring caching in the CDN dashboard only, so the policy is invisible to your code and absent from staging.
• Trusting forwarded IP headers from any source rather than only the CDN’s ranges.
• Using private where you needed no-store, or the reverse.
• Caching everything on day one and finding the problems in production.

Best practices

• Default to no caching, then allow specific routes. Opt-in beats opt-out when the failure mode is a data leak.
• Own the policy at the origin so it travels with your code and exists in staging.
• Use s-maxage for the edge and max-age for browsers. They are different problems.
• Always set stale-if-error. It is free outage insurance.
• Expose a cache status header and monitor hit ratio per route, not site-wide.
• Build purge-on-publish into the application rather than relying on TTLs alone.
• Make the leak test part of CI, so a future config change cannot reintroduce it quietly.

Frequently asked questions

Can a CDN cache dynamic pages at all?

Yes, and that is where most of the benefit is. Dynamic does not mean personalised. A blog post rendered from a database is identical for every anonymous visitor and can be cached at the edge for minutes. Only genuinely per-user content must bypass.

What is the difference between private and no-store?

private permits browser caching but forbids shared caches. no-store forbids writing the response to any cache at all. Use both for authenticated pages; use no-store alone for genuinely sensitive responses.

Why did my hit ratio collapse after adding a cookie banner?

Because the consent tool sets a cookie on every visitor and your CDN treats any cookie as a bypass signal, or you are varying on Cookie. Configure the CDN to ignore all cookies except the specific ones that indicate a session.

How do I verify private pages are not being cached?

Request the page with a real session cookie and confirm the cache status shows a bypass or miss, never a hit. Then request the same URL with no cookies and confirm the personalised content is absent. Do this after every cache rule change.

Should I cache API responses?

Public read-only endpoints, yes — with short TTLs and a cache key that includes whatever parameters affect the response. Anything requiring an Authorization header should be treated as private by default.

Do I still need caching at the origin?

Yes. The CDN protects you from repeat requests for the same URL; it does nothing for the first request, for uncacheable routes, or during a purge. Origin-level caching handles those.

Wrapping up

A CDN in front of a dynamic site is a classification problem wearing a performance costume. Sort your routes into public, private and static; express that at the origin with Cache-Control; make session cookies a hard bypass on both the read and write path; and keep tracking parameters out of the cache key.

Then test the way an anonymous visitor arrives, not the way you browse your own site. Two curl commands — one with a session, one without — catch the failure that matters, and they take about ten seconds. Run them every time you change a cache rule and the Monday email never arrives.

Want a CDN set up without the surprises?

I work with teams on edge caching for dynamic sites — route classification, cache headers that survive a redesign, purge-on-publish wired into the application, and the monitoring that tells you when hit ratio quietly drops.

If you would rather have this done carefully the first time, you can hire me on Upwork.

The post CDN Setup Without Breaking Dynamic Content appeared first on John Nessime.

Nearly every TLS certificate error I have had to chase down comes back to one of three things: the chain your server sends is incomplete, the certificate does not actually cover the hostname being requested, or it expired and no alert fired. This article walks through all three — how to identify which one you are looking at, the exact commands to prove it, and how to set up renewal automation so the third category stops being a category at all.

Why TLS certificate errors are so confusing to debug

Two things conspire to make this harder than it should be.

The first is that browsers are forgiving in ways other clients are not. When a server sends an incomplete certificate chain, most modern browsers will quietly fetch the missing intermediate using the Authority Information Access extension embedded in the certificate. They fix your misconfiguration on the fly and show you a padlock. Meanwhile curl, Python’s requests, Java clients, Go services, and older Android devices do no such thing. They fail. This is why “it works in Chrome” is worth almost nothing as a diagnostic signal.

The second is that error messages describe the symptom rather than the cause. “Unable to get local issuer certificate” sounds like a client problem. It usually is not — it usually means your server is not sending the full chain. Learning to translate the message into the actual failure is most of the work.

One command that tells you almost everything

Before touching config files, look at what the server is actually sending on the wire:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

The -servername flag matters more than people expect. It sets SNI, and without it you may be handed the server’s default certificate rather than the one for the domain you care about. Plenty of confusing “the certificate is for the wrong domain” reports come from testing without SNI.

Three parts of the output are worth reading carefully:

• The “Certificate chain” block near the top, listing each certificate the server sent with its subject and issuer.
• The “Verify return code” at the bottom. 0 (ok) is what you want. 20 and 21 both point at chain problems.
• The subject line of the first certificate, which tells you whether you even got the certificate you expected.

If you want the certificate details without the chain noise, pipe it into x509:

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

That single line answers “who issued it”, “when does it expire”, and “what hostnames does it cover” in one shot. It is the first thing I run.

Family one: certificate chain issues

A publicly trusted certificate is almost never signed directly by a root. There is at least one intermediate CA in between. The client already trusts the root — it ships in the operating system or browser trust store — but it has no idea about the intermediate unless you hand it over. Your server’s job is to send the leaf certificate plus every intermediate needed to walk up to a trusted root.

The classic mistake: serving the leaf without the intermediates

If you use Let’s Encrypt, certbot writes several files into /etc/letsencrypt/live/example.com/. Two of them look interchangeable and are not:

• cert.pem — the leaf certificate on its own.
• fullchain.pem — the leaf plus the intermediates.
• chain.pem — the intermediates on their own.
• privkey.pem — the private key.

Nginx wants fullchain.pem. Point it at cert.pem and browsers will still work, so the mistake survives testing and surfaces weeks later when an API client fails.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

On Apache 2.4.8 and later, SSLCertificateFile can hold the leaf and the intermediates concatenated together, and SSLCertificateChainFile is deprecated. If you inherited a config that still uses the old directive, it will work, but it is worth cleaning up:

SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Wrong order, or a root that should not be there

Order is part of the specification, not a suggestion. The leaf comes first, then each issuer in sequence walking upward. Some clients tolerate a shuffled bundle; several do not, and the ones that do not tend to be the ones you find out about from an angry customer.

Including the root certificate at the end is a different case: it is harmless from a trust perspective, since the client ignores it and uses its own copy, but it adds bytes to every single handshake for no benefit. Leave it out.

Verifying a chain offline

You can check a bundle before deploying it, which is far better than discovering the problem in production:

# Does the leaf verify against the intermediates you plan to serve?
openssl verify -untrusted chain.pem cert.pem

# Print the subject and issuer of every certificate in a bundle, in order
openssl crl2pkcs7 -nocrl -certfile fullchain.pem 
  | openssl pkcs7 -print_certs -noout

That second command is the one I reach for most. Read the output top to bottom: the issuer of each certificate should be the subject of the next one down. The moment that pattern breaks, you have found your gap.

The key and the certificate do not match

Less common, but it produces a spectacularly unhelpful error. After a renewal where files were copied around by hand, confirm the pair still belongs together — the two hashes must be identical:

openssl x509 -noout -modulus -in cert.pem | openssl md5
openssl rsa  -noout -modulus -in privkey.pem | openssl md5

Family two: SAN mismatches

The Common Name field is dead. It has been deprecated for hostname matching for years, and Chrome stopped honouring it entirely back in 2017. What matters now is the Subject Alternative Name extension. If the hostname a client requested is not in the SAN list, the connection fails, regardless of what the CN says.

Check what a certificate actually covers:

# From a file
openssl x509 -noout -ext subjectAltName -in cert.pem

# From a live server
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName

The four SAN mistakes that keep recurring

• Apex without www, or www without apex. These are two distinct names. A certificate for example.com does not cover www.example.com. Both need to be in the SAN list, and both need to be passed to certbot with separate -d flags.
• Assuming a wildcard covers everything. It does not. *.example.com matches exactly one label. It covers api.example.com. It does not cover example.com itself, and it does not cover staging.api.example.com. Multi-level subdomains need their own wildcard or their own entry.
• A new subdomain that never made it into the renewal. You add metrics.example.com to nginx, point DNS at it, and forget that the certificate was issued for a fixed list of names. Adding a name means reissuing, not just reloading.
• Connecting by IP address. Almost no public certificate includes an IP SAN, so hitting the server by IP will always fail hostname verification. That is expected behaviour, not a broken certificate.

One more that catches people out: if you use Cloudflare in proxied mode, the certificate a visitor sees is Cloudflare’s edge certificate, not yours. Debugging the origin means bypassing the proxy and testing the origin IP directly with the Host header set correctly, or temporarily turning the orange cloud grey.

Family three: expiry, and why automation is no longer optional

Expiry used to be a calendar problem. You bought a certificate for a year, set a reminder, and dealt with it once. That era is closing.

In April 2025 the CA/Browser Forum passed ballot SC-081v3, which phases the maximum validity period for publicly trusted TLS certificates down from 398 days to 47 days. The schedule runs in three steps: 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. The first phase is already in force. Domain validation reuse windows shrink alongside it.

The 47-day target was chosen deliberately: short enough that manual renewal stops being viable at any meaningful scale. Automation is the point of the change, not a side effect of it.

If you run a handful of domains, this is a nuisance. If you run fifty, manual renewal is already finished as a strategy.

Getting ACME renewal right

Certbot installs a systemd timer or cron entry that attempts renewal twice a day and does nothing unless the certificate is close to expiry. Confirm it is actually there:

systemctl list-timers | grep certbot
certbot renew --dry-run

The dry run exercises the whole path against the staging environment without touching rate limits. Run it after any change to your web server config, not just after installing certbot. A renewal that worked last quarter can break because someone added a redirect that intercepts the ACME challenge path.

The trap: renewal succeeds, the site still serves the old certificate

This is the failure I see most often, and it is genuinely maddening because every log says success. Certbot writes the new certificate to disk. Nginx has the old one loaded in memory and keeps serving it until it is told otherwise. The certificate on disk is valid, the certificate on the wire is expired, and everything looks fine from the server’s point of view.

The fix is a deploy hook, which runs only when a certificate was actually renewed:

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

Better still, make it permanent by adding it to the renewal configuration at /etc/letsencrypt/renewal/example.com.conf, under the [renewalparams] section, so it survives however the renewal happens to be triggered:

renew_hook = systemctl reload nginx

Use reload rather than restart. A reload picks up the new certificate without dropping connections.

Remember that anything else terminating TLS needs the same treatment. A mail server, a database proxy, a Docker container with the certificate baked into its image — each one needs its own reload step, and containers in particular will happily run for months with an expired certificate mounted from the host.

Wildcards need DNS-01

Wildcard certificates cannot be issued through HTTP-01 validation. They require DNS-01, which means certbot needs to create a TXT record on your domain, which means API credentials for your DNS provider. Use a provider plugin rather than the manual mode — manual DNS-01 cannot be automated, and an unautomated wildcard on a 47-day cycle is an outage with a scheduled start time.

If issuance fails outright with a policy error, check your CAA records before assuming the ACME client is broken. A CAA record that names a different CA will block issuance entirely:

dig CAA example.com +short

Monitor from outside, not from the server

Checking the certificate file on disk tells you what should be served. Only an external check tells you what is being served. Given the reload trap above, that difference is the entire point.

A minimal check that works anywhere:

#!/usr/bin/env bash
# Usage: ./cert-days.sh example.com
# Exits non-zero if fewer than 21 days remain.
set -euo pipefail

DOMAIN="$1"
THRESHOLD=21

END=$(echo | openssl s_client -connect "${DOMAIN}:443" -servername "${DOMAIN}" 2>/dev/null 
      | openssl x509 -noout -enddate | cut -d= -f2)

DAYS=$(( ( $(date -d "${END}" +%s) - $(date +%s) ) / 86400 ))
echo "${DOMAIN}: ${DAYS} days remaining (expires ${END})"

[ "${DAYS}" -lt "${THRESHOLD}" ] && exit 1
exit 0

If you already run Prometheus, the blackbox exporter gives you this for free through the probe_ssl_earliest_cert_expiry metric. An alert rule looks like this:

groups:
  - name: tls
    rules:
      - alert: TLSCertificateExpiringSoon
        expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 21
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "TLS certificate expiring in under 21 days"

Set the threshold well above your renewal window. With 200-day certificates renewing at 30 days remaining, a 21-day alert gives you nine days of warning that something in the pipeline broke. Once 47-day certificates arrive, those numbers compress hard, and an alert that fires too late is the same as no alert.

A workflow for diagnosing TLS certificate errors

When something breaks, work through it in this order. It takes about a minute and rules out whole families of causes as you go.

1. Reproduce outside the browser. Use curl -v or openssl s_client. If the browser works and curl does not, you are almost certainly looking at a chain problem.
2. Read the verify return code. Code 20 or 21 means a chain issue. A hostname mismatch message means a SAN issue. A date error means expiry — or a wrong system clock on the client.
3. Print the dates. Rules expiry in or out in one command, and tells you whether the certificate on the wire matches the one on disk.
4. Print the SANs. Confirm the exact hostname being requested appears in the list. Watch for apex versus www.
5. Walk the chain. Each certificate’s issuer should be the next one’s subject. Find where the sequence breaks.
6. Compare disk against wire. If the file is newer than what is being served, you have a reload problem, not a certificate problem.
7. Check the client’s trust store. If everything above is clean and one specific client still fails, the problem has moved to their end — an old Android device, a Java service with its own cacerts, or a container image built on a base with a stale CA bundle.

Common mistakes worth avoiding

• Testing only in a browser, and mistaking its silent chain repair for a working configuration.
• Pointing the web server at cert.pem instead of fullchain.pem.
• Renewing without reloading the service that holds the certificate in memory.
• Running certbot renew on a schedule but never running --dry-run after config changes.
• Copying key and certificate files between servers by hand and losing track of which pair belongs together.
• Monitoring the file on disk rather than the certificate actually being served.
• Forgetting that mail servers, load balancers, and containers terminate TLS too, and need their own renewal path.
• Adding a subdomain to the web server config and assuming the existing certificate covers it.

Best practices that hold up over time

• Automate issuance and renewal from day one, even for a single domain. The habit matters more than the scale.
• Always use a deploy hook, and always reload rather than restart.
• Alert on days remaining, measured externally, with a threshold at least twice your renewal window.
• Keep an inventory of every hostname you hold a certificate for. You cannot monitor what you have forgotten about.
• Prefer DNS-01 with a provider plugin if you need wildcards, and never rely on manual DNS validation.
• Set CAA records deliberately so you know which CAs are permitted to issue for your domain.
• Test with a non-browser client before calling a certificate deployment finished.

Frequently asked questions

Why does my site work in Chrome but fail in curl?

Almost always an incomplete chain. Browsers fetch missing intermediate certificates automatically using the Authority Information Access extension; curl does not. Point your web server at the full chain file rather than the leaf certificate and both will work.

What does “unable to get local issuer certificate” actually mean?

The client could not build a path from your certificate to a root it trusts. Nine times out of ten the server is not sending its intermediates. Occasionally the client’s own CA bundle is out of date, which is common in older container base images.

Does a wildcard certificate cover the root domain?

No. *.example.com matches a single label, so it covers www.example.com but not example.com and not a.b.example.com. Include the apex explicitly as an additional SAN entry when you request the certificate.

My certificate renewed but the site still shows it as expired. Why?

The service holding the certificate has not reloaded. The new file is on disk; the old one is still in memory. Add a deploy hook that reloads the service on renewal, then verify from outside with openssl s_client rather than trusting the file timestamp.

How short will certificate lifetimes actually get?

Under the CA/Browser Forum schedule, 200 days applies from March 2026, 100 days from March 2027, and 47 days from March 2029. Private and internal CAs are not bound by these rules, but public certificates are.

Is the Common Name field still used at all?

Not for hostname validation. Modern clients read only the Subject Alternative Name extension. A certificate whose CN matches but whose SAN list does not include the hostname will be rejected.

Wrapping up

TLS certificate errors feel opaque mostly because the error text points at the wrong layer. Once you sort them into chain, SAN, or expiry, each one has a short diagnostic path and an obvious fix. Get comfortable with openssl s_client and openssl x509 and you will resolve most incidents faster than it takes to find the right dashboard.

The expiry category is the one worth engineering away permanently. With maximum lifetimes dropping toward 47 days, any process that depends on a person remembering something will fail eventually. Automate the renewal, add the deploy hook, and alert on what is actually being served rather than what is sitting on disk. Do that once and TLS certificate errors go back to being a rare curiosity instead of a recurring outage.

Need help with TLS, certificates, or infrastructure automation?

I work with teams on exactly this kind of problem — broken certificate chains, ACME automation across multiple servers, expiry monitoring wired into Prometheus and Grafana, and the wider DevOps plumbing that keeps it all running quietly in the background.

If you would rather hand this off than debug it at two in the morning, you can hire me on Upwork.

The post TLS Certificate Errors: Chain Issues, SANs, and Expiry Automation appeared first on John Nessime.

It usually is. Not because DNS is fragile, but because it’s the one layer where caching, delegation, and propagation all conspire to make the same domain behave differently depending on who’s asking and when. A record can be perfectly correct in your control panel and still resolve to the wrong IP for half the internet.

This article is the DNS troubleshooting workflow I actually use — the order of checks, the commands worth memorising, how to read what they tell you, and the specific failure patterns that show up over and over. No theory dumps. Just the path from “something’s broken” to “here’s exactly which record on which server is wrong.”

First, Get the Mental Model Right

You can’t debug a system you don’t have a picture of. When a browser resolves example.com, several independent parties are involved, and any one of them can be the liar:

1. The application — browsers keep their own short-lived DNS cache, and HSTS or connection pooling can mask changes entirely.
2. The operating system — the local stub resolver, /etc/hosts, nscd, systemd-resolved, or the Windows DNS Client service.
3. The recursive resolver — your router, your ISP, or a public resolver like 1.1.1.1 or 8.8.8.8. This is where most stale answers live.
4. The delegation chain — root servers, then the TLD servers, then whichever name servers your registrar says are authoritative.
5. The authoritative name server — the only place where the truth actually lives.

Effective DNS troubleshooting is just working down that list and asking each party the same question directly, instead of trusting whatever the browser tells you. The moment you find two parties giving different answers, you’ve found your boundary — and the problem is between them.

The Tools That Matter

You need surprisingly few. My honest ranking:

dig — the one you should learn properly

dig is the only tool that shows you everything: the query it sent, the response status, the TTL remaining, the authority section, and whether the answer came from a cache or from the source. On Debian and Ubuntu it lives in dnsutils; on RHEL-family systems it’s in bind-utils.

# Just the answer, nothing else
dig +short example.com A

# The full picture — status, flags, TTL, authority
dig example.com A

# Ask one specific resolver instead of the system default
dig @1.1.1.1 example.com A

# Ask a specific authoritative server directly
dig @ns1.example-dns.com example.com A

host — for quick sanity checks

host example.com
host -t MX example.com
host -t TXT example.com

nslookup — fine, but know its limits

nslookup is everywhere, including Windows, which is its main virtue. But it hides details you often need, and its “Non-authoritative answer” banner confuses people constantly — it simply means the answer came from a cache rather than the authoritative server. That’s completely normal. On Windows I reach for PowerShell instead:

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Server 1.1.1.1

resolvectl — essential on modern Linux

If the machine runs systemd-resolved, your /etc/resolv.conf probably points at 127.0.0.53, which tells you nothing about the real upstream servers. resolvectl does:

resolvectl status
resolvectl query example.com
resolvectl statistics

getent — the reality check

dig talks to DNS. Your applications talk to the C library resolver, which also consults /etc/hosts and whatever else /etc/nsswitch.conf lists. When dig and the application disagree, this is the command that explains why:

getent hosts example.com
getent ahosts example.com

A Repeatable DNS Troubleshooting Workflow

This is the sequence. Don’t skip ahead — each step eliminates a whole class of causes, and jumping straight to the authoritative server is how you spend an hour fixing something that was never broken.

Step 1 — Confirm it’s actually DNS

Resolve the name, then connect to the resulting IP directly. If the IP works and the name doesn’t, it’s DNS. If neither works, you’re troubleshooting the wrong layer.

dig +short example.com A
curl -I --resolve example.com:443:203.0.113.10 https://example.com/

The --resolve flag is underrated. It forces curl to use an IP you specify while still sending the correct Host header and SNI, which lets you test the web server as if DNS were already fixed. Replace 203.0.113.10 with the IP you expect.

Step 2 — Compare local vs public resolvers

dig +short example.com A
dig +short @1.1.1.1 example.com A
dig +short @8.8.8.8 example.com A
dig +short @9.9.9.9 example.com A

If your local answer differs from all three public resolvers, the problem is on your side — a cache, a hosts file entry, a VPN pushing internal DNS, or a router doing something creative. If all four agree but the answer is wrong, the problem is upstream at the authoritative layer.

Step 3 — Find out who is actually authoritative

This is the step people skip, and it’s the one that catches the nastiest problems. The name servers listed in your DNS provider’s dashboard are not necessarily the ones the internet is using.

# What the parent zone (the registry) says
dig +short NS example.com

# What the zone itself says, straight from one of those servers
dig @ns1.example-dns.com example.com NS

Those two lists should match. When they don’t, you’ve usually found a half-finished DNS migration: the registrar still delegates to the old provider, so the world keeps reading a zone nobody has updated in months.

Step 4 — Query every authoritative server individually

A zone with four name servers can be inconsistent across them if a zone transfer failed. Intermittent, “it works every third time” problems are almost always this. Compare the SOA serial on each:

# Pull the SOA record from every authoritative server in one shot
dig +nssearch example.com

# Or check them one by one
dig +short @ns1.example-dns.com example.com SOA
dig +short @ns2.example-dns.com example.com SOA

Different serial numbers mean the secondaries haven’t caught up with the primary. Different answers for the same record mean something is genuinely broken in replication.

Step 5 — Walk the delegation chain

When nothing else explains it, follow the query the way a recursive resolver would — from the root, down through the TLD, to the authoritative servers:

dig +trace example.com A

Read it top to bottom. Each block is one hop. The point where the output stops making sense — a referral to servers that don’t answer, a missing glue record, an unexpected NXDOMAIN — is your break point. This single command has saved me more time than any other in DNS troubleshooting.

Reading dig Output Without Guessing

The status line in a dig response tells you the category of failure immediately. Learn these four and you’ve eliminated most of the guesswork.

• NOERROR — the query succeeded. Note that NOERROR with an empty answer section is not a failure: it means the name exists but has no record of the type you asked for. Asking for an A record on a name that only has MX records gives you exactly this.
• NXDOMAIN — the name does not exist at all. Not a typo in the record; the label itself isn’t in the zone. Check for a missing record, a misspelled hostname, or a zone that isn’t loaded.
• SERVFAIL — the resolver tried and failed. This is the ambiguous one, and in practice it usually means DNSSEC validation failure, an authoritative server that’s unreachable or refusing queries, or a broken delegation.
• REFUSED — the server you asked is not willing to answer for that zone. Typically you’re querying a server that isn’t authoritative and doesn’t do recursion for you.

Two other things worth reading in every response:

• The aa flag — present when the answer came from an authoritative server. If it’s missing, you’re looking at a cached answer, and the TTL tells you how stale it might be.
• The TTL column — on a cached answer this counts down. Query the same resolver twice a few seconds apart; if the TTL drops, you’re being served from cache. If it stays constant, you’re hitting the source.

The Propagation Myth (and What’s Really Happening)

“DNS propagation takes 24 to 48 hours” is the most repeated and least accurate sentence in web hosting. Nothing propagates. When you change a record, the authoritative server has the new value instantly. What takes time is the expiry of cached copies held by thousands of independent resolvers — and that duration is entirely determined by the TTL you set before the change.

The practical consequence: lowering a TTL after you’ve made the change does nothing for anyone who already cached the old value. Plan ahead instead.

1. Well before a migration, drop the TTL on the records you’ll change to something short — 300 seconds is a common choice.
2. Wait at least the length of the old TTL so the short value fully replaces it in caches.
3. Make the actual change. Old cached answers now expire within minutes.
4. Verify against several public resolvers and from a couple of different networks.
5. Once everything is stable, raise the TTL back to something sane — an hour or more — so you’re not paying for lookups you don’t need.

The TTL you set today determines how painful next month’s migration will be. It’s the cheapest piece of planning in infrastructure work, and the one most consistently skipped.

One more thing people miss: negative caching. When a lookup returns NXDOMAIN, resolvers cache that “doesn’t exist” answer too, for a duration derived from the minimum field in the zone’s SOA record. So if you query a hostname before creating it, you may keep getting NXDOMAIN for a while even after the record is live. Check what you’re in for:

dig +short example.com SOA

The last number in that output is the negative caching TTL. Resist the urge to test a hostname before you’ve actually created it.

Failure Patterns You’ll Meet Again and Again

A CNAME on the zone apex

You cannot put a plain CNAME on the root of a domain. The apex must carry SOA and NS records, and a CNAME is not allowed to coexist with other records at the same name. Providers work around this with ALIAS, ANAME, or “CNAME flattening” records that resolve the target server-side and return an A record. If your root domain misbehaves while www is fine, this is the first thing to check.

Stale cache — everywhere at once

Correct at the authoritative server, wrong on your machine. Clear caches from the outside in:

# Linux with systemd-resolved
sudo resolvectl flush-caches

# Linux with nscd
sudo systemctl restart nscd

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Windows (run as Administrator)
ipconfig /flushdns

Then remember the browser. Chromium-based browsers keep a separate cache you can clear at chrome://net-internals/#dns. And if the site uses HSTS, a browser may refuse to fall back to HTTP regardless of what DNS says — test with curl before you conclude anything from a browser.

A forgotten line in /etc/hosts

Someone adds a hosts entry during a migration to test the new server, and never removes it. Six months later the server is “randomly” hitting the wrong backend. It costs three seconds to rule out:

grep -i example.com /etc/hosts
getent hosts example.com

DNSSEC validation failures

A domain with broken DNSSEC returns SERVFAIL from validating resolvers while working perfectly on non-validating ones. That produces the maddening symptom where the site loads for some users and not others, with no geographic pattern.

The diagnostic trick is +cd, which disables validation. If the query fails normally but succeeds with +cd, DNSSEC is your culprit:

dig @1.1.1.1 example.com A
dig @1.1.1.1 +cd example.com A

# Show the DNSSEC records themselves
dig example.com DNSKEY +dnssec
dig example.com DS

# delv performs validation and explains the outcome
delv example.com A

The usual cause is a DS record at the registrar that no longer matches the keys published in the zone — classic after changing DNS providers without disabling DNSSEC first. Always turn DNSSEC off at the registrar before migrating name servers, then re-enable it once the new provider is live and stable.

Split-horizon DNS surprises

Internal resolvers hand out private addresses; external resolvers hand out public ones. Perfectly intentional — until a VPN, a container, or a misconfigured search domain puts a client on the wrong side of the split. When a name resolves differently depending on where you run the query, compare the local resolver against a public one and check whether a VPN profile is pushing its own DNS servers.

Proxied records hiding the origin

If a domain sits behind Cloudflare or a similar proxy, public DNS returns the proxy’s IP, not your server’s. That’s the whole point — but it means you cannot verify an origin change through public DNS at all. Query the authoritative provider’s own API or dashboard for the real record value, and test the origin directly with curl --resolve.

Wildcards masking a missing record

A * record in the zone means every hostname resolves — including the ones you typo’d, and including subdomains you thought you’d deleted. If everything resolves but half of it points somewhere unexpected, check for a wildcard before you go hunting for phantom records.

Missing trailing dots in zone files

Hand-editing BIND zone files? A record value without a trailing dot gets the origin appended to it. Write mail.example.com instead of mail.example.com. and you’ve just created mail.example.com.example.com. Validate before reloading:

named-checkconf
named-checkzone example.com /var/named/example.com.zone

And bump the SOA serial. A zone edit without a serial increment won’t reach the secondaries, which is exactly the inconsistency you were chasing in Step 4.

Containers and the ndots trap

Inside Kubernetes pods, /etc/resolv.conf commonly sets ndots:5. Any name with fewer than five dots gets tried against every search domain first, so an external lookup like api.example.com can generate several failed queries before the correct one. It works — it’s just slow, and under load it looks like intermittent DNS failure. Adding a trailing dot to fully qualify the name skips the search list entirely:

cat /etc/resolv.conf
dig api.example.com.        # note the trailing dot

DNS Troubleshooting for Email Delivery

Mail problems are DNS problems more often than they are mail-server problems. When messages bounce or land in spam, check these before touching the mail server config:

# Where should mail for this domain go?
dig +short example.com MX

# SPF and DMARC live in TXT records
dig +short example.com TXT
dig +short _dmarc.example.com TXT

# DKIM lives under a selector you choose
dig +short selector1._domainkey.example.com TXT

# Reverse DNS for the sending IP
dig -x 203.0.113.10 +short

Things that regularly go wrong here:

• Two SPF records. A domain must publish exactly one. Two SPF TXT records is a permanent error, and receiving servers are entitled to fail the check outright. Merge them into one.
• An MX pointing at a CNAME. MX targets must resolve to address records, not aliases.
• Missing reverse DNS. If the PTR record for your sending IP doesn’t match the hostname the server announces, expect a lot of spam folder.
• DKIM selector mismatch. The selector in the message header must match the one published in DNS — a detail that quietly breaks after a mail platform migration.

While you’re in TXT territory: if certificate issuance is failing, check for a CAA record. A CAA entry that only authorises one certificate authority will silently block every other one, and the error you get back from the ACME client rarely says “DNS.”

dig +short example.com CAA

Mistakes That Cost the Most Time

• Testing only in a browser. Browser caches, HSTS, service workers, and QUIC connection reuse will all lie to you. Confirm with dig and curl.
• Trusting the control panel. The dashboard shows what the zone should contain. Only a query against the authoritative server shows what it actually serves.
• Changing several things at once. Adjust one record, verify, then move on. Batch changes turn a five-minute fix into an archaeology project.
• Forgetting IPv6. A stale or wrong AAAA record produces “works for some people” behaviour, because dual-stack clients generally prefer IPv6. Always check dig +short example.com AAAA.
• Leaving DNSSEC enabled through a provider migration. The single most reliable way to take a domain fully offline for hours.
• Not documenting the zone before a migration. Export or record every record first. Rebuilding a zone from memory at 2am is not a plan.

Best Practices That Prevent the Next Incident

• Use at least two name servers, ideally on separate networks or providers. Single-provider DNS is a single point of failure for your entire presence.
• Keep TTLs deliberate. Long TTLs for stable infrastructure, short ones ahead of planned changes. Not the other way round.
• Monitor DNS resolution itself, not just HTTP endpoints. A check that queries your authoritative servers directly and alerts on a changed or missing answer catches problems before users do.
• Version-control your zone data if your provider supports API or zone-file export. Diffing two zone versions turns “what changed?” into a one-second question.
• Keep a record inventory — what each record is for, who owns it, and whether it’s still needed. Old A records pointing at decommissioned servers are a genuine security risk, not just clutter.
• Standardise your checks. A short script that runs your Step 1–5 sequence against a domain makes DNS troubleshooting repeatable instead of improvised.

A Quick Reference You Can Keep

# Basic resolution
dig +short example.com A
dig +short example.com AAAA

# Compare resolvers
dig +short @1.1.1.1 example.com A
dig +short @8.8.8.8 example.com A

# Authority and delegation
dig +short example.com NS
dig +trace example.com A
dig +nssearch example.com

# Cache behaviour
dig example.com A            # watch the TTL count down
dig +norecurse @1.1.1.1 example.com A   # cached-only lookup

# DNSSEC
dig +cd example.com A
delv example.com A

# Mail and verification records
dig +short example.com MX
dig +short example.com TXT
dig +short _dmarc.example.com TXT
dig -x 203.0.113.10 +short

# System-level view
resolvectl status
getent hosts example.com
cat /etc/resolv.conf

Frequently Asked Questions

How long does a DNS change really take to take effect?

At the authoritative server, immediately. For everyone else, up to the TTL that was in place when they last cached the record. If the old TTL was 3600 seconds, worst case is roughly an hour. The “24 to 48 hours” figure is a legacy of very long default TTLs and badly behaved resolvers, not a rule.

What’s the difference between SERVFAIL and NXDOMAIN?

NXDOMAIN is a definitive answer: the name doesn’t exist. SERVFAIL means the resolver couldn’t produce an answer at all — commonly a DNSSEC validation failure, an unreachable authoritative server, or a broken delegation. NXDOMAIN points you at the zone contents; SERVFAIL points you at the infrastructure.

Why does the site work for me but not for a colleague?

Different resolvers with different cache states, a hosts file entry on one machine, a VPN pushing internal DNS, an IPv6 versus IPv4 difference, or DNSSEC failing only on validating resolvers. Have both people run the same dig against the same public resolver — if the answers match, the difference is local to one machine.

Should I use dig or nslookup?

dig, whenever it’s available. It shows response status, flags, TTLs and the authority section, all of which you need for real DNS troubleshooting. Use nslookup or Resolve-DnsName when you’re on a Windows box without other tooling.

Do online “DNS propagation checker” sites actually help?

They’re useful for one thing: seeing what different resolvers around the world currently have cached. They won’t tell you why an answer is wrong, and they can’t see proxied origins or internal split-horizon zones. Treat them as a rough sanity check, not a diagnosis.

Can a CNAME point to another CNAME?

Technically yes, and resolvers will follow the chain — but every extra hop adds latency and another thing to break. Keep chains short, and never let one loop back on itself. Also remember a CNAME cannot coexist with other records at the same name, which is why it doesn’t belong on a zone apex.

Why do my DNS changes keep reverting?

Usually because something else owns the zone: an infrastructure-as-code pipeline, a control panel that rewrites records on certain actions, or an external DNS controller in a Kubernetes cluster. Decide on one source of truth and make every change through it.

Is switching to a public resolver a fix?

It’s a workaround for one user, not a fix for the domain. It’s genuinely useful as a diagnostic — if 1.1.1.1 gives the right answer and your ISP’s resolver doesn’t, you’ve isolated the problem to that resolver’s cache. But if the record itself is wrong, changing resolvers just changes who tells you the wrong thing.

Wrapping Up

Good DNS troubleshooting isn’t about knowing obscure record types. It’s about discipline: confirm it’s DNS, compare resolvers, find out who’s really authoritative, ask each of them directly, and follow the delegation chain when the answers stop agreeing. Five steps, in order, every time.

Do that consistently and most incidents collapse into something small and obvious — a stale cache, a TTL nobody lowered, a DS record left behind after a migration, a hosts entry from six months ago. The problems aren’t usually exotic. They’re just invisible until you ask the right party the right question.

Keep the quick-reference commands somewhere you can reach in thirty seconds, set your TTLs before you need them, and monitor resolution as seriously as you monitor uptime. Future you will appreciate it at 2am.

Need a Hand With DNS, Hosting or Cloud Infrastructure?

If you’re stuck on a DNS issue, planning a migration you’d rather not do twice, or you just want someone to review a zone before you flip the switch, I’m available for freelance work.

I work on DNS configuration and troubleshooting, domain and hosting migrations, SSL and certificate issues, email deliverability records (SPF, DKIM, DMARC), server setup and hardening, AWS and cloud infrastructure, and monitoring and alerting — plus WordPress performance and maintenance.

You can see my profile, past work and reviews on Upwork, and message me directly there with what you’re dealing with.

Got a DNS problem this article didn’t cover? Leave a comment describing the symptoms and what dig +trace shows — that output alone usually narrows it down fast.

The post DNS Troubleshooting: How to Find the Real Cause in Minutes, Not Hours appeared first on John Nessime.