Risks of explicitly trusting SSL certificate vs relying on certificate chain for validation?
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.
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.