Doppelganger/tripleganger intermediate certificates

[Rob Stradling]

Several CAs have issued intermediate CA certificates with duplicate
serial numbers. This is a clear violation of the serial number
uniqueness requirement of the BRs and RFC5280 4.1.2.2. Below is a list
of all those known to crt.sh that chain to at least 1 NSS built-in root:


Issuer: https://crt.sh/?caid=140
Issuer O: AC Camerfirma SA CIF A82743287
Issuer CN: Chambers of Commerce Root
Subject CN: (id=1252) AC CAMERFIRMA AAPP
(id=12625404) AC Camerfirma Express Corporate Server
Serial #: 0d
Certs: https://crt.sh/?id=1252
https://crt.sh/?id=12625404
Revoked?: No


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


Issuer: https://crt.sh/?caid=941
Issuer O: Atos
Issuer CN: Atos TrustedRoot 2011
Subject CN: Atos TrustedRoot Client-CA 2011
Serial #: 5b:6a:8e:8d:5a:86:71:8f
Certs: https://crt.sh/?id=12725513
https://crt.sh/?id=12725727
https://crt.sh/?id=12728899
Revoked?: No
Subject CN: Atos TrustedRoot CodeSigning-CA 2011
Serial #: 33:45:52:39:ec:16:dd:62
Certs: https://crt.sh/?id=18068233
https://crt.sh/?id=49643406
Revoked?: Yes
Subject CN: Atos TrustedRoot Server-CA 2011
Serial #: 6b:5d:91:bc:13:61:ce:75
Certs: https://crt.sh/?id=705899
https://crt.sh/?id=18068212
Revoked?: Yes


Issuer: https://crt.sh/?caid=138
Issuer O: SwissSign AG
Issuer CN: SwissSign Gold CA - G2
Subject CN: AffirmTrust Networking
Serial #: 84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9
Certs: https://crt.sh/?id=3386
https://crt.sh/?id=1991456
Revoked?: No
Subject CN: Trend Micro Gold CA
Serial #: 49:e1:33:6e:94:e5:b6:a5:2d:a9:6e:d4:8a:e2:76
Certs: https://crt.sh/?id=12629343
https://crt.sh/?id=198226194
Revoked?: Yes


Issuer: https://crt.sh/?caid=656
Issuer O: Trustwave Holdings, Inc.
Issuer CN: Trustwave Organization Issuing CA, Level 2
Subject CN: Trustwave Enterprise CA
Serial #: 6b:49:d2:04
Certs: https://crt.sh/?id=12624965
https://crt.sh/?id=12629351
Revoked?: Issuer cert revoked (https://crt.sh/?id=95565)

Issuer: https://crt.sh/?caid=12391
Issuer O: Trustwave Holdings, Inc.
Issuer CN: Trustwave Enterprise CA
Subject CN: Trustwave Enterprise VPN CA
Serial #: 41:90:ae:5d
Certs: https://crt.sh/?id=12625419
https://crt.sh/?id=12629788
Revoked?: Issuer's issuer cert revoked (https://crt.sh/?id=95565)


Issuer: https://crt.sh/?caid=1450
Issuer O: WoSign CA Limited
Issuer CN: CA 沃通根证书
Subject CN: 中国湖南 EV 服务器证书
Serial #: 44:80:7b:20:7c:f2:05:2e:8d:34:11:77:02:66:d2:95
Certs: https://crt.sh/?id=7841622
https://crt.sh/?id=9318242
Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots
still in NSS)
Subject CN: CA 沃通 EV 代码签名证书
Serial #: 3a:de:c4:02:27:0b:f4:ee:9e:89:2c:c6:5e:0a:da:21
Certs: https://crt.sh/?id=12728869
https://crt.sh/?id=12729072
Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots
still in NSS)


P.S. Here's the query I ran on crt.sh to find these certs:

