I was looking for a way to block certificates signed by one of the CA's mentioned in this advisory: https://community.mcafee.com/servlet/JiveServlet/previewBody/6093-102-1-13874/MTIS14-107.pdf. Since the CA's are in a subscribed list I can't just delete them.
the "Certificate Chain" setting that is used in the SSL Scanner allows you to select two lists of Root CAs, one "personal" and one with the subscribed list:
In the "My CAs" list you can add CAs and set them to "untrusted".
Ok, so I put it in the right place then.
The two entries are
India PKI - CCA India 2007
India PKI - CCA India 2011
What is missing is the newer 2014.
All three of them have been used recently to sign Google services. The advisory linked above has more details.
Interesting, the advisory states for MWG the status is under investigation. Microsoft has pushed out a patch to revoke the CA's.
as read the Microsoft advisory. As far as I understood it the "NIC CA" subordinate certificates have been removed, because they have been used to sign unauthorized certificates for major websites. I don't think the Root CAs heve been removed, thats why they are still part of MWG. The Root CAs come with CRL lists which have the information that the "NIC CA"s are revoked, so access to a website which has a certificate signed by those subordinate certificates will be prevented by MWG.
As far as I know the CCA India Root certificates are governmental CAs which are used for a wide variety of services, so I don't think they should be removed as of today.
Thanks for the additional information.
I guess the thinking here was more like, we're not doing business with anybody who will have a certificate signed by those CA's, so let's just block them.
An update to the McAfee advisory might be helpful, this would have brought clarity to the current status. At the same time I agree, more research on my part should have resulted in the same conclusion.
basically the thinking is not wrong. I think it is - from a security perspective - not the worst idea to limit the number of "trusted" certificate authorities to a minimum. The list we maintain and offer is pretty global, it is kept closely to what Microsoft and Mozilla do plus added items which pop up in support regularily. I am sure the list is not satisfying everyone but compared to our initial approach of asking every customer to maintain his own list it might be a step forward. You still have the ability to step back and build your very personal list, but from feedback I got 90% of our customer base does not want to do so.
In most support cases the requirement is that MWG behaves "closely" to how the browser behave, aka "It does not work in MWG but it works in Internet Explorer, so MWG is broken". So generally the list is more comfort orientated than plain security focussed.
I assume that blocking because of an untrusted Root CA is the killer security feature - even if we accept the CA we break the traffic and apply all the filters to the data that is actually transferred. Malicious stuff should be detected at this level.
For a real secure list of Root CAs you would need to go ahead and drop all which do not have a CRL/OCSP responder. There are plenty of them, even bigger players. Then educate your customers that they cannot access their favorite web site because the web site owner uses a certificate that is signed by a Root CA which does not have revocation lists. Customer probably won't care. We had one customer who used such an approach but that certainly reduced the comfort using the product.
In regards to advisories and abused certificates we certainly follow the press and so such issues get our attention. At least for the MWG product we can react pretty quickly and ensure the certificates are dropped or - more important - their Root CAs (for subordinate CAs) have revocation lists set up and working. In regards to the three NIC CA certificates one of them is already blocked by CRL lists since a week or so when the issue was first mentioned on the press. Since then two more subordate CAs have been revealed, one which is signed by a Root CA we do not (yet) have in the store (= no access), the remaining one was fixed recently as it was missing the CRL URL, so there should no risk remain.
As a side note, much feedback in regards to certificates comes from customers and the community, so any question, comment discussion etc. around certificates is helpful to improve the quality of the list.