SSL/TLS

I’ve been using Certbot for years and it works fine. But a while back I started running into situations where Certbot felt too heavy — too many dependencies, too much Python version drama, and the way it modifies your Nginx config automatically sometimes caused more problems than it solved. That’s when I started looking at […]

When I first started running services in Docker, TLS felt like an afterthought. Everything was on localhost or an internal network, so I figured it didn’t matter much. Then I started exposing services, connecting containers to external databases, and dealing with client certificate authentication — and suddenly TLS was everywhere. Here’s what I’ve actually learned

I’ve dealt with PKCS#12 files (also called PFX or P12 — the terms are interchangeable) more times than I’d like. Mostly when migrating certificates to Windows, working with Java keystores, or handing certificates off to developers who aren’t familiar with PEM files. The format is useful but the tooling around it is inconsistent and the

I’ve gone through the CSR generation process dozens of times across different servers, operating systems, and environments. And every time I thought it was straightforward, I ran into some edge case that tripped me up — a wrong key size, a missing SAN field, a passphrase that caused issues with the web server. So here’s

Converting SSL certificates is one of those tasks that looks straightforward until you’re knee-deep in error messages at 11 PM before a deployment. I’ve converted hundreds of certificates across different server setups, and the same situations come up repeatedly: CA sends PEM, server needs PFX. Client needs Java keystore, you only have CRT and KEY

If you’ve ever tried to install an SSL certificate and hit a wall because the server expects .crt but your CA sent you .pem, you know how frustrating this rabbit hole can get. I’ve been there more times than I’d like to admit. The good news is that once you understand what these formats actually

Both wildcard and SAN (Subject Alternative Name) certificates solve the same core problem — securing multiple domains or subdomains with one certificate. But they work differently and have different costs, limitations, and use cases. Picking the wrong type leads to either unnecessary expense or coverage gaps. What Wildcard Certificates Cover A wildcard certificate secures *.example.com