select count(*), min(c.id), max(c.id), c.issuer_ca_id,
encode(x509_serialNumber(c.certificate), 'hex') from certificate c,
ca_certificate cac where c.id=cac.certificate_id and exists (select 1
from ca_trust_purpose ctp where ctp.ca_id = c.issuer_ca_id and
ctp.trust_context_id=5) group by c.issuer_ca_id,
x509_serialNumber(c.certificate) having count(*) > 1 order by count(*) desc;

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Adriano Santoni]

We started investigating on this.

[Ramiro Muñoz]

AC Camerfirma is looking into this issue.

regards

Ramiro Muñoz Muñoz
AC Camerfirma SA.
CTO, Exploitation Manager, CISA.
+34 619 746 291 · ram...@camerfirma.com.
https://www.linkedin.com/in/ramirom.
________________________________________
¿ Has probado c-Office ?
firma de documentos, factura electrónica, puesta a disposición, notificaciones fehacientes y mucho, mucho más.. https://www.c-office.es

[Reinhard Dietrich]

Thanks, Rob, for the investigation. We detected that the certificates were incorrectly issued in 2009 with a double serial number. The CA software used in recent years had special protection against abusive issuing and revocation of certificates with the same serial number. This led to the situation that the certificate could not yet be officially revoked in our CRL by normal operational procedure. We have already discussed the right options with the operators of the root stores. We will continue to try to circumvent the protection of our CRLs for these certificates and to allow the use of same serial number in our CRL despite different certificates (as an exception).

We will inform in this thread about our next steps.
Reinhard Dietrich
SwissSign

[Adriano Santoni]

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

[Rob Stradling]

Hi Adriano. Thanks for providing your incident report so promptly.

Some questions inline...

On 02/10/17 15:26, Adriano Santoni via dev-security-policy wrote:
<snip>

> 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;

Are these "temporary unconstrained SubCA certificate"s publicly trusted?
That is, do they have valid signatures from your "Actalis
Authentication Root CA" (https://crt.sh/?caid=935) ?

If yes, can you confirm that you have disclosed them all to the CCADB?

<snip>

> 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.

Are you suggesting that "discarding" a certificate makes it acceptable
to reuse the same serial number in another certificate?

<snip>

> - revocation of the affected SubCA certificate is scheduled for Oct 4th,
> EOB.

Nit: revocation of *both* affected SubCA certificates, since they share
the same serial number.

[Nick Lamb]

The "post-processing" element is confusing, and could do with a bit more explanation unless perhaps I'm the fool here and everybody else (m.d.s.policy regulars) understands how this works

Since the name constraints are part of the signed document, altering them after it's signed would invalidate the signature. So surely that can't be what happens.

On the other hand, if the thing being "post-processed" is a tbsCertificate rather than a signed certificate surely that can be created using whatever processes are convenient entirely outside the protected physical environment and prior to the ceremony commencing? At most it may be appropriate for the serial number to be chosen during the protected process, to assure auditors that this was random rather than chosen by a third party.

I guess the thing I'm seeking clarity on is whether a "temporary unconstrained subCA" actually exists as a signed document, even momentarily within the protected physical environment, and if so, how that could possibly be necessary. Regardless of whether that's the case, the proposed remedial actions are appropriate, but if there are sketchy "temporary" unconstrained subCAs being created (and hopefully destroyed) then it seems important to emphasise to other CAs that this is not an acceptable practice.

[Kathleen Wilson]

On Friday, September 29, 2017 at 1:29:26 PM UTC-7, Rob Stradling wrote:
> Several CAs have issued intermediate CA certificates with duplicate
> serial numbers. This is a clear violation of the serial number
> uniqueness requirement of the BRs and RFC5280 4.1.2.2. Below is a list
> of all those known to crt.sh that chain to at least 1 NSS built-in root:
>

Thanks, Rob. I plan to file Bugzilla Bugs for these (for those not already filed), and request that these CAs scan their databases for all certs with same issuer/serial and provide an incident report.

