I don't think I was clear. When I say "Authentication", I'm referring to the first "A" in "AAA" - i.e.: verifying your client/server identity at the SSL/TLS layer (not a password exchange which comes later). Encryption doesn't require a purchased certificate. You can implement HTTPS just fine with your own self-signed key/cert combo. Likewise any application you use can do the same to keep the information secret. When I say "authentication" above, I'm not referring to your application level username/password back and forth. I'm referring to the bit where, say, your web browser wants to verify that the SSL cert you're using actually belongs to you, and does so by inherently trusting the CA that signed the cert. A bit like the bouncer at the nightclub trusts that your driver's license is legit because it's got a cute little hologram over the top, and from there, trusts that you are who your ID says. Now, if you don't want the whole signed certificate bit, you don't have to use it. If you own both sides of the communication (say, two servers passing data, or a laptop connecting to a VPN server, or a web browser running on an SOE desktop talking to an internal web server), you don't need the signed CA. You can just tell each side that the other is legit, because you as the admin say so, and to trust that specific fingerprint. When they connect, they see it whitelisted, are satisfied that it's not some dodgy individual, and away they go. In the same way, an expired SSL certificate doesn't mean a website suddenly stops encrypting data. All it means is that you can't be sure that the website belongs to the people who claim to own it still. And the crux of the whole issue is - do we even trust CAs? If I connect to Commbank.com.au and get the little green bar in my web browser saying it's legit, the only thing that verifies that is the fact that my web browser trusts a company called Verisign. Do *I* trust Verisign? Do I have proof that they did their due diligence in making sure that the person ringing up to get the commbank SSL cert actually worked for the commbank? Or even more maliciously, did I sight them in person on site? (What if it was someone using one of commbanks internal phone lines to get the certificate maliciously?). That's the problem this thread covers - Symantec were handing out signed certs without doing their due diligence. That's bad. Compare and contrast to a PGP key signing event. You turn up with several pieces of photo ID, and your digital certificates signed by others. You then present the "evidence" that you are who you say you are, backed up by other people in your circle of known acquaintances and your ID. If someone else thinks that's good enough, they too can sign your key. Eventually the list of signatures is overwhelmingly large enough for others to trust, and you've built your "Web of Trust". But again, you don't need that at all to ensure encryption. If all you want to do is obfuscate a string of text, the authentication part (particularly authenticating your server to the entire Internet) is unnecessary if you control all the points in question. Coming full circle: if you're writing some app that communicates between two bits of kit that your company owns, and isn't designed to ever have a random Internet user log in to it, then you don't need to buy an SSL cert from anyone. That part is entirely unnecessary for that specific use case.