Venafi’s Scott Carter offers a word of caution before deploying self-signed certificates.
A self-signed certificate is one that you create in-house, using tools like openssl instead of requesting it from a public certificate authority (CA). Almost no one is still using self-signed certificates on public-facing websites (because they are not contained in the trust stores of major browsers, they trigger a warning to web visitors). However, there are still a certain number of enterprises that use them within their network or for test environments in DevOps or Fast IT efforts.
However, some folks still view self-signed certificates as inherently risky because they contain both the public and private key in the same entity. In that sense, self-signed certificates do not offer the widespread trust that comes with those signed by a trusted third party, such as a public certificate authority. But some security experts feel that the exposure for internal uses is relatively limited. Researchers at McAfee labs point out that the self-signed certificates are a “one-of-a-kind” which cannot be regenerated without access to the private key. They go on to point out that potential exposure may be limited, even if the key is compromised.
“The compromised certificate would be tossed out, removed from service because it could not be used to establish trust between the parties. Because the old certificate is self-signed, it also will not work for other uses, such as the TLS server-side authentication.”
That may be true, but what happens to the compromised certificate after it has been replaced? Because it was not issued by a certificate authority, it cannot be revoked, just disabled. At best, you may end up with a slew of bad certificates that you’re no longer using but can’t get rid of. At worst you may suffer from an outage caused by an expired certificate that you didn’t even know about and can’t locate.
That means you have to be very deliberate about how you use self-signed certificates. Depending on the implementation, self-signed certificates may not even be set to expire (EVER!) But let’s say that you do assign an expiration date when you generate your self-signed certificates. That’s great. But there is no mechanism to notify you when they are about to expire, as there would be with a public CA or a third-party management system. (And that expiration date could be 10 years down the road under a new administration that has zero knowledge of the certificate’s existence).
Granted, one-to-one encryption is relatively safe. But it’s only as safe as your ability to manage and monitor it. To maintain your security posture, you must be able to detect the compromise of a self-signed certificate, find the exposed certificate and generate a new one. That may be easier said than done. Because self-signed certificates do not fall under the umbrella of an independent issuing authority, they can be notoriously difficult to locate within your network.
In a great article “The Hidden Costs of Self-Signed Certificates”, Teresa Wingfield concludes that with software-only encryption “visibility into status can be severely limited.” She also warns that “Unless keys are stored in hardware, organizations cannot guarantee that it knows how many keys exist and who has had access to them. If the network is compromised, a company has no way of knowing if a key was copied off-site and is being compromised.”
This brings us to another major risk of self-signed certificates. According to Networkworld, “If the bad guys get your CA root private certificate, your implementation is useless.”
An IBM Knowledge Center entry explains why. “A user with a self-signed personal certificate might be able to use it to sign other personal certificates. In general, this is not true of personal certificates issued by a CA, and represents a significant exposure.” One of my colleagues at Venafi also wrote a revealing blog on how Cyber Criminals Can Quickly Turn a Strength into a Vulnerability.
To prevent this type of compromise, basically you need to be sure that your internal CA infrastructure is secured as well as that of the best public CAs. And let me tell you, these guys have built a business based purely on trust. So they are extremely serious about security. Plus, they have some of the most robust automated systems available to ensure adherence to strict policies designed to prevent misuse.
Experts at TechRepublic recommend that:
“If you opt to go the self-signed route for your internal servers, you must ensure your issuing certificate authority server is secure — really secure. Not only does the CA server need to be secured from nefarious network traffic, you need to make sure it is housed in a location that doesn’t lend access to just anyone. You do not want to allow every employee access to that CA server. Why? If your CA root certificate were to find its way into the hands of the wrong people, things could go downhill quickly for those internal LAN-only services.”
So, given the benefits and the risks, here’s the bottom line as I see it. Unless you have the extra highly-trained PKI staff that you’ll need to manage and protect self-signed certificates, it’s probably not worth it.
In the words of Teresa Wingfield:
“Some businesses attempt to automate SSL security workflow by writing custom software, but many manually manage processes. This takes a considerable amount of time and effort from highly skilled and trusted staff-which may mean more highly paid senior employees.”
Whether or not you decide to include self-signed certificates as part of your strategy for machine identity protection, there are certain best practices that you should always follow. Pay close attention to cipher suites and other attributes. Keep track of all certificates across the enterprise. Continually monitor the status and usage of all certificates. Automate the full certificate lifecycle to ensure maximum availability and reliability.