But before doing so, I compared your finding with what I see in the CCADB...

>
> Issuer: https://crt.sh/?caid=140
> Issuer O: AC Camerfirma SA CIF A82743287
> Issuer CN: Chambers of Commerce Root
> Subject CN: (id=1252) AC CAMERFIRMA AAPP
> (id=12625404) AC Camerfirma Express Corporate Server
> Serial #: 0d
> Certs: https://crt.sh/?id=1252
> https://crt.sh/?id=12625404
> Revoked?: No
>

I see these Camerfirma doppelgangers in the CCADB.

>
> 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

I am not finding these Actalis certs in the CCADB. Will include that in the Actalis bug as well.

By the way, I do not see them listed here:
https://crt.sh/mozilla-disclosures#undisclosed

>
>
> Issuer: https://crt.sh/?caid=941
> Issuer O: Atos
> Issuer CN: Atos TrustedRoot 2011
> Subject CN: Atos TrustedRoot Client-CA 2011
> Serial #: 5b:6a:8e:8d:5a:86:71:8f
> Certs: https://crt.sh/?id=12725513
> https://crt.sh/?id=12725727
> https://crt.sh/?id=12728899
> Revoked?: No
> Subject CN: Atos TrustedRoot CodeSigning-CA 2011
> Serial #: 33:45:52:39:ec:16:dd:62
> Certs: https://crt.sh/?id=18068233
> https://crt.sh/?id=49643406
> Revoked?: Yes
> Subject CN: Atos TrustedRoot Server-CA 2011
> Serial #: 6b:5d:91:bc:13:61:ce:75
> Certs: https://crt.sh/?id=705899
> https://crt.sh/?id=18068212
> Revoked?: Yes

I see these Atos doppelgangers in the CCADB.

>
>
> Issuer: https://crt.sh/?caid=138
> Issuer O: SwissSign AG
> Issuer CN: SwissSign Gold CA - G2
> Subject CN: AffirmTrust Networking
> Serial #: 84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9
> Certs: https://crt.sh/?id=3386
> https://crt.sh/?id=1991456
> Revoked?: No
> Subject CN: Trend Micro Gold CA
> Serial #: 49:e1:33:6e:94:e5:b6:a5:2d:a9:6e:d4:8a:e2:76
> Certs: https://crt.sh/?id=12629343
> https://crt.sh/?id=198226194
> Revoked?: Yes

I see these SwissSign doppelgangers in the CCADB.

>
>
> Issuer: https://crt.sh/?caid=656
> Issuer O: Trustwave Holdings, Inc.
> Issuer CN: Trustwave Organization Issuing CA, Level 2
> Subject CN: Trustwave Enterprise CA
> Serial #: 6b:49:d2:04
> Certs: https://crt.sh/?id=12624965
> https://crt.sh/?id=12629351
> Revoked?: Issuer cert revoked (https://crt.sh/?id=95565)
>
> Issuer: https://crt.sh/?caid=12391
> Issuer O: Trustwave Holdings, Inc.
> Issuer CN: Trustwave Enterprise CA
> Subject CN: Trustwave Enterprise VPN CA
> Serial #: 41:90:ae:5d
> Certs: https://crt.sh/?id=12625419
> https://crt.sh/?id=12629788
> Revoked?: Issuer's issuer cert revoked (https://crt.sh/?id=95565)

I see the revoked issuer is in CCADB. The other certs are not, but that's OK since the revoked issuer is in OneCRL.

>
>
> Issuer: https://crt.sh/?caid=1450
> Issuer O: WoSign CA Limited
> Issuer CN: CA 沃通根证书
> Subject CN: 中国湖南 EV 服务器证书
> Serial #: 44:80:7b:20:7c:f2:05:2e:8d:34:11:77:02:66:d2:95
> Certs: https://crt.sh/?id=7841622
> https://crt.sh/?id=9318242
> Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots
> still in NSS)
> Subject CN: CA 沃通 EV 代码签名证书
> Serial #: 3a:de:c4:02:27:0b:f4:ee:9e:89:2c:c6:5e:0a:da:21
> Certs: https://crt.sh/?id=12728869
> https://crt.sh/?id=12729072
> Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots
> still in NSS)

