Risks of explicitly trusting SSL certificate vs relying on certificate chain for validation?

Question

I'm working with a client that is manually importing our (publically signed and issued by a well known intermediate CA) SSL certificate onto their client systems. I believe they are doing this because they do not update the list of trusted root CA certificates on older Microsoft Windows 7 systems.

This inevitably causes problems each time our SSL certificate is renewed or changes for any reason. I'd like to understand some reasons (advantages) that would motivate an organization to manage their systems in this way.

Specifically:

• What are the risks of not relying on the certificate chain for SSL certificate validation and instead manually importing the certificate as trusted?

• What additional risks, if any, are there for not keeping the list of trusted root CAs updated?

Answer 1

What are the risks of not relying on the certificate chain for SSL certificate validation and instead manually importing the certificate as trusted?

One is related to the fact the chain of validation typically includes a CRL and/or OCSP service to query for invalidated, but otherwise legitimate, certs. In other words, a cert may be technically valid, but have been invalidated because its private key was compromised - CRL and OCSP are standardised ways of dealing with revocation, which is not generally the case of manual certificate management.

I would also tend to think this is a waste of resources: why expend additional effort on meeting a need that has a better, and more to the point, standardised, solution?

Especially at any scale, surely this is also inefficient: versus the one root (or e.g. 5 root + intermediate CAs) you might want to trust, you would need to distribute X end-entity certificates, and additionally, would be bound to the issuing CA's lifecycle for certs in terms of needing to re-distribute new certificates.

What additional risks, if any, are there for not keeping the list of trusted root CAs updated?

As mentioned, revocation is one area that springs to mind: absent an effective revocation mechanism, a trusted CA merely indicates that something was, at some point, trusted. It has no clear significance for whether this same 'something' is now trusted.

Without maintaining your trusted roots, I would tend to think you are rendering much of the purpose of x509 moot: trust is a transitive property, and any assumptions to the contrary have tended to be exploited for malicious purposes.

Answer 2

It sounds as if you are talking about a one-to-one connection, where the client system only ever connects to your system (and maybe a few others).

In that case, the client's approach may actually be improving security, as long as they also at the same time delete all existing trusted CAs from their system.

Essentially, what they are doing is certificate pinning. They trust your SSL certificate, instead of all certificates issued by your CA. Rogue certificates, that is, certs that have been issued without knowledge of the domain owner, are a reality today. By trusting only your certificate, rogue certificates will not work even if they were issued by the same CA.

Of course, that only works if they aren't still trusting any CAs at all.

If certificate pinning indeed is your client's main goal, then cert revocation is not an issue - if a cert does need to be revoked, you would simply communicate that directly to the client.

Answer 3

Installing a trusted root certificate grants immense power over a machine. A root certificate can validate signed code, or intercept encrypted web traffic by forging certificates. (This is how https inspecting proxies work.) If your organization isn’t following all the policies and rules of a trusted CA as defined by the CA Security Council, your root CA certificate simply isn’t trustworthy.

Interestingly, you should not want your root CA to be trusted by your clients, either. Why not? Because you may become liable in case they’re hacked. An attacker could break in to your CA and use it to sign malware to be run on your clients’ machines.

That doesn’t mean your application’s or server’s certificate can’t be trusted to do whatever services you provide, but a trusted root has an inappropriately higher level of power.

We’ve had client teams asking us about installing vendor certificates in their trusted root stores before, and we always have to tell them “never allow that!”