
The State of Cursor, November 2025: When Sandboxing Leaks Your Secrets
Cursor's new sandbox security model can expose credentials from your home directory. How the switch from allow-lists to ...
Don't let certificate chain issues or outdated TLS configs bite you in production. Here's a bash tool that catches SSL/TLS problems before they catch you.
I recently spent way too long debugging why Node.js and Python were rejecting my acme.sh certificates on my private Traefik server. Turns out I was using the immediate certificate instead of fullchain.cer – classic certificate chain mistake.
That’s when I (re)discovered testssl.sh, and honestly, it’s become my go-to for SSL/TLS sanity checks.
testssl.sh is basically a health check for your SSL/TLS setup. It’s a bash script that tests your server’s TLS configuration and tells you exactly what’s wrong – in plain English.
It catches everything from certificate chain issues (like mine 🤦) to outdated protocols, weak ciphers, and known vulnerabilities like Heartbleed or BEAST.
On macOS, just use Homebrew:
brew install testssl
# Then run it
testssl.sh example.com
For everyone else (or if you prefer running without installing):
# Just download and run
bash <(curl -L https://testssl.sh/testssl.sh) example.com
# Or clone if you want to keep it around
git clone --depth 1 https://github.com/testssl/testssl.sh.git
cd testssl.sh
./testssl.sh example.com
Here’s the thing: I know my home network’s attack surface is limited. But sometimes I expose services externally, and then I want that peace of mind. Plus, in a business context? Proper TLS configuration isn’t optional – it’s crucial.
And unlike public testing sites, testssl.sh runs locally – perfect for internal services, staging environments, or when corporate security policies don’t allow exposing endpoints to external scanners.
Keeping track of all the various SSL/TLS vulnerabilities is exhausting. POODLE, FREAK, Logjam, whatever new vulnerability dropped this week… testssl.sh tracks all of them for you.
If you’ve used SSL Labs before, this is basically their command-line equivalent but better. It’s:
When I ran it against my misconfigured Traefik server, it immediately flagged:
Certificate Chain Issues:
Chain of trust NOT ok (chain incomplete)
(!) Intermediate certificate missing
Clear as day. Fixed it by switching to fullchain.cer, ran the test again, all green.
But it didn’t stop there – it also pointed out security headers I was missing:
HTTP Security Headers:
Strict-Transport-Security NOT offered
Right, HSTS. Added that to my Traefik config too. These are the kinds of things you know you should configure but somehow slip through the cracks.
testssl.sh --parallel example.com
The --parallel flag speeds things up if you’re testing multiple hosts. I used to recommend --fast but it’s deprecated now and can miss important security issues, so it’s better to run the full test.
After using it to debug my certificate chain issue, I’m now running it against all my exposed services. It’s one of those tools that makes you realize how many security details you’ve been overlooking.
So yeah, if you’re running any TLS services (and who isn’t?), give testssl.sh a shot. It’s way better than waiting for your users to complain about certificate errors or, worse, getting dinged in a security audit.
What’s your go-to approach for SSL/TLS testing and monitoring? Have you had any close calls with certificate issues that could have been caught earlier? I’d love to hear about your security testing workflows and any tools you’ve found indispensable.
Explore more articles on similar topics

Cursor's new sandbox security model can expose credentials from your home directory. How the switch from allow-lists to ...

Add browser automation to your AI agent with Playwright MCP. See how visual inspection transforms UI debugging from 10+ ...

Amazon's Kiro has brilliant architectural ideas but dangerous security flaws. My honest review after 4+ hours of testing...