I don't plan to file a bug for these WoSign doppelganger certs, since we've already disabled and are removing the WoSign roots (bug #1387260).



Also, I see another set of dobbelganger certs in the CCADB. Not sure why they didn't show up in your script output...

Issuer commonName: Belgium Root CA4
Subject commonName: Belgium Root CA4
Serial Number: 4f33208cc594bf38
https://crt.sh/?id=26311649
https://crt.sh/?id=160110886
Revoked? No

Thanks,
Kathleen

[Adriano Santoni]

Kathleen,

you do not see such subordinate in CCADB because it's a technically
constrained subordinate, and there is no requirement (to date) to
disclose technically constrained subordinates.

At any rate, I confirmed our issuance of such subordinate in my response
to Gerv on 15/5/2017 when he asked ...

"Also, am I right in thinking that Actalis has recently
cross-signedUniCredit?

https://crt.sh/?id=47081615

"

I can easily find such subordinate in
https://crt.sh/mozilla-disclosures#undisclosed.
Actually there are two almost identical entries, alas, because of the
doppelganger issue that we were not aware of until Sep 30, when we read
the warning from Rob Stradling posted on m.d.s.p.

As I wrote in my report of Oct 2nd, today we are going to revoke the two
doppelgangers.

Adriano

Il 03/10/2017 18:50, Kathleen Wilson 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

[Rob Stradling]

On 03/10/17 17:50, Kathleen Wilson via dev-security-policy wrote:
> On Friday, September 29, 2017 at 1:29:26 PM UTC-7, Rob Stradling wrote:

>> Several CAs have issued intermediate CA certificates with duplicate
>> serial numbers. This is a clear violation of the serial number
>> uniqueness requirement of the BRs and RFC5280 4.1.2.2. Below is a list
>> of all those known to crt.sh that chain to at least 1 NSS built-in root:
>>
>
>

> Thanks, Rob. I plan to file Bugzilla Bugs for these (for those not already filed), and request that these CAs scan their databases for all certs with same issuer/serial and provide an incident report.
>
> But before doing so, I compared your finding with what I see in the CCADB...

<snip>

>> Issuer: https://crt.sh/?caid=1450
>> Issuer O: WoSign CA Limited
>> Issuer CN: CA 沃通根证书
>> Subject CN: 中国湖南 EV 服务器证书
>> Serial #: 44:80:7b:20:7c:f2:05:2e:8d:34:11:77:02:66:d2:95
>> Certs: https://crt.sh/?id=7841622
>> https://crt.sh/?id=9318242
>> Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots
>> still in NSS)
>> Subject CN: CA 沃通 EV 代码签名证书
>> Serial #: 3a:de:c4:02:27:0b:f4:ee:9e:89:2c:c6:5e:0a:da:21
>> Certs: https://crt.sh/?id=12728869
>> https://crt.sh/?id=12729072
>> Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots
>> still in NSS)
>

