Here's our full report on the issue. 1) How your CA first became aware of the problem
We first became aware that there was a potential issue on Sep 29th, at 22:28, upon reading an email from Rob Stradling with subject "Doppelganger/tripleganger intermediate certificates", sent to the mozilla.dev.security.policy discussion list.
2) A timeline of the actions your CA took in response.We read the email from Rob Stradling on Sep 30th and immediately started looking into the issue. We then reviewed our records, the contents of our Root CA database, our communications with Unicredit, and our procedures. We also interviewed our staff and cross-checked all the gathered evidences. We completed our investigation on Oct 2nd. A summary of our analysis is provided below (see point 6).
3) Whether your CA has stopped, or has not yet stopped, issuing TLS/SSL certificates with the problem.
The issue was caused by a human error made in a very infrequent circumstance. We know for sure that it happened only once, and are taking suitable measures to ensure that it will not happen again.
4) A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
Just the single doppelganger reported on by Stradling. 5) The complete certificate data for the problematic certificates. Already provided in the email from Rob Stradling.6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
In the particular case of the generation of technically constrained SubCA certificates, and only in that particular case, we use a special procedure that operates in two phases: first, we generate a temporary unconstrained SubCA certificate using our core Root CA software; then, we perform a post-processing of the same certificate with a separate software, in order to insert the necessary Name Constraints in it. We have developed this post-processing software to address some functional limitations of our current Root CA software.
Post-processing can be performed more than once, but, of course, only the result of the last run should be delivered to the owner organization. In this case post-processing was performed twice, as Unicredit provided us with an updated list of their domains (to be included in the NameConstraints extension) on the same day of the first run, at a time when the procedure had already been executed once and the first SubCA certificate had already been delivered to Unicredit.
Since it had been Unicredit itself to ask for regeneration of their SubCA certificate, on the very same day, our staff assumed that the first SubCA certificate would have been discarded; but apparently, due to some misunderstanding within Unicredit, it was mistakenly installed on some sites and then removed, but it probably remained online long enough for some crawler to detect it.
From this analysis, we conclude that our current post-processing procedure, although it performs its job properly, can cause problems if it is not used appropriately in particular circumstances.
We'd like to point out that the generation of SubCA certificates is done manually, in the protected physical environment of our Root CA (normally off-line), with the prior authorization of our management and in the presence of our internal auditor.
We found no other problematic situations of this kind.7) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
Immediate action:- revocation of the affected SubCA certificate is scheduled for Oct 4th, EOB.
Remedial actions to avoid re-occurrance of the same problem in the future:- update to our SubCA post-processing software so that it cannot be executed more than once on the same certificate; - update of the reference manual of SubCA post-processing software and the CA certificates generation procedure, with clarifications on how similar situations must be handled; - at the earliest opportunity, upgrade of our Root CA software so that post-processing of SubCA certificates is no longer required; - awareness meeting with the CA staff to clarify what happened, what caused the issue, and how the staff must behave in such circumstances.
Thanks to Rob Stradling for bringing this issue to our attention. Adriano Santoni ACTALIS S.p.A. Il 02/10/2017 07:54, Adriano Santoni via dev-security-policy ha scritto:
We have almost completed our analysis. I will post a report shortly. Il 30/09/2017 15:51, Adriano Santoni via dev-security-policy ha scritto:We started investigating on this. Il 29/09/2017 22:28, Rob Stradling via dev-security-policy ha scritto:Issuer: https://crt.sh/?caid=935 Issuer O: Actalis S.p.A./03358520967 Issuer CN: Actalis Authentication Root CA Subject CN: UniCredit Subordinate External Serial #: 3e:5d:be:44:e7:51:5a:5a Certs: https://crt.sh/?id=47081615 https://crt.sh/?id=147626411 Revoked?: No_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
