A bit more info (and some discussion linked from these Bugzilla reports):
It is a shame that you cannot have a cert signed by multiple CAs.
(The format seems like it would allow it, but nothing supports it, and in practice CAs demand the ability to actually modify some fields, and then sign that.)
"Sir, this is a Wendy's" moment where my compiler thought it was a root certificate authority
This seems to be the list of certs https://gist.github.com/mendymm/ff7a9fd00339260b4d2dbdcb0f48...
data from https://www.ccadb.org/resources
It's interesting that this sort of policy is baked into a language platform.
[dead]
https://gist.github.com/AGWA/5a78186e0f4a7d537b8891a7b46f945... is the list of certificates in Certificate Transparency issued by the blocked CAs as of this time. They appear to be non-malicious test certificates, and the DNS name in the first certificate indicates who likely discovered the issue.
What's alarming and unprecedented is that yesterday, two Certificate Transparency log implementations were updated to block the logging of certificates issued by the CAs. This likely indicates total private key compromise, and the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild. (These certificates won't validate in CT-enforcing clients since they won't be in CT logs, but could be used to attack non-CT-enforcing clients.)