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.
>> _______________________________________________
>> dev-security-policy mailing list
>>
dev-secur...@lists.mozilla.org
>>
https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
> _______________________________________________
> dev-security-policy mailing list
>
dev-secur...@lists.mozilla.org
>
https://lists.mozilla.org/listinfo/dev-security-policy