DEV Community

Recca Tsai
Recca Tsai

Posted on • Originally published at recca0120.github.io

Laravel Valet Certificate Showing on analytics.google.com? Root Cause and Fix

#laravelvalet #ssl #nginx #dnsmasq

Originally published at recca0120.github.io

You open analytics.google.com in Chrome and click the certificate — and see this:

Enter fullscreen mode Exit fullscreen mode

That's not Google's certificate. That's your local Laravel Valet CA leaking onto an external site.

This isn't a browser bug or a Google problem — it's your local dev environment intercepting traffic it shouldn't.

How It Happens

Valet builds a local dev stack out of three components:

  1. dnsmasq: resolves *.test domains to 127.0.0.1
  2. nginx: listens on 127.0.0.1, routes requests to local sites by server_name
  3. Valet CA: signs HTTPS certificates for each .test site

In a correct setup, /etc/resolver/test scopes only *.test lookups to dnsmasq; external domains go through the system DNS. The two never cross paths.

But there are a few failure modes that break this boundary.

Cause 1: Overly Broad dnsmasq Rules

The correct content of ~/.config/valet/dnsmasq.d/tld-test.conf is:

address=/.test/127.0.0.1
Enter fullscreen mode Exit fullscreen mode

If this entry loses its TLD restriction, or if global dnsmasq config has a catch-all address rule, dnsmasq starts resolving domains outside .test to 127.0.0.1.

Cause 2: nginx Default Server Catches External Requests

When nginx gets a request whose Host header doesn't match any known server_name, it falls through to the default server block. Valet's default block doesn't reject unknown hosts — it falls back to the Valet PHP server. nginx picks up the TLS certificate from whatever vhost was loaded last, which happens to be a .test Valet cert.

Cause 3: Browser Cached the Wrong State

Chrome caches HSTS policies and TLS sessions. If even one request to an external domain was answered by Valet's nginx before the DNS issue was fixed, Chrome may cache that connection state and keep presenting the stale cert on every subsequent visit.

Why analytics.google.com Gets Hit

Google Analytics is a third-party script embedded in local pages. Your local .test site loads it; the browser tries to resolve analytics.google.com; if dnsmasq is misbehaving at that moment, it returns 127.0.0.1; nginx gets the request, finds no matching server block, and responds with whichever Valet cert it has handy.

Diagnosis

Step 1 — Check if dnsmasq is intercepting external domains

dig analytics.google.com @127.0.0.1
Enter fullscreen mode Exit fullscreen mode

Expected: SERVFAIL or a real Google IP.

Problem: 127.0.0.1 → dnsmasq is leaking. Keep going.

Step 2 — Verify dnsmasq rules are scoped to .test only

cat ~/.config/valet/dnsmasq.d/tld-test.conf
Enter fullscreen mode Exit fullscreen mode

Should only contain:

address=/.test/127.0.0.1
listen-address=127.0.0.1
Enter fullscreen mode Exit fullscreen mode

Step 3 — Check /etc/resolver/ for extra files

ls /etc/resolver/
Enter fullscreen mode Exit fullscreen mode

Only your TLD name (e.g. test) should be here. No blank filename, no wildcard.

Step 4 — Check nginx default server behavior

nginx -T 2>/dev/null | grep -A 5 "default_server"
Enter fullscreen mode Exit fullscreen mode

If the default server doesn't have return 444 or return 400, unknown hosts fall through to a real vhost.

Fixes

Fix 1: Clear Browser HSTS and Socket Cache

The most common case — even after the underlying DNS is fixed, stale cache keeps the bad cert appearing.

Chrome:

  1. Go to chrome://net-internals/#hsts
  2. Under "Delete domain security policies", type analytics.google.com → Delete
  3. Go to chrome://net-internals/#sockets → Flush socket pools

Safari:
Preferences → Privacy → Manage Website Data → search the affected domain → Remove

Fix 2: Flush System DNS Cache 

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
Enter fullscreen mode Exit fullscreen mode

Fix 3: Add an nginx Default Server That Rejects Unknown Hosts

Adding an explicit catch-all that drops connections prevents any accidental bleed-through from reaching a .test vhost:

Find the Valet nginx config directory:

ls /opt/homebrew/etc/nginx/valet/
Enter fullscreen mode Exit fullscreen mode

Add _reject-default.conf:

server {
    listen 127.0.0.1:80 default_server;
    listen 127.0.0.1:443 ssl default_server;
    server_name _;

    ssl_certificate /dev/null;
    ssl_certificate_key /dev/null;

    return 444;
}
Enter fullscreen mode Exit fullscreen mode

444 is nginx's connection-close-with-no-response code — the client gets nothing back, the request dies silently.

Apply:

valet restart
Enter fullscreen mode Exit fullscreen mode

Fix 4: Rebuild Valet CA Trust (if the Keychain state is broken) 

valet trust       # re-add Valet CA to system trust
Enter fullscreen mode Exit fullscreen mode

Or re-issue certs for your sites:

valet unsecure --all
valet secure <site-name>
Enter fullscreen mode Exit fullscreen mode

Verify the Fix 

# Confirm external domains are no longer intercepted
dig analytics.google.com @127.0.0.1
# Expected: SERVFAIL or a real IP, not 127.0.0.1

# Confirm nginx rejects unknown hosts
curl -I --resolve analytics.google.com:443:127.0.0.1 https://analytics.google.com 2>&1 | head -5
# Expected: connection refused or SSL handshake failure — not a Valet cert
Enter fullscreen mode Exit fullscreen mode

Then open Chrome, visit analytics.google.com, click the certificate icon — issuer should be Google, not Laravel Valet CA.

Prevention

  • Don't touch dnsmasq global config — Valet's dnsmasq rules should only cover your configured TLD
  • After valet install or major upgrades, re-verify dnsmasq rules haven't been broadened
  • Add the nginx default reject block once and forget about it — any stray traffic gets dropped at the nginx layer before it can serve the wrong cert
  • Avoid embedding external analytics scripts in local .test pages during development — reduces the surface area where dnsmasq leakage can trigger

References

Top comments (0)