It's not about a lack of support for SHA-256 on the CA side. But backdated SHA-1 certs are in demand because they allow other systems to keep working, systems like embedded/PoS computers that lack support for SHA-256, while simultaneously dodging errors on modern browsers that only allow SHA-1 certs if they were issued before a certain date.

Wosign was certainly capable of issuing SHA-256 certificates. But the customers needed SHA-1 certificates with a backdated issue timestamp. And Wosign was willing to fake the issue timestamp on new certificates, probably a lucrative market because no other reputable CA would be willing to do so.

> Wosign was certainly capable of issuing SHA-256 certificates. But the customers needed SHA-1 certificates with a backdated issue timestamp.

So they had a special side deal to get backdated certs? There's no way they were doing this for everybody or for "regular price" right?

Interestingly, several western sites also have side deals to get SHA1 certs backdated or otherwise whitelisted, including Google and CloudFlare.

Google is not doing this.

CloudFlare made a deal with Comodo to issue (non-backdated) SHA-1 certificates from a "legacy" root that is mostly no longer trusted by modern clients.

Symantec and Entrust are also issuing SHA-1 certificates from "legacy" roots to large enterprises.

"CloudFlare made a deal with Comodo to issue (non-backdated) SHA-1 certificates from a "legacy" root that is mostly no longer trusted by modern clients."

That's quite a nice solution.

The upside seems to be there's very little additional risk if certs are issued that "modern clients" won't accept - while still allowing "legacy clients" to commuicate with the level of security/encryption they always have.

I guess the downside is - allowing it to contniue means nobody will _ever_ upgrade or turn off "legacy client" equipment - which is probably all riddled with huge numbers of other "known exploits"... If you make it possible to put off upgrading your WindowsXP (or equivalent early 2000's linux based) POS system or industrial/SCADA gear - it'll stay around randomly switching which botnet it's DDoSing for forever...

This is a very interesting allegation. Do you have a link to any such backdated or whitelisted certificates? Where is the whitelist, and how does it work? Does all major SSL libraries, browsers, http clients (openssl, libressl, polarssl, gnutls, microsoft, apple, java, etc etc) implement the same whitelist?

A common approach is to get SHA-1 certificates signed by roots that have been pulled from various root programs, but are still (likely) present on outdated devices that do not support SHA-2 (like XP <= SP2). I think CloudFlare is using one of Comodo's removed roots[1] for this purpose.

Once a root certificate has been pulled from a root program, they stop being in scope for the root program policies and the Baseline Requirements (at least that's the common interpretation), which would prohibit SHA-1 issuance from those roots. There's been some discussion about changing this.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1208461

So the allegation that "western" sites somehow do similar shady deals falls flat on its face, because the Wosign situation is all about the actions of a trusted CA. There is no comparison between trusted CAs and other random/untrusted/removed CAs.

I'm sure plenty of "western" sites have attempted to get similar deals (FWIW, Tyro, one of the companies that got SHA-1 certificates from WoSign, is based in Australia), but I'm not aware of any other CA incidents like this one. Other CAs seem to either use pulled roots or go through the proper exception process for SHA-1 issuance in the CA/B Forum. No one else has been caught backdating SHA-1 certificates to my knowledge. (For now?)

(Symantec accidentally signed a SHA-1 certificate from a publicly-trusted root while preparing their SHA-1 issuance exception application, but that's not quite as bad, I guess.)

I did not claim they were doing anything shady, just that they got those certs through out-of-the-ordinary deals.

It would be a lot more justifiable (and far better for everyone involved) if, for example, the SHA1 certs through Comodo’s pulled root were available to everyone.

That's at best off topic. We're discussing the actions and trustworthyness of a currently trusted root CA here.

I dunno - there's an argument to be made (which I'm not sure which side I'd come down on" that having a trusted CA say "Oh _those_ certs? They're ones we issued from a no-longer-trusted-root of ours! We can do whatever we want with that!" is at best disingenuous and quite possibly just timeshifting abuse of trust. The "trust" lies in the organisation, not in the individual certs. Pulling them from the root program shouldn't absolve the organisation from continuing to treat them as security-critical and shouldn't absolve them from abiding by the rules for them.

I don't want to pick on Cloudflare or Comodo right now (see my other comment in here), but if someone were to propose a rule change that says a CA's trust obligations extend to all their old retired trusted roots as well as their current and future ones, I'd be inclined to agree unless I heard a very convincing argument against it (that had some strong protections in place to stop some of the obvious abuse possibiulities).

Thought experiment: what'd happen to a CA with root trust, if they negotiated to update a root cert, replaced their old one in all the trust stores, then sold their old private key to $badpeople?

There is a public exception process to handle SHA1 certificates, and for the rest, they get special certificates of old root certificates that are only on older devices.

Obviously, all these options are not available to anyone except a handful of large companies.

That's at best off topic again. We're discussing the actions and trustworthyness of a currently trusted root CA here.

Edit: The exception processes also do not involve fraudulently backdating anything. Which is kind of a big deal when you are in the trust business.

Doesn't matter they violated the chain of trust, the fact that they took extra money to do this doesn't make it any more or less of an offense.

EDIT: Was reading out of date info :)

~~However like some one else pointed out out of the discussion in the group looks like it was a technical bug, which is still bad, but at least not maliciously bad.~~ Gah HN why you still no do markdown....

It was definitively done on purpose based on customer requests. Look at the linked PDF, section 9.2.

Oh nvm, looks like link changed or i have clicked a different link I was reading the google groups thingie.