(In reply to Ryan Sleevi from comment #6)
Can you further clarify: are you running an in-house/custom CA software, or is this based on a common off-the-shelf commercial or open-source system?
I think the challenge here in understanding the flow of now your system works is that it sounds like you’re running some program on the offline CA to produce the CRL/ARL. That is, instead of producing a TBSCertList, which can be manually reviewed and linted before signing, it sounds like the process is integrated into a script that performs all of these steps automatically.
If that’s the case, I think there’s a question about understanding how that’s tested. The downside of such a scripted approach is that it can make it easy to forget to run in a testing environment, that the testing environment can differ from the production environment, or that errors that occurr in production don’t occur in testing. On the other hand, such a script can remove a lot of room for manual error, such as skipping steps, and so it’s not without its benefits.
The concern here is trying to go deeper than the specific incident at play here - such as the bug in the code that lead to wrong extensions, and trying to understand the process and design of the system, to understand if there are still systemic risks.
That said, to better help understand and confirm this explanation: Can you attach one of the invalid CRLs here, along with the
TBSCertList that successfully validates with the (invalid) signature? Basically, one way to help confirm that the explanation provided is what happened is to help demonstrate the “right”
TBSCertList that the signature was created for (e.g. without extensions). While this is something the community could try to work out manually, based on the description provided so far, the fact that iTrusChina has a better understanding of the bug hopefully makes it easier to provide these supporting artifacts. This is not meant to accuse you of impropriety, but rather, a useful process in incident reports (as with the previous comments) to provide detailed supporting technical artifacts.
We use a in house CA software developed by our R&D team.
The process of generation of CRL/ARL is not through scripts, but a program/function of our offline CA which performs all steps automatically.
As for the method of testing, our regular testing procedure is:
1, R&D team conducts self-test in the development environment;
2, Deploy and tested in the testing environment. We have test CA software and test HSM(with testing key pairs) exactly the same version as the production environment to trouble shooting and reproduce issues;
3, After testing work, deploy the software to production environment.
Attached is our invalid ARL and TBSCertList.
Thanks for your questions and suggestions, it will make us better understand what details the incident report should provide to make it clearer.