> I don't plan to file a bug for these WoSign doppelganger certs, since we've already disabled and are removing the WoSign roots (bug #1387260).

That seems reasonable. I realize the old WoSign and StartCom roots are
already (semi-)disabled in Firefox, but since they've not yet been
removed from NSS I considered them to be in scope for this report (for
the benefit of any other consumers of the NSS trust list).

> Also, I see another set of dobbelganger certs in the CCADB. Not sure why they didn't show up in your script output...
>
> Issuer commonName: Belgium Root CA4
> Subject commonName: Belgium Root CA4
> Serial Number: 4f33208cc594bf38
> https://crt.sh/?id=26311649
> https://crt.sh/?id=160110886
> Revoked? No

My query did find those two "Belgium Root CA4" certs, but (rightly or
wrongly) I decided to omit them from my report. They're both
self-signed root certs rather than intermediates, although there are
other trust paths from the "Belgium Root CA4" CA up to a root that's
included in NSS.

FWIW, I also found one other pair of self-signed root certs that share a
serial number, although there are no longer any known unrevoked trust
paths from this CA up to a root that's included in NSS:

Issuer commonName: Common Policy
Subject commonName: Common Policy
Serial Number: 29:36:47:aa:e3:8a:ac:86:4a:23:56:f2:ca:b7:61:af
Certs: https://crt.sh/?id=20444
https://crt.sh/?id=26310636

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Adriano Santoni]

Hi Rob,

sorry for the slight delay; see my answers below:

Il 02/10/2017 17:03, Rob Stradling via dev-security-policy ha scritto:
> Hi Adriano.  Thanks for providing your incident report so promptly.
>
> Some questions inline...
>
> On 02/10/17 15:26, Adriano Santoni via dev-security-policy wrote:
> <snip>
>> 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;
>
> Are these "temporary unconstrained SubCA certificate"s publicly
> trusted?  That is, do they have valid signatures from your "Actalis
> Authentication Root CA" (https://crt.sh/?caid=935) ?
> If yes, can you confirm that you have disclosed them all to the CCADB?

No. The temporary unconstrained SubCA certificate is not trusted,
because it is post-processed when it still is a tbsCertificate. When it
comes into existence as a signed object, it already is a technically
constrained certificate. As such, it is not required to disclose it to
the CCADB.

>
>> 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.
>
> Are you suggesting that "discarding" a certificate makes it acceptable
> to reuse the same serial number in another certificate?

I am not suggesting anything like that. Our operating instructions
implied that post-processing would be executed only once, but the
post-processing software module in itself did not prevent a second run.
Due to the fact that it was the first time we had to perform such task,
and because the operating instructions did not expressly prohibit that,
our staff mistakenly decided to trigger a second run in order to update
the same certificate upon receiving, unexpectedly, an updated list of
domains from Unicredit on that same day without notice. Unfortunately,
on that occasion, the result of the first run had been already sent to
Unicredit.

>
>> - revocation of the affected SubCA certificate is scheduled for Oct
>> 4th, EOB.
>
> Nit: revocation of *both* affected SubCA certificates, since they
> share the same serial number.
>

Yes.

----
Adriano Santoni
ACTALIS S.p.A.

[Rob Stradling]

On 04/10/17 13:18, Adriano Santoni via dev-security-policy wrote:
<snip>

>> Are these "temporary unconstrained SubCA certificate"s publicly
>> trusted?  That is, do they have valid signatures from your "Actalis
>> Authentication Root CA" (https://crt.sh/?caid=935) ?
>> If yes, can you confirm that you have disclosed them all to the CCADB?
>
> No. The temporary unconstrained SubCA certificate is not trusted,
> because it is post-processed when it still is a tbsCertificate. When it
> comes into existence as a signed object, it already is a technically
> constrained certificate. As such, it is not required to disclose it to
> the CCADB.

Great. Thanks for clarifying that, Adriano.

[Adriano Santoni]

Nick,

I think I have addressed this in my reply to Rob Stradling a few minutes
ago.

In short: no, the "temporary unconstrained subCA" does never exist as a
signed document, only the final (constrained) subCA is signed.

Adriano

[ramiro...@gmail.com]

>
> Issuer: https://crt.sh/?caid=140
> Issuer O: AC Camerfirma SA CIF A82743287
> Issuer CN: Chambers of Commerce Root
> Subject CN: (id=1252) AC CAMERFIRMA AAPP
> (id=12625404) AC Camerfirma Express Corporate Server
> Serial #: 0d
> Certs: https://crt.sh/?id=1252
> https://crt.sh/?id=12625404
> Revoked?: No

