Re: Doppelganger/tripleganger intermediate certificates
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. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Doppelganger/tripleganger intermediate certificates
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 · rami...@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=camerfirma@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-security-pol...@lists.mozilla.org; ramirommu...@gmail.com Asunto: Re: Doppelganger/tripleganger intermediate certificates ramirommunoz--- via dev-security-policy 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
ramirommunoz--- via dev-security-policy 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
> > 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=i...@camerfirma.com/serialNumber=A /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma SA/OU=Sistemas/CN=*.camerfirma.com/emailAddress=admin-siste...@camerfirma.com/serialNumber=A82743287 /C=ES/ST=Avila/L=Avila/O=AC Camerfirma SA/OU=Sistemas/CN=*.camerfirma.com/emailAddress=admin-siste...@camerfirma.com/serialNumber=A82743287 /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_valido/emailAddress=i...@camerfirma.com/serialNumber=A /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_revocado/emailAddress=i...@camerfirma.com/serialNumber=A /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_caducado/emailAddress=i...@camerfirma.com/serialNumber=A 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: Firma crittografica S/MIME ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
On 04/10/17 13:18, Adriano Santoni via dev-security-policy wrote: 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. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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: 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. smime.p7s Description: Firma crittografica S/MIME ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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... 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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 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 smime.p7s Description: Firma crittografica S/MIME ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-secur
Re: Doppelganger/tripleganger intermediate certificates
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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: 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? 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? - 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. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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 Authenticatio
Re: Doppelganger/tripleganger intermediate certificates
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: Firma crittografica S/MIME ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Doppelganger/tripleganger intermediate certificates
AC Camerfirma is looking into this issue. regards Ramiro Muñoz Muñoz AC Camerfirma SA. CTO, Exploitation Manager, CISA. +34 619 746 291 · rami...@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 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
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 smime.p7s Description: Firma crittografica S/MIME ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Doppelganger/tripleganger intermediate certificates
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
