DEV Community: Jeff W

Your SSL Cert Works in Chrome. Here's Why It's Broken Everywhere Else.

Jeff W — Mon, 07 Sep 2026 16:24:10 +0000

"The site loads fine in my browser" is one of the least reassuring sentences in TLS debugging. Chrome (and every major browser) does a lot of quiet, generous error-correction that curl, older mobile OSes, most programming-language HTTP clients, and plenty of corporate proxies simply don't. A cert that looks perfectly fine with the padlock icon can still be actively broken for a meaningful slice of real traffic.

Here's what's actually going on, and how to check for it yourself instead of trusting the padlock.

The chain isn't just "your certificate"

A TLS handshake sends your leaf certificate (the one for your actual domain) plus zero or more intermediate certificates that chain it up to a root CA your client already trusts. Browsers ship with a huge cache of known intermediates and will silently fetch a missing one via the AIA (Authority Information Access) extension if your server doesn't send it. Most other clients won't. No caching, no AIA chasing; if your server doesn't hand over the full chain, the handshake just fails.

This is, by a wide margin, the single most common "works for me" TLS bug.

Check what your server is actually sending, not what your browser reconstructed for you:

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

Better, see the whole chain your server sent (count the s:/i: pairs — if there's only one certificate and it's not directly signed by a well-known root, you're missing intermediates):

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

Order matters too

Even when the intermediate is present, some servers send it in the wrong order (root before intermediate, or leaf last). The spec technically wants leaf first, then each subsequent issuer in order — plenty of servers get away with the wrong order because, again, browsers correct for it. openssl s_client will show you the order as sent; a client that validates strictly (which is more common outside browsers than you'd think) will reject an out-of-order chain even though every certificate in it is individually valid.

OCSP stapling: not required, but its absence has a cost

Without OCSP stapling, the client has to go ask the CA "is this cert still valid?" on its own, out-of-band, during the handshake. That's an extra network round-trip to a third party your client may or may not be able to reach quickly (or at all, behind certain corporate proxies/firewalls) — and some clients fail closed on a slow/failed OCSP check rather than just proceeding. Stapling means your server fetches that proof ahead of time and hands it over as part of the handshake itself — one less external dependency in the critical path of every single connection.

Check whether it's actually working (not just enabled in config):

openssl s_client -connect example.com:443 -servername example.com -status < /dev/null 2>/dev/null | grep -A1 "OCSP Response Status"

successful (0x0) means it's really stapling a response. Nothing there at all is the far more common finding than you'd expect, even on sites that believe they've turned it on.

Cipher/protocol mismatches quietly cut off old clients

Disabling TLS 1.0/1.1 and weak ciphers is correct and you should do it, but "correct" and "zero impact" aren't the same thing. Older Android versions, some embedded/IoT HTTP clients, and legacy internal tooling can be stuck on a cipher/protocol combination your server no longer offers. This fails before certificate validation even happens, so it's easy to misdiagnose as a cert problem when it's actually a negotiation problem:

openssl s_client -connect example.com:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'

If a specific old client is failing, negotiating with the closest matching protocol/cipher combination from your own machine tells you whether it's even in your server's supported set before you go looking anywhere else.

SNI: the handshake needs to know who it's talking to

If your server hosts multiple certificates behind one IP (extremely common now), it picks which one to present based on the SNI (Server Name Indication) value the client sends in its ClientHello. A client that doesn't send SNI at all — some older clients, certain bare-metal health checkers, a curl command that omits -servername when testing a non-default port — can get served the wrong certificate, or the server's default/fallback cert, and then fail validation for a hostname that's actually configured perfectly fine. Notice the -servername flag in every command above — that's not decorative, it's what makes the test represent a real browser request instead of a different, SNI-less one.

Checking all of this without memorizing openssl flags

The commands above are the ground truth, but running five of them by hand every time you touch a cert is exactly the kind of thing that gets skipped under time pressure — right up until a customer reports "it doesn't work" from some client you didn't test.

I built a free tool that runs the chain-completeness, order, OCSP-stapling, and TLS protocol/cipher checks above against any domain and shows you the results in one pass:

SSL Certificate Checker — full chain, key type/size, fingerprints, protocol support matrix, and OCSP status, for any public domain, no account needed.

(Disclosure: I built this — it's a free tool from ShieldIngress, a WAF/edge security product I run. No catch, no signup — I'd just rather people catch this before a client does.)

Beyond IP Blocking: Filtering Requests by Header, Query Param, and Cookie

Jeff W — Wed, 02 Sep 2026 09:24:00 +0000

Most "block bad traffic" advice starts and ends with IP blocklists. That's a start, but IP-based rules break down fast in practice: attackers rotate through residential proxies, legitimate users share IPs behind NAT/CGNAT, and a single blocked IP can be one bad actor or a whole office building.

A layer that gets skipped way more often than it should: matching on the request itself — a header, a query parameter, or a cookie — instead of (or alongside) the source IP. Here's when each actually earns its place, with working examples for nginx, Apache, and Express.

1. Gate an internal/staging endpoint with a shared-secret header

If you have an endpoint that should only ever be hit by your own tooling — a webhook receiver, an internal admin API, a staging environment — don't rely on obscurity or IP allowlisting alone (IPs change, CI runners are ephemeral). Require a header instead:

# nginx
location /internal/ {
    if ($http_x_internal_token != "your-secret-value") {
        return 403;
    }
}

# Apache (mod_rewrite)
<Location /internal/>
    RewriteEngine On
    RewriteCond %{HTTP:X-Internal-Token} !^your-secret-value$
    RewriteRule ^ - [F]
</Location>

// Express middleware
app.use('/internal', (req, res, next) => {
  if (req.headers['x-internal-token'] !== process.env.INTERNAL_TOKEN) {
    return res.status(403).send('Forbidden');
  }
  next();
});

This is cheap, doesn't care what IP the request comes from, and rotates trivially if it ever leaks (just change the env var).

2. Block obvious bot/scraper traffic by User-Agent or missing headers

A shocking amount of low-effort scraping traffic doesn't bother sending a realistic User-Agent, or omits Accept-Language entirely — headers a real browser always sends. You can catch a meaningful chunk of junk traffic just by requiring these to be present, before it ever reaches your app logic:

# nginx
if ($http_user_agent = "") {
    return 403;
}

# Apache (mod_rewrite)
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule ^ - [F]

This won't stop a sophisticated attacker (they'll just fake a normal browser UA), but it's nearly free and kills a surprising amount of naive automated traffic.

3. Feature-flag or A/B test at the edge with query params or cookies

Not security-specific, but the same matching mechanism: routing based on a query param (?preview=true) or a cookie your app sets is how a lot of preview/canary deployments work without needing a separate hostname.

# nginx
if ($arg_preview = "true") {
    proxy_pass http://staging-backend;
}

# Apache (mod_rewrite + mod_proxy)
RewriteCond %{QUERY_STRING} preview=true
RewriteRule ^(.*)$ http://staging-backend%{REQUEST_URI} [P,L]

The catch

None of this is exotic — the trade-off is that hand-maintained RewriteCond/if blocks scattered across config files get messy fast, and a typo in a security-relevant rule is exactly the kind of thing that silently fails open instead of loud. Worth testing each rule against both a request that should pass and one that shouldn't, not just the happy path.

(I work on a managed WAF, ShieldIngress — this is one of the things it does automatically, but everything above works with whatever you're already running.)

A Practical Guide to ModSecurity/Coraza SecRule Syntax (and the mistakes that bite)

Jeff W — Sun, 30 Aug 2026 19:40:10 +0000

If you run a WAF backed by ModSecurity or Coraza (the Go rewrite most modern setups use now — nginx, HAProxy via SPOE, Traefik plugins, etc.), sooner or later you write a custom SecRule by hand. The syntax is powerful and genuinely well-designed once it clicks, but the learning curve is real — most people's first custom rule either silently does nothing or blocks traffic they didn't mean to.

Here's the anatomy of a rule, and the specific mistakes that actually trip people up.

The shape of a SecRule

Every rule is three parts: what to look at, how to match it, what to do.

SecRule VARIABLE "OPERATOR value" "ACTIONS"

A real one — block any request whose URI contains /wp-admin from an IP not in your office range:

SecRule REQUEST_URI "@contains /wp-admin" "id:1000001,phase:2,deny,status:403,msg:'Blocked wp-admin probe'"

REQUEST_URI — the variable being inspected. Others you'll reach for constantly: ARGS (any query/body parameter), REQUEST_HEADERS, REQUEST_COOKIES, REQUEST_METHOD, REMOTE_ADDR.
@contains — the operator. @streq (exact match), @beginsWith/@endsWith, @rx (regex), @ipMatch (IP/CIDR), and the built-in @detectSQLi/@detectXSS heuristics are the ones you'll use most.
id, phase, deny, status, msg — actions. Every rule needs a unique id. phase:2 means "after the request body is parsed" — almost always what you want for anything inspecting ARGS or REQUEST_BODY; phase:1 runs before that, headers/URI only.

Combining conditions

Multiple SecRule lines chained with chain act as AND — all of them have to match. The gotcha: only the first line carries the real actions (id, phase, deny, etc.); every line after it just needs chain (except the last, which needs nothing extra):

SecRule REQUEST_METHOD "@streq POST" "id:1000002,phase:2,deny,status:403,chain"
    SecRule REQUEST_URI "@contains /api/admin" "t:none"

Forget the chain on a non-final line and you've written two independent rules instead of one AND condition — this is the single most common way a "working" rule turns out to match far more (or far less) than intended.

Allow-listing instead of blocking

The other half of writing WAF rules is un-blocking something the ruleset got wrong — a legitimate rich-text field that trips an XSS heuristic, for example. Don't just disable the whole rule globally; scope the exemption as narrowly as you can:

SecRule REQUEST_URI "@beginsWith /editor/save" "id:1000003,phase:2,pass,nolog,ctl:ruleRemoveTargetById=941320;ARGS:content"

ctl:ruleRemoveTargetById=<id>;<VARIABLE> removes just one field from one rule's inspection
— rule 941320 keeps checking everything else on this request, it just stops looking at ARGS:content. Use ctl:ruleRemoveById=<id> (no target) only when you're sure the whole rule should be off for requests matching your condition — that's a much bigger exemption than most false-positive fixes actually need.

The mistake almost everyone makes once: rule ID collisions

If you're running the OWASP Core Rule Set (CRS) — most Coraza/ModSecurity setups are — its rules live in id range 900000–999999 (and CRS reserves 800000–999999 broadly for its own use). Pick a custom rule ID in that range and you'll get silent, confusing collisions the first time CRS ships an update that happens to use the same number.

Use 1000000 and up for anything custom. This is genuinely the most common mistake I see — it works fine until the day it doesn't.

Case sensitivity and transformations

t:lowercase before a @streq/@contains match makes it case-insensitive; the default (t:none) is case-sensitive. Easy to forget, and the failure mode is quiet — the rule just doesn't fire on /WP-ADMIN instead of erroring, which is exactly the kind of gap that gets found in production instead of testing.

Building these without the syntax fights

Once you know the shape, hand-writing simple rules is fine — but the escaping rules (regex needs different quote-escaping than a literal string match), the chain/action ordering, and the CRS reserved-ID range are exactly the kind of thing that's easy to get subtly wrong under time pressure, mid-incident, at 2am.

I built a small free tool that generates a correct rule from plain fields — pick the variable, operator, and value, and it handles the syntax, the chaining, the reserved-ID warning, and the block-vs-exempt distinction above for you:

WAF Rule Builder — runs entirely in your browser, nothing you type is sent anywhere, just copy the generated rule into your own config.

(Disclosure: I built this — it's a free tool from ShieldIngress, a WAF/edge security product I run. No catch, no signup — I'd just rather people not lose an evening to a missing chain keyword.)

6 HTTP Security Headers Your Site Is Probably Missing (and how to fix each one)

Jeff W — Sat, 29 Aug 2026 15:10:25 +0000

Run any random production site through a headers check and odds are it's missing at least half of the headers below. Not because anyone decided against them — usually because nobody ever added them in the first place. They cost nothing, take one line to set, and most frameworks don't set them for you by default.

Here's what each one actually does, and the one-liner to add it in a few common stacks.

1. Strict-Transport-Security (HSTS)

Tells the browser "never connect to this site over plain HTTP again, even if someone types http:// or links to it that way." Without it, every visit is one stray link or bookmark away from a downgrade-to-HTTP attack.

Strict-Transport-Security: max-age=63072000; includeSubDomains

Express (helmet):

app.use(helmet.hsts({ maxAge: 63072000, includeSubDomains: true }));

nginx:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

2. Content-Security-Policy (CSP)

The single biggest lever against XSS. It tells the browser exactly which origins are allowed to supply scripts, styles, images, etc. — so even if an attacker manages to inject a <script> tag somewhere, the browser refuses to run it if it's not from an allowed source.

It's also the one people avoid because a bad policy breaks your own site. Start narrow and loosen it as you find real violations (report-only mode is your friend here):

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com

3. X-Frame-Options

Stops your pages from being loaded inside a hidden <iframe> on someone else's site — the setup behind clickjacking ("click here to win a prize" that's secretly your bank's transfer-confirmation button underneath).

X-Frame-Options: DENY

(CSP's frame-ancestors directive supersedes this in modern browsers, but set both — older clients don't understand frame-ancestors.)

4. X-Content-Type-Options

One value, always the same:

X-Content-Type-Options: nosniff

Without it, some browsers will "sniff" a response's actual content and decide to treat it as something other than what the Content-Type header says — the classic version being an uploaded file that's technically an image but gets executed as script.

5. Referrer-Policy

Controls how much of your own URL — including query strings, which sometimes contain tokens or IDs you didn't mean to share — gets sent to whatever site a visitor clicks away to.

Referrer-Policy: strict-origin-when-cross-origin

A reasonable default: full URL on same-origin navigation, just the origin (no path/query) on cross-origin ones.

6. Permissions-Policy

Explicitly turns off browser features your site never uses — camera, microphone, geolocation, USB, etc. Even if you never call these APIs yourself, a compromised third-party script embedded on your page could try to.

Permissions-Policy: camera=(), microphone=(), geolocation=()

Bonus: stop announcing your stack

Server: nginx/1.18.0 and X-Powered-By: Express don't do anything for your visitors — they just hand an attacker a head start on which known vulnerabilities to try first.

server_tokens off;

app.disable('x-powered-by'); // Express

Checking your own site

Reading headers off a raw response is annoying to do by hand every time — curl -I and then squinting for six specific header names. I built a small free tool that just does the check and tells you what's missing and why each one matters:

Security Headers Checker — no signup, doesn't store anything you enter, checks all six headers above plus flags the Server/X-Powered-By leaks.

(Disclosure: I built this — it's a free tool from ShieldIngress, a WAF/edge security product I run. The checker itself has no paywall or catch, I'd genuinely rather more sites just have these headers set.)

If you run it against your own site and find gaps, the snippets above should cover fixing most of them in a few minutes.