Hi Rob
Here the incident report from Camerfirma:

1) How your CA first became aware of the problem

Affected certificates
Serial number:0d dates:15 Nov-2007 to 8-Nov-2032 Name:AC Camerfirma Express corporate Server(1)
Serial number:0d dates:23 Feb-2010 to 20-Feb-2022 Name:AC Camerfirma AAPP(2).

We were aware some time later of Febr 2010 after issuing the (2) SubCA when we already had issued valid certificates.

2) A timeline of the actions your CA took in response.

The SubCA (1) was an internal CA to issue only 6 test certificates. This SubCA is not used anymore since 08-11-2014.

Certificates issued by SubCA (1)
/C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=127.0.0.1/emailAddress=in...@camerfirma.com/serialNumber=A99999999
/C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma SA/OU=Sistemas/CN=*.camerfirma.com/emailAddress=admin-s...@camerfirma.com/serialNumber=A82743287
/C=ES/ST=Avila/L=Avila/O=AC Camerfirma SA/OU=Sistemas/CN=*.camerfirma.com/emailAddress=admin-s...@camerfirma.com/serialNumber=A82743287
/C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_valido/emailAddress=in...@camerfirma.com/serialNumber=A99999999
/C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_revocado/emailAddress=in...@camerfirma.com/serialNumber=A99999999
/C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_caducado/emailAddress=in...@camerfirma.com/serialNumber=A99999999

3) Whether your CA has stopped, or has not yet stopped, issuing TLS/SSL

The SubCA (1) issue no certificates since since 08-11-2014.

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.

See answer 1.

5) The complete certificate data for the problematic certificates.

See answer 1.

6) Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.

The generation of SubCA certificates is done
manually, in the protected physical environment of our Root CA off-line,

with the prior authorization of our management and in the presence of our internal auditor.

We used a wrong template in the creation SubCA process.
We reviewed the templates and classified them to avoid new problems.
This control has been effective since no other similar problem has arisen so far.

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.

Templates are now approved by the tech management and review by our internal auditor before going into production.

Regards
Ramiro

[Kathleen Wilson]

Bugs filed, or already existed…

To the CAs who have already responded here in this discussion, please also copy-paste your incident report into the bug.

> >
> > Issuer: https://crt.sh/?caid=140
> > Issuer O: AC Camerfirma SA CIF A82743287
> > Issuer CN: Chambers of Commerce Root
> > Subject CN: (id=1252) AC CAMERFIRMA AAPP
> > (id=12625404) AC Camerfirma Express Corporate Server
> > Serial #: 0d
> > Certs: https://crt.sh/?id=1252
> > https://crt.sh/?id=12625404
> > Revoked?: No
> >
>

> I see these Camerfirma doppelgangers in the CCADB.

https://bugzilla.mozilla.org/show_bug.cgi?id=1405815

>
> >
> > 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
>
>

> I am not finding these Actalis certs in the CCADB. Will include that in the Actalis bug as well.
>
> By the way, I do not see them listed here:
> https://crt.sh/mozilla-disclosures#undisclosed
>

https://bugzilla.mozilla.org/show_bug.cgi?id=1405817

> >
> >
> > Issuer: https://crt.sh/?caid=941
> > Issuer O: Atos
> > Issuer CN: Atos TrustedRoot 2011
> > Subject CN: Atos TrustedRoot Client-CA 2011
> > Serial #: 5b:6a:8e:8d:5a:86:71:8f
> > Certs: https://crt.sh/?id=12725513
> > https://crt.sh/?id=12725727
> > https://crt.sh/?id=12728899
> > Revoked?: No
> > Subject CN: Atos TrustedRoot CodeSigning-CA 2011
> > Serial #: 33:45:52:39:ec:16:dd:62
> > Certs: https://crt.sh/?id=18068233
> > https://crt.sh/?id=49643406
> > Revoked?: Yes
> > Subject CN: Atos TrustedRoot Server-CA 2011
> > Serial #: 6b:5d:91:bc:13:61:ce:75
> > Certs: https://crt.sh/?id=705899
> > https://crt.sh/?id=18068212
> > Revoked?: Yes
>
>

