There was a time I loved explaining to people how certificates work, and I still do – but I am truly done talking about this particular item. Enough is enough. If someone asks me in the future why self-signed certificates are less secure than PKI-signed ones, all they are going to get is a link to this post.
Et tu, CIS?
If you’re not 100% sure what I am ranting about, here’s an example. On their website, the usually very trustworthy Center for Internet Security (CIS) has this article: Top External Network Risks And How to Fix Them. Under paragraph 4 („misconfigured certificates“) you will find the following explanation:
Clients can trust certificates only if they are signed by a mutually trusted third-party CA. Self-signed certificates should only be used for testing purposes. Self-signed certificates should not be used on any production or critical server. These certificates pose a serious risk, as CTAs can impersonate the server by presenting a fake self-signed certificate and conduct an AiTM attack. If the client knows that the server does not have a trusted certificate, it will accept this spoofed certificate and communicate with the malicious server.
This is supposed to have been published on August 27, 2025, but I am pretty sure I’ve seen and heard this exact text quoted hundreds of times well before that date. Whatever. If your attention span allows you to read until the end of the paragraph, you will probably understand what the authors meant by it – namely, that the User (which is not the same thing as „the Client“!) will accept whatever certificate is presented, overriding their browser’s warning, if they know beforehand that they have to override the warning in order to get to this particular site. So, the „misconfiguration“ here is not that the server is presenting an „insecure certificate“ but that the organization does not manage trust on clients and allows users to override browser warnings! Let me repeat this: You can pay a commercial CA ten thousand dollar for an Extended Validation certificate, but if I (i) remove the root CA of that cert from your trust store and (ii) configure your browser so that you are not allowed to accept untrusted certs, you are not getting to the site either!
This is compounded by the fact that no one reads the whole paragraph if it has more than three sentences. So the sentences #2 and #3 is all that has burned itself into the collective memory of thousands security practitioners out there:
Self-signed certificates should only be used for testing purposes. Self-signed certificates should not be used on any production or critical server.
A further annoyance is that lots of people overlook the „External Network“ part of that article’s caption and apply the findings universally, i.e. to internal network security as well.
Before we deal with the question at hand, though, there is something else I want to get off my chest.
Another common misconception that drives me nuts
If (or, rather, when) you find yourself in a conversation about self-signed vs. PKI-signed certificates, listen carefully, because lots of folks to this day conflate „self-signed“ with „signed by a self-hosted private CA“. It used to be one conversation out of two 10 years ago. It did get better over time, but I would still place the percentage of people who do not understand the difference in double digits. So make sure you’re talking about one and the same thing before you proceed. And the question of how Let’s Encrypt is more secure than your ADCS implementation is not in scope of this post 🙂
What is a „secure cert“ anyway?
No one in their right mind should or would be using self-signed or private-signed certs on public-facing websites. Given that, and assuming that admins in an organization actually know what they’re doing, what makes a certificate more or less secure? It’s three things:
- Cryptography (key size and algorithms the key pair being used can support), i.e. how easy it is for the attacker to break the encryption
- How easy it is for the attacker to compromise the private key
- How easy it is for the admins to respond to compromise once it has been detected
That’s it – how easy your org makes it for the malicious actor to spoof DNS, or insert herself as AitM, is not a certificate security concern! Anything you could do on the DNS hardening or application hardening front, you can do with any cert, self-signed or otherwise. And remember one thing: at the root of any PKI is always a self-signed cert. The self-signedness is what makes a Root CA a root CA!
Yeah, but to make a self-signed cert trusted without warnings…
…my organization has to deploy it to all the endpoints as a trusted root CA! This is absolutely true. But
- it has nothing per se to do with security
- in a managed environment, it’s very easy to accomplish
- depending on what system will be using the self-signed cert, it doesn’t even have to be „all the endpoints“ but just the ones that will be communicating with that system! In fact, not having other systems trust the certificate is actually a side benefit, albeit a small one 🙂
So let’s stay focussed and examine the three security-related criteria above!
1. Cryptography a cert will or will not support
I have yet to hear about a widely supported cryptographic algorithm whose usage is limited to PKI-issued certificates by technical means. It’s not impossible per se to create such a standard, but lots of vendors have to start supporting it for it to become a real differentiator. Until that day, any combination of public key algorithm and key size you can request from a CA can also be packaged into a self-signed cert.
Let me reiterate: A certificate stores two kinds of information: the public key and everything else. To encrypt or decrypt a message, you need one half of the key pair. All the rest is convention (aka „industry standards“), like validity periods, revocation, allowed key usage etc., that doesn’t have anything to do with actual cryptography. These things only matter as long as systems performing the cryptography are set up in a way that they will not begin decryption if the certificate is not trusted or has expired. A threat actor is usually not bound by such limitations.
For attacking systems that DO adhere to industry standards, the hashing algorithm used to thumbprint the certificate may also be of some significance, because weak thumbprints theoretically allow falsifying certificates. On this front, PKI-signed certs also do not offer any advantages over self-signed ones!
2. Getting at the private key
One of the golden rules of certificate and key management is:
In asymmetric cryptography, the private key is generated by the entity that will use it, and doesn’t leave that entity.
Of course, there are exceptions to both parts of the rule, but if you’re able to stick with it, your allegedly insecure self-signed cert’s private key only exists on the server that will be presenting it to the clients. So, in order to compromise the self-signed cert on a single node system, the attacker has to become root on the very system she is trying to attack! But once that objective is achieved, there are probably 100 other methods to abuse this application that are cheaper and more useful (from the attacker’s point of view) than doing stuff with the certificate. And even if they do want to do nefarious stuff with the certificate, the private key doesn’t care where „its“ certificate is coming from. There’s nothing to prevent you from using the same key pair for creating a self-signed cert and for requesting a PKI-signed one!
If, on the other hand, you put the private key of your $10,000 commercially-issued EV certificate on a public-facing resource, spoofing DNS and spoofing your website as a consequence does sound like a very attractive proposition! This condition can exist in form of a .PFX file in a universally accessible file share, with another file named „PFX_password.txt“ right next to it. Or in form of a misconfigured web server where the configuration files are exposed over HTTPS. None of these conditions has anything to do with certificate security.
There are lots of use cases where two systems explicitly establish a cryptographic trust with each other (think SAML, for instance). In 99% of these cases, there’s NOTHING to be gained by issuing the trust partners‘ certs from their respective PKIs, only to then explicitly exchange the certs, without any revocation checking or other validation.
What about the possibility of abusing a compromised private key by signing other certrificates with it? Remember, we just deployed our self-signed certificate as a „trusted root“ to lots of endpoints! To put your mind at ease, this is not going to work, because your typical self-signed cert lacks both the Ca=TRUE extension and the keyCertSign EKU. This, of course, requires that all systems involved adhere to industry standards (see above). But since we’re mostly talking about spoofing here, it’s a fair assumption.
3. Dealing with private key compromise
One of the reasons why one might intuitively consider a PKI-signed certificate more secure is the ability to revoke a particular cert if there is reason to believe that its private key has been compromised. But let’s look at how this really works in a managed environment.
With a PKI-issued certificate, once a particular cert is considered compromised,
- A „Certificate Admin“ person revokes it on the CA – this can be a lengthy process when dealing with a commercial CA
- A „CA Admin“ person (which may or may not be the same person/facility) instructs the CA to recreate the CRL outside of the normal lifecycle
- The CRL is published to the CDPs or OCSP endpoints (OCSP vs. CDP is important – see my post about Let’s Encrypt’s switch from OCSP to CDP)
- If there are devices that require that CRL be uploaded to them, someone has to do this (at least, if they actually have to validate the compromised cert)
- At some point, endpoints that had cached the previous CRL request an updated one. Only from this time on are they aware of the revocation!
If the processes in steps 3 and 4 are of manual nature in your particular organization, it’s fairly safe to assume that the validity of CRLs will be longer, months rather than weeks or weeks rather than days. So the revoked certificate does not stop being trusted immediately upon revocation, unless you use OCSP and every affected node is able to access it for revocation checking.
Oh, by the way: do you remember that software you installed last year that required you to disable revocation checking in order for the installation to succeed? Guess what, if that configuration is still in place, the endpoints may not even bother checking your certificate’s status!
With a compromised self-signed cert, you have no choice than to remove or replace the „trusted root“ entry you had deployed to the endpoints. Whatever mechanism was used to establish trust in the first place can probably be used to break it again, and with the same efficiency. Whether it’s Group Policy, or an endpoint management solution, or scripts, you will probably be able to break trust quicker and more consistently than propagate the revocation of a single cert.
Conclusion
While having a PKI in place (or using a commercial one) is certainly an efficient, comfortable and „enterprise-y“ way of managing certificates at scale, there’s very little to support the claim of PKI-signed certificates being inherently „more secure“ than self-signed ones. And although Laws #2 and #8 of the „10 Immutable Laws of Security Administration“ do suggest that reduced complexity amounts to increased security, I am sure none of the people quoting that CIS article will be prepared to attribute „reduced complexity“ to PKI.
The more important law of the ten, in this case, is #7:
The most secure network is a well-administered one.
Happy certificating!