Who is PROCERT, you might ask. Good question. It’s a small Venezuelan certificate authority (CA) that almost no one knew about until Mozilla recently decided to stop trusting their root.
So why should we give any thought to a tiny CA halfway around the world who issues no more than a few hundred certificates? Here’s why: To use the tired “weakest link” analogy, the entire PKI is only as good as the sum of its components. Mis-issued certificates can and will be used by cyber criminals, regardless of whether they come from a CA as large as Symantec or a tiny government-affiliated CA as small as PROCERT.
As we recently experienced with WoSign, Symantec and others, the use of a root is a privilege granted by browser makers. If a CA doesn’t enforce stringent security policies on the use of a root certificate, it’s like playing with a loaded weapon. You never know when it will go off and what it might hit. That’s why we have independent standards, such as the CA/Browser Forum's Baseline Requirements.
Ultimately, those CAs who don’t play by the rules will end up tainting the trust upheld by all other CAs. Based on Mozilla’s evaluation, PROCERT simply didn’t seem to be completely aware that there were rules.
“PROCERT have not been, and continue not to be, adequately aware of the requirements placed upon them by various RFCs, the CA/Browser Forum's Baseline Requirements, and Mozilla Root Store Policy. They have not demonstrated sufficient control of their issuance pipeline or sufficient checking of the results to avoid regularly creating certificates which violate the requirements of one or more of those documents.”
In an excellent blog, Vincent Lynch outlines the seven violations uncovered by researchers Alex Gaynor, Jonathan Rudenberg and Andrew Ayer. Lynch comments on why these seemingly minor violations are actually a bigger deal than they may initially appear to be.
“The range of PROCERT’s violation suggests that it either does not use well-defined profiles, or that it’s a common practice to manually circumvent such profiles. For example, issuing a certificate for an internal name suggests that it is possible for a PROCERT employee to override the technical controls – or that those controls do not exist at all.”
Of course, in the game of CA trust, there is no one strike and you’re out. Browsers will often notify CAs of apparent errors. In return, they expect certain assurances that the problem they highlighted was remedied and is not likely to occur again.
Apparently, Mozilla was not satisfied that this was the case with PROCERT, concluding, “They have not, to our knowledge, performed any root cause analysis which might allow us to have some confidence that problems of this or a similar nature will not recur.” Game over.
So, what does all of this mean for your organization? As the Google/Symantec situation illustrates, this isn’t an isolated incident. And, while you carefully choose the CAs that provide encryption assets for your organization, you may be impacted by errors that are outside of your control. You need to be able to continually monitor all certificate-related activity within your organization, so that you can react quickly to protect yourself if your CA experiences a problem.
Do you have complete visibility into your certificates and what they are doing?