In many organizations the use of self-signed certificates is forbidden by policy. Organizations may ban the use of self-signed certificates for several reasons: It is trivially easy to generate a certificate’s key pair without reasonable entropy, to fail protect the private key of the key pair appropriately to its use, to poorly validate the certificate when used, and to misuse a self-signed certificate when a certificate authority should have been used instead. However, when properly and appropriately used, a self-signed certificate provides acceptable security in some situations.
There is a broadly held misunderstanding that self-signed certificates are inherently bad security. We offer this explanation to expand your understanding of certificate use. At the same time, we explain the circumstances under which McAfee’s use of a self-signed certificate in one of our products provides adequate security for our customers.
For many uses of public key infrastructure (PKI), the correct method for signing a certificate is to use a well-known, trusted third party, a certificate authority (CA). “In a CA-based PKI system, the CA must be trusted by both parties. This is usually accomplished by placing the CA certificates in a whitelist of trusted certificates,” says Wikipedia.
Indeed, self-signed certificates have several key limitations. Most important among these are:
- Self-signed certificates cannot be revoked.
- Self-signed certificates never expire.
However, there are cases for which a self-signed certificate may be sufficient, and perhaps a better choice than a certificate that has been signed by a CA.
In a public key infrastructure, in which parties to a communication are unknown to each other (and thus untrusted), the limitations of self-signed certificates presented above are important.
Consider browser-to-website connections. Users, via the browser, must ensure that the site to which they are connecting is indeed the intended site. In this case, having a trusted third party, the CA, is critical to validate that the web server in the connection is the one for which the certificate has been issued.
Establishing website-to-browser identity is the standard certificate use that transport layer security (TLS) pre-encryption authentication employs as well as the typical example for the use of certificates in general. This use case is also the driver for many organizational security policies in which the use of self-signed certificates is forbidden.
In the case where both sides of the communication know each other—often within the same entity—self-signing limitations become advantages. In this case, we can think of the certificate as a credential used to identify a particular entity to itself. This case is not entirely the same as attempting to establish trust between unknown parties.
In fact, when a certificate is used between two components in the same entity—that is, both sides are establishing that the other side is the one, intended component—the certificate is a form of shared secret, like a rather complex password.
In this case, there is no need for a third party to act as a root of trust. All that is required is that the key pair match—or, more precisely, that the public key can be used to verify that the certificate was signed with its private key mate (often called certificate pinning). Any public/private key pair will perform this function; an X.509 certificate happens to be a convenient and well understood “package” for the interaction.
The preceding self-signed use case presupposes that the private key of the certificate’s key pair has been and will continue to be protected with great care, similar to any important credential. One of the advantages of using an X.509 certificate for authentication is that the private key need not be installed (and thus is highly protected!) along with the certificate. The private key is used to generate the certificate. After generation, the private key is no longer needed to validate the certificate; only the public key is required.
Of course, a certificate when used as a credential requires sufficient protection, just as with any form of credential. Still, without the private key, the certificate becomes a one-of-a-kind credential; it can be reused if stolen, but it cannot be regenerated without access to the private key.
A self-signed certificate used for intercomponent authentication for TLS must be protected so that the likelihood of theft is very low. At McAfee, we provide layers of self-protection against the theft and reuse of products authentication certificates.
X.509 is nearly ubiquitous and has a great deal of programming and processing support. Hence, it is faster to deliver authentication based upon certificates than to build alternate software to validate key pairs. Besides, in the case of TLS, the protocol specifies X.509 certificates; certificates must be used to take advantage of TLS’ built-in authentication mechanism.
Because a self-signed certificate cannot be revoked and it does not expire, this reduces update and patching complexities in a connection between components built by the same entity and intended to be used solely within that closed context. However, to replace a certificate, for whatever reason, requires a software update because each self-signed certificate is the credential, rather than relying on trust of a certificate authority.
If the self-signed certificate’s private key were to become compromised in some manner, software could be updated with a new set of certificates and new keys. 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 we have described.
Essentially, once removed from its intended use, a self-signed certificate is useless to any party, malicious or otherwise.
At McAfee, we take our customer’s security seriously. We analyze each cryptography case carefully to identify the best solution that will help to ensure our customers continued protection. The use of self-signed certificates in McAfee products is appropriate to the use to which the self-signed certificate has been applied.
For more stories like this, be sure to follow us on Twitter at @McAfee_Labs.
The post Self-Signed Certificates Can Be Secure, So Why Ban Them? appeared first on McAfee Blogs.