> A sword hanging over their head if any evidence arises that the CA has backdated any certificates.

Doesn't that just bring us right back to "too-big-to-fail CA"?

It's slightly better because at that point presumably you've failed auditing standards for many browsers, not just one. We're talking about "you tried to deliberately compromise security and get away with it by deliberately lying to take advantage of the loophole we'd provided you." With proof of that level of malfeasance, especially if it's widespread for new certs, it is plausible that Chrome and Firefox will both remove your certs, with Edge or Safari possibly coming up quickly behind. Presumably all of this would be "we are publicly announcing that we are dropping this CA in a month" to allow graceful switching...

A month's notice to allow for 'graceful switching' of CAs is overly optimistic.

We have some certificates that we have to start the renewal process 2-3 months out, because we have a lot of alternate names of domains we don't (directly) control (white-labelled service).

Thankfully we don't use WoSign for any of our certificates, but if it were say Symantec or someone else that got into trouble? Thirty days isn't enough time.

A thirty day notice that nothing issued after the date, and a 6 month migration period would be more like a graceful exit period. Still a stressful period, but less utter panic inducing.

If getting new certs is such a massive process, shouldn't you always get 2 certs from different CAs and put one in the safe?

Yeah, this has always seemed to me like a good idea, and a profit opportunity for the CAs. All the CAs get to spread FUD about each other being blacklisted, and claim that it's best practice to get two certs from different CAs (with different actual root certs, not just different resellers). Even the Let's Encrypt users will keep a fancy wildcard in their back pocket.

If you issue them from the same CSR / key, you can even configure your web server to send both certs in the certificate chain, and most clients will figure out which one they trust without requiring manual intervention by the site operator.

Doubling the cost and difficulty of CA management for a once in a... well.. we haven't yet had a major CA killed in the decades that CAs have been around.

If CAs were being killed every few months then that would be a reasonable thing to do - but not for such a rare occurrence.

Mis-issuance is creating a certificate that is totally reasonable to create, just with the wrong validation. If you have a human step that lets you override the validation check, or if you get the validation logic wrong (e.g. WoSign/StartCom's thing where they allowed high-numbered ports), etc., you end up with a certificate that is otherwise reasonable for you to have created. And there's a lot of code that goes into validation. But there is never any reasonable use for a backdated certificate, and it's a very simple thing to double-check that your code does right.

If you give CAs a pile of requirements and say "Do not do these incorrectly" (which is what browsers do to all CAs), they can always argue that they made an honest mistake and they fixed it. Maybe they shouldn't have that room for argument, but they do. But if you say "Do not backdate certs," you've given them one thing to get right, that is hard to get wrong by mistake. At that point, a backdated cert implies either malice or losing control of the raw private key material, both of which clearly demand revocation.

I know a couple reasons for a backdated cert. Here's one that is easy to explain: backdated clients + emergencies. At least one in a million client devices is backdated by more than three days. It is therefore prudent to wait until a week or more past NotBefore before deploying a cert.

If you need a new certificate in a terrible rush, you can backdate.

Now, that's not what happened here. I would chalk this up to a cultural shift between the Americans and Europeans making the rules at the CA/B forum and the WoSign folks who honestly never imagined they would be expected to comply with rules that couldn't be checked---that a rule would say "don't sign sha-1 after Jan 1" as opposed to "don't sign sha-1 with a NotBefore after Jan 1."

Hm, that's a fair reason. But really what's important here is the fixed CT cutoff date. If you have mandatory CT from October 1 onwards, it seems fine to promise that you'll actually do CT for all certs with a notBefore of September 24 or later, and on October 1, you will stop issuing certs with a notBefore earlier than September 24.

(Of course the complexity now re-introduces some room for "honest" mistakes.)

They never imagined they would be expected to comply with rules they explicitly agreed to?

> Of course, Mozilla needs to add support for CT for this approach to work.

Is there any chance of this happening?

Yes.