> I see these Atos doppelgangers in the CCADB.
>
>

https://bugzilla.mozilla.org/show_bug.cgi?id=1329223

> >
> >
> > Issuer: https://crt.sh/?caid=138
> > Issuer O: SwissSign AG
> > Issuer CN: SwissSign Gold CA - G2
> > Subject CN: AffirmTrust Networking
> > Serial #: 84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9
> > Certs: https://crt.sh/?id=3386
> > https://crt.sh/?id=1991456
> > Revoked?: No
> > Subject CN: Trend Micro Gold CA
> > Serial #: 49:e1:33:6e:94:e5:b6:a5:2d:a9:6e:d4:8a:e2:76
> > Certs: https://crt.sh/?id=12629343
> > https://crt.sh/?id=198226194
> > Revoked?: Yes
>

> I see these SwissSign doppelgangers in the CCADB.
>

https://bugzilla.mozilla.org/show_bug.cgi?id=1404403

> >
> >
> > Issuer: https://crt.sh/?caid=656
> > Issuer O: Trustwave Holdings, Inc.
> > Issuer CN: Trustwave Organization Issuing CA, Level 2
> > Subject CN: Trustwave Enterprise CA
> > Serial #: 6b:49:d2:04
> > Certs: https://crt.sh/?id=12624965
> > https://crt.sh/?id=12629351
> > Revoked?: Issuer cert revoked (https://crt.sh/?id=95565)
> >
> > Issuer: https://crt.sh/?caid=12391
> > Issuer O: Trustwave Holdings, Inc.
> > Issuer CN: Trustwave Enterprise CA
> > Subject CN: Trustwave Enterprise VPN CA
> > Serial #: 41:90:ae:5d
> > Certs: https://crt.sh/?id=12625419
> > https://crt.sh/?id=12629788
> > Revoked?: Issuer's issuer cert revoked (https://crt.sh/?id=95565)
>
>

> I see the revoked issuer is in CCADB. The other certs are not, but that's OK since the revoked issuer is in OneCRL.
>

https://bugzilla.mozilla.org/show_bug.cgi?id=1405826


Thanks,
Kathleen

[Nick Lamb]

On Wednesday, 4 October 2017 13:34:17 UTC+1, Adriano Santoni wrote:
> Nick,
>
> I think I have addressed this in my reply to Rob Stradling a few minutes
> ago.
>
> In short: no, the "temporary unconstrained subCA" does never exist as a
> signed document, only the final (constrained) subCA is signed.

Thank you Adriano,

I agree your reply covers that. I still don't think I understand how "post-processing" came to be a necessary element of this process but since your planned remediation eliminates this anyway and we've established that there's never a signed unconstrained subCA even momentarily I don't think we need to dig into this any deeper, thank you for taking the time to reply.

[Peter Gutmann]

ramirommunoz--- via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>1) How your CA first became aware of the problem
>Affected certificates
>Serial number:0d dates:15 Nov-2007 to 8-Nov-2032 Name:AC Camerfirma Express corporate Server(1)
>Serial number:0d dates:23 Feb-2010 to 20-Feb-2022 Name:AC Camerfirma AAPP(2).
>
>We were aware some time later of Febr 2010 after issuing the (2) SubCA when
>we already had issued valid certificates.

So just to confirm this, the CA has known about these invalid certificates for
SEVEN YEARS and is only now taking action over them?

