[kevingadd]

Aside from the necessity of enforcing good security policy here, it's brutal to observe the situation Actalis was stuck in based on the thread's ongoing comments. They clearly got themselves into bad/unsustainable deals with big customers where they made promises that couldn't be fulfilled in these circumstances, so their choices were to (likely) lose those customers + harm their customers' users, or to risk getting kicked out of the root program. And if they don't play their cards right it's possible they BOTH lose their customers and get booted out of the root program eventually anyway. Not a fun situation to be in, especially because in this case it sounds like they got screwed by a bug in third-party software and not specifically due to bad internal processes.

[mghilardi]

I think Actalis found itself between a very hard rock and an even harder place. I am italian and I have worked with some public entities similar to the ones Actalis provided certificates to. There is a private network "SPC" of public italian organizations, with many machine-to-machine HTTPS web services that MUST by law provide updates to the central government with quite strict deadlines.

On such networks, certificate pinning is very common and possibly even recommended, contrary to the "Basic Requirements" and recommendations of CAs.

Failing to respect such deadlines causes penalties to the local governments, and in grave cases may even be a crime: "public service interruption" which would initiate a trial, with more fines and possibly jail time.

Thus Actalis had to choose between:

1. follow the CAs "Basic Requirements" that force CAs to quickly revoke certificates when a problem is discovered. Then most of the certificates would be revoked before the public customers managed to replace them - disrupting their operativity, risking penalties for the missed deadlines and possibly trial and jail time for "public service interruption". To avoid this, they would then need to demonstrate in a public trial that the public customers were well informed that certificates could be revoked and re-issued at any time with very short warning time, and they did everything they could to avoid the "public service interruption", both pre-emptively (when negotiating the sell of certificates and educating the customers) and re-actively (when the serial numbers vulnerability was discovered). Quite a hard path.

2. contact the customers, push them to quickly replace the compromised certificates, and revoke them only afterwards, thus avoiding service disruptions.

They chose 2. Unluckily italian public organizations are very slow, which in the end caused Actalis to miss their BR deadlines by a long shot.

[carapace]

Thank you! Reading between the lines it seemed clear that just revoking the certs would have caused major infrastructure problems, but what you describe sounds severe. No wonder they chose to take the hit in BR deadlines!

[makomk]

Oh, this is nothing. A while back the browser vendors decided that since underscores weren't technically allowed in subdomain names, every CA who'd issued such certificates needed to revoke them all. It turned out that some of those certificates weren't terribly easy to replace. In particular, a whole bunch were in use by a health insurance enrollment system that was right in the middle of the main enrollment period and because of that could only receive changes that were absolutely essential. So the CA ended up missing the deadline to revoke them by a few months in order to keep this all working. The annointed enforcers of the CA rules were, of course, utterly pissed that their underscore pedanticism wasn't considered important enough to risk people losing access to healthcare for, pointing out that they could certainly deploy a fix if there was some critical security issue so why couldn't they do it for this?

[tialaramex]

Not a bug, but let's say a "shortcoming". EJBCA felt they'd clearly documented what this did, their users not so much.

And the defence against this stuff is curiosity - which is internal process. If you issue lots of certificates (say, more than a dozen) and you find that the "64-bit" integers in them actually only vary in 63 bits you ought to be suspicious. If Actalis (or other CAs) had declared "Hi, we found out about this after two weeks when we looked at our serial numbers more closely" instead of waiting for the problem with EJBCA to get called out explicitly I'd have _way_ more sympathy.

Likewise if you're sure you are implementing 3.2.2.4.6 Agreed‐Upon Change to Website, curiosity would suggest it's worth taking a look at some of those agreed upon changes and how they were verified, and how some failed. No failures at all? Well that's weird, let's look more closely - oh, we're counting 404 errors as success. Oops. (Yes a real public CA did this and in their case they did find it before someone else reported it).