it is trying its best to bruteforce the key that was used to sign the "invalid" CRLs as we speak but the search has yielded not a single hint yet.
this theory can't be definitively proven, but it can be definitively proven by reproducing the key, and that doesnt seem to happen with its attempts so far
CALLLLLLLLLLLLLLLLLLLLLLLED ITTTTTTTTTTTTTTTTTTTTTTTTTTT
The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.
also, this entire ordeal could have been prevented by SIMPLY NOT TESTING IN PROD, and this testing in prod was APPROVED BY EVERYONE INVOLVED
there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
(emphasis mine; source)
eMudhra should, under no circumstances, ever be trusted again
from some rudimentary attempts to verify their story with a soft hsm, it seems to all check out. a plausible story does not mean that there was no malice behind it, but if they fucked around with wrapping, they may genuinely have done this as a honest mistake with many, many preventable steps
it is actually plausible that this was an honest mistake aber den salat haben wir jetzt trotzdem
the only thing really giving it the creeps is this sentence:
d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root
by looking at the notBefore fields, we can see that they are not created in batch:
15:35:09 DV TLS G3C
15:37:41 OV TLS G3C
15:39:31 EV TLS G3C
15:54:08 DV TLS G3B
16:00:12 OV TLS G3B
16:03:31 EV TLS G3B
16:08:27 OV CS G3B
16:38:40 OV CS G3C
so, was this mistake made in a script somewhere, or did a human make this mistake 8 times?
it seems more plausible for this mistake to happen once in its opinion, and not 8 times
@49016 That feels like what one would see if the mistake was encoded in the plan for a signing ceremony and then everyone involved faithfully followed the plan without engaging brain properly