Look, OpenSSL isn't winning any beauty contests. The API documentation reads like it was written by someone actively trying to confuse you, certificate debugging will have you staring at hex dumps at 2am wondering why you didn't become a carpenter, and every major version upgrade breaks something you didn't even know you were depending on. But here's the thing: it works everywhere, even on that Solaris box from 2003 that accounting won't let you decommission.
The Reality of OpenSSL Adoption
OpenSSL became the default crypto library the same way PHP became the default web language - not because it was the best choice, but because it was the choice that sucked the least when everything else failed. Every time you see that padlock in your browser, Apache or Nginx are using OpenSSL under the hood. Big tech companies throw money at the project because replacing it would cost more than a small country's GDP.
The library runs on everything from IoT toasters to enterprise mainframes, which sounds impressive until you realize that means it also carries 25 years of compatibility baggage. Switching to anything else would break 47 different things you forgot about and probably take down half the internet in the process.
OpenSSL 3.5 LTS: Finally Stable Enough for Production
OpenSSL 3.5 came out earlier this year, and unlike the earlier 3.x releases that made everyone stick with 1.1.1 for way too long, this one might actually be worth upgrading to. They added Post-Quantum crypto algorithms (ML-KEM, ML-DSA, and SLH-DSA), which you probably won't need until 2035 but your compliance team insists you plan for now.
More importantly, they finally added QUIC support that doesn't require you to hack together experimental patches. QUIC powers HTTP/3, and while you still need to convince your ops team to enable it, at least now the crypto library supports it properly instead of through some weird third-party integration that breaks every update.
Performance: It's Finally Not Embarrassingly Slow
OpenSSL 3.0 was slower than the old 1.1.1, which pissed off everyone who had to upgrade for security patches. They fixed most of the performance problems in recent versions, getting close to gigabit speeds for TLS handshakes. BoringSSL and AWS-LC are still faster, but unless your bottleneck is pure crypto operations (it probably isn't), the difference won't matter compared to your database queries or network latency.
Why Everyone Hates (But Uses) OpenSSL
OpenSSL tries to do everything, which means it does most things in the most complicated way possible. The API has more footguns than a Dick's Sporting Goods, and the documentation used to be hot garbage written by people who apparently assumed you already knew how OpenSSL worked. The 3.x docs are actually readable now, which is a low bar but hey, progress. I remember when the man pages assumed you already had a PhD in cryptography and knew what EVP_PKEY_CTX_set_rsa_padding() was supposed to do without any explanation of the 47 different padding schemes.
This mess is exactly why everyone keeps making forks. Google made BoringSSL because they were tired of compatibility with random legacy crap they don't need. OpenBSD made LibreSSL because they wanted something that wasn't held together with 20-year-old compatibility hacks. Amazon made AWS-LC because they wanted BoringSSL performance but with more control. Meanwhile, OpenSSL keeps all the weird algorithms and edge cases that someone, somewhere, absolutely needs to keep their Solaris 8 box running. The OpenSSL compatibility layer tries to smooth over the API changes, but breaking changes are breaking changes. You can read about all the deprecated APIs in the migration guide, or just wait for your build to break and then figure out what changed. The OpenSSL GitHub issues are full of people discovering new ways the 3.x series breaks their assumptions, and the mailing list archives document years of "why did this change" conversations.
