In the wake of the Heartbleed bug, many are faced with the daunting (and expensive) prospect of replacing the SSL certificates on those vulnerable systems. This is due to the possibility that the private keys of exposed SSL certificates may or may not have been compromised. In the end, since there is no way to know for sure if your private keys have been compromised, many are opting to replace the SSL certificates of the affected system(s).
But is it strictly necessary to use expensive publicly rooted certificates for all your SSL certificate requirements? In many cases, the answer is certainly yes. But that may not always be the case.
In my career as a PKI consultant, I have often come across publicly rooted SSL certificates used in places where privately rooted certificates would certainly have sufficed. The decision to use publicly rooted certs is being made for a variety of reasons: perceived elevated levels of trustworthiness and assurance and business expediency to name a few. Administrators often make the decision to use public certs because ‘that is just the way it’s always been done.’
Perhaps this Heartbleed bug event can be used to revisit some of those decisions.
In my opinion, the decision to use a publicly rooted certificate should be based on the PKI requirements of the SSL application. The decision should not be based on “FUD” – fear, uncertainty, and doubt — not on business inertia, and certainly not on misconceptions.
And I say “should,” because many times I have found that the application PKI requirements are not the primary drivers of this decision process. Administrators in charge of applications often make the decision to use publicly rooted certificates over privately rooted certificates based on the (mis)perception that publicly rooted SSL certificates are somehow more trustworthy, or somehow have more assurance than any SSL certificates they could generate privately. And while that may be the case, we have all seen where it might not be.
I have been a part of many privately rooted PKI design efforts that have resulted in corporate PKIs capable of delivering exceptionally high levels of assurance, whose certificates are fully documented by their CP/CPS and validated by external auditors. Conversely, we have all read in the news recently about the trust short-comings of some very public PKIs.
As you can see, it’s entirely plausible that an administrator’s existing PKI could have the capability of providing more than enough assurance for the needs of their SSL certificates, often at a significantly lower cost. So what should an administrator that is tasked with renewing their SSL certificate base a “public/private” decision on? The answer quite often boils down to certificate “trust,” and not “assurance.” That is, who will need to trust your certificate? And from where will that trust need to be established?
As an application owner, one should know who needs to trust their SSL certificate. That is, who will be using the certificates? Mobile Phones? Corporate laptops? Vendors? The public?
If the answer to the trust question is a list of entities of which one has absolutely no IT control over, then one cannot assume there will be any trust whatsoever of your private root CA cert. This will almost certainly require that your new SSL certificate be rooted publically.
But, if the answer to that trust question is a list of entities to which you have complete IT control over, such as corporate laptops, servers and users, then there is a strong possibility these entities already trust, or can trust your private root. This means that you have the strong possibility of using a privately rooted SSL certificate.
It’s worth considering, as we all deal with the fallout of the Heartbleed bug, a new and possibly refined approach to replacing those affected certificates. Perhaps you can use your own SSL certificates.
