Stop Using Self-Signed Certificates!

There’s kind of a rash going around, with people creating and deploying self-signed certificates in all manner of situations.

Stop it. Here’s why.

First, let me openly acknowledge that I get it. Certificate management is a PITA sometimes, especially in organizations that really have a locked-down PKI. And I mean, sheesh, all you want to do is get some encryption going, right?

No. Not right.

Self-signed certificates are primarily useful only in a test-and-pilot environment, and even then, they’re not an awesome idea because they don’t accurately test or pilot whatever you’re trying to test or pilot. For one, they’re not testing or piloting your ability to use real certificates, which is a thing you should be testing and piloting.

Additionally, you need to understand why certificates exist. I know you think you might know – encryption! – but you’re wrong. Encryption is not why certificates exist. Certificates exist to prove identity; encryption is the means by which they do so. having an SSL certificate is not there to encrypt your data; it’s there to prove that you’re sending sensitive data to actual, and not to an imposter. Encryption is the means by which that happens, but the encryption itself is pointless if the data’s going to the wrong person. Identity is why certificates exist.

As a means of proving identity, a self-signed certificate is stupid. It’s like having a homemade passport – nobody will care. The identity of Entity A can only be proven to Entity B by means of a third-party verifier, Entity C, whom Entity A and B both trust. The third-party verifier cannot also be Entity A (“trust me! I am who I assert myself to be!”) because that is dumb.

So let’s say you deploy a shiny new PowerShell Web Access (PWA) server. It refuses to run (rightfully so) without an SSL certificate. But you don’t want to get a real SSL certificate (either private or commercial), so you make a self-signed one. So now, when an administrator connects to the server and types in a Domain Admin password, you’ve no real verification that the PWA server is actually your PWA server, as opposed to some intruder. Oh, but it’ll be an encrypted channel! So, yay, you and the intruder can have a private conversation while they rip off the family jewels. Awesome.

Every time you use a self-signed certificate outside of a very initial and informal testing situation, you are making two clear statements:

  • I do not know how this works, nor do I care.
  • My organization and I do not possess certain basic IT management skills, which definitely include certificate management, but may also include many other things that others take for granted. Shun us.

So. Stop it. If managing certificates is a pain in your organization, fix that problem. Certificate management is like IP address management – it is a core expectation at this point, and if you don’t know how to do it, you don’t deserve your job (so, you know, find out). If your organization doesn’t do it, they don’t deserve your expertise (so, you know, resume).

10 thoughts on “Stop Using Self-Signed Certificates!

  1. JbJcJd

    Absolutely agree, overall and in your closing statements. I’ve found this particular issue along with abysmal lack of covering basics like DNS and IPAM to almost be triggering.

    1. sumdog

      The trouble is, most people use self signed certs and have their clients ignore them. If you manually import the self signed cert into your key store and make that the only valid cert, then yes, self-signed certs are way better than CA certs. But no one does that. If you’re going to bother, you might as well setup a local CA with ACME support. Typically self-signed certs are just bad practice.

    2. Don Jones

      I appreciate your perspective – I’m thinking a lot more broadly than just SSL though. And while I agree that there are instances where “self-signed certificates + a lot of process like notarizing and/or pinning” can be secure, I was writing about the far more common – and much less developer-centric – scenario where people simply use self-signed certificates because they’re cheap and easy.

      There’s a broader point be made from your comment: Certificates are neither secure nor insecure; they enable identity verification, which in turn can enable encryption. Self-signed certificates are not “more secure.” _The process by which a certificate is created and issued_ is what determines “how secure” something is. A self-signed certificate, alone, doesn’t enable any kind of identity verification. Control the chain, as you suggest, and you can create the degree of trust you need – but that is the process creating the trust.

      My article here was targeted primarily at administrators using PowerShell, who are my main audience, and who – regrettably and often through a simple lack of education to the contrary – use self-signed certificates as if they were fully trusted statements of identity, often resulting in a major lessening of security. I acknowledge that the overall topic of certificates is broader and more nuanced.

  2. Brett Hill

    Are you saying that somehow a public certificate is more valid than an enterprise CA? Not sure the scenario your thinking about here, as I clearly there are lots of uses for private, trusted CA.

    1. Don Jones

      Certificates issued by an enterprise CA are not “self signed.” Except the root CA which is a unique thing.

  3. sumdog

    A lot of people don’t understand that certificates are for identity. SSL certs are pretty broken though at this point, considering all the crap companies like Comodo have failed at (like issuing Iran certs for Google and Facebook). That being said, with LetsEncrypt available, there’s no excuse. There are open source solutions for rolling your on LetsEncrypt style server using the ACME protocol internally as well.

  4. Pingback: Protecting output content from prying eyes | pshirwin

  5. Pingback: Self-Signed Certificates: A Broader Perspective | Don Jones

Comments are closed