Do the BR's contain any text on timeliness of action, or is it like the Swiss
plan to shut down their reactors? (German plan: We've voted to shut them
down, here's the schedule. Swiss plan: We've voted to shut them down, and now
we've finished voting on shutting them down).

Peter.

[Ramiro Muñoz]

Hi Peter

When we realize the problem there were many certificates issued by the newer
SubCA and taken into account that the older SubCA only issued a few
"internal use" certificates (6) and it has never been used since then . We
found neither security nor administrative problem in maintain this
situation. The problem appeared when we disclose this UNUSED CA in the
CCADB.

Best Regard

Ramiro Muñoz Muñoz
AC Camerfirma SA.
CTO, Exploitation Manager, CISA.
+34 619 746 291 · ram...@camerfirma.com.
https://www.linkedin.com/in/ramirom.
________________________________________
¿ Has probado c-Office ?
firma de documentos, factura electrónica, puesta a disposición,
notificaciones fehacientes y mucho, mucho más.. https://www.c-office.es

-----Mensaje original-----
De: dev-security-policy
[mailto:dev-security-policy-bounces+ramirom=camerfi...@lists.mozilla.org
] En nombre de Peter Gutmann via dev-security-policy
Enviado el: martes, 10 de octubre de 2017 8:37
Para: mozilla-dev-s...@lists.mozilla.org; ramiro...@gmail.com
Asunto: Re: Doppelganger/tripleganger intermediate certificates

[Rob Stradling]

Hi Adriano.

It was pointed out to me that the doppelganger intermediate certificates
that Actalis issued to Unicredit (https://crt.sh/?id=47081615 and
https://crt.sh/?id=147626411) don't quite meet Mozilla's current
"technically constrained" criteria.

Since v2.3, the Mozilla Root Store Policy has referenced BR 7.1.5, which
says (emphasis mine):
"If the Subordinate CA Certificate includes the id‐kp‐serverAuth
extended key usage, then the Subordinate CA Certificate MUST include the
Name Constraints X.509v3 extension with constraints on dNSName,
iPAddress *and DirectoryName*".

(In v2.2, "technically constrained" was defined within the Mozilla
policy itself, and that definition did not require a DirectoryName
constraint).

I suspect that the DirectoryName constraint requirement was added to the
BRs due to Windows XP's weird behaviour when processing a Name
Constraints extension that lacks a DirectoryName constraint (see
https://unmitigatedrisk.com/?p=201).

I've just adjusted my crt.sh code to enforce the DirectoryName
constraint requirement, and so the two Unicredit intermediates now
appear under https://crt.sh/mozilla-disclosures#undisclosed

On 04/10/17 13:33, Adriano Santoni via dev-security-policy wrote:
> Nick,
>
> I think I have addressed this in my reply to Rob Stradling a few minutes
> ago.
>
> In short: no, the "temporary unconstrained subCA" does never exist as a
> signed document, only the final (constrained) subCA is signed.
>

> Adriano
>
>
> Il 02/10/2017 20:57, Nick Lamb via dev-security-policy ha scritto:
>> The "post-processing" element is confusing, and could do with a bit
>> more explanation unless perhaps I'm the fool here and everybody else
>> (m.d.s.policy regulars) understands how this works
>>
>> Since the name constraints are part of the signed document, altering
>> them after it's signed would invalidate the signature. So surely that
>> can't be what happens.
>>
>> On the other hand, if the thing being "post-processed" is a
>> tbsCertificate rather than a signed certificate surely that can be
>> created using whatever processes are convenient entirely outside the
>> protected physical environment and prior to the ceremony commencing?
>> At most it may be appropriate for the serial number to be chosen
>> during the protected process, to assure auditors that this was random
>> rather than chosen by a third party.
>>
>> I guess the thing I'm seeking clarity on is whether a "temporary
>> unconstrained subCA" actually exists as a signed document, even
>> momentarily within the protected physical environment, and if so, how
>> that could possibly be necessary. Regardless of whether that's the
>> case, the proposed remedial actions are appropriate, but if there are
>> sketchy "temporary" unconstrained subCAs being created (and hopefully
>> destroyed) then it seems important to emphasise to other CAs that this
>> is not an acceptable practice.