Re: Incident Certificate signed with SHA1 Violation BR 7.3.1
On 15/09/17 13:55, cornelia.enk...@gmail.com wrote: > technically the CA now is disabled to sign certificates using SHA1 But presumably you thought that was true before this incident? (And if not, why not?) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Certificate signed with SHA1 Violation BR 7.3.1
Am Mittwoch, 6. September 2017 22:38:35 UTC+2 schrieb Nick Lamb: > Thanks for writing this incident report. > > The latter of the two certificates was issued after popular web browsers had > ceased accepting SHA-1 as far as I understand it. As a result it seems likely > that it would not have functioned as expected if a customer deployed it on a > Web server. You mention that you reached out to the affected customer, did > they indicate that they'd noticed any problem with their certificate? Do you > have any reason to think that in practice it was not used? (e.g. customer > ordered & received a SHA-256 cert for the same name shortly afterwards). In fact the customers did not use this certificates. Best Regards Conny ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Certificate signed with SHA1 Violation BR 7.3.1
Am Mittwoch, 6. September 2017 21:47:54 UTC+2 schrieb Rob Stradling: > Hi Conny. Are you able to post those 2 certificates to some CT logs and > provide crt.sh links? > > You've said that both certs have the same SHA-1 Fingerprint. Are you > sure about that? > > On 06/09/17 20:38, cornelia.enke66--- via dev-security-policy wrote: > > SwissSign has identified the following incident: > > two Certificate signed with SHA1: Violation BR 7.3.1 > > > > 1) > > During an internal audit on 05.09.2017 we found out that there are two > > certificates issued after 16.01.2015 and signed with a SHA1 hash. > > After the discovery of two certificates, the following actions where taken > > 05.09.2017 > > a) a security incident was opend > > b) contact the customers to revoke the two certificates > > c) identify the reason for the error > > d) the source of the error has been eliminated > > > > 2) > > On 06.09.2017 the Icident including a description of the treatment was > > reported to the community. > > > > 3) > > By identifying the error, the configuration of the software has been > > changed in such a way that the issuing of certificates with a SHA1 > > signature is no longer possible. > > > > 4) > > The following certificates were concerned: > > a) CN=v05dua. pnet. ch/Email=betriebit...@post.ch/OU=IT2/O=Post CH > > AG/L=Bern/ST=BE/C=CH > > Certificate Identifier: CEC009CA9554D878F118F9582749B3 > > SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: > > E1:96: A4:9D: 05: EE > > Issued: 16.01.2015 > > Revoked: 2017-09-05 15:37:10 > > b) CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik > > AG/L=Herisau/ST=AR/C=CH > > Certificate Identifier: 743DDD4855841D256DAFBD0448D957A439DEA593D > > SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: > > E1:96: A4:9D: 05: EE > > Issued 02/02/2017 > > Revoked 2017-09-06 08:42:42:42 > > > > 5) > > The following reasons for misissunace have been identified: > > a) the correct configuration of the customer account to prevent the > > issuance of SHA1 certificates was activated delayed. > > b) a new functionality was introduced in the CA software in January 2017, > > which made it possible to reissue the certificate signed with SHA1. > > > > 6) > > The additional functionality introduced in January 2017 had a weak point. > > This vulnerability was only found because of the detailed error analysis > > performed by finding the certificate that was misissued. > > The misissued certificates where detected by the improved quality control. > > No further measures are currently planned. > > > > 7) > > The error has been fixed. Configurative measures ensured that no more > > certificates can be signed using SHA1. > > > > Best Regards Conny Enke > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online Hi Rob, no sorry my mistake. The following certificates were concerned: a) CN=v05dua. pnet. ch/Email=betriebit...@post.ch/OU=IT2/O=Post CH AG/L=Bern/ST=BE/C=CH Certificate Identifier: CEC009CA9554D878F118F9582749B3 SHA1 Fingerprint: 75:E4:D8:02:5D:A2:3C:AA:83:73:41:69:06:DB:EE:E7:06:C3:C4:D8 Issued: 16.01.2015 Revoked: 2017-09-05 15:37:10 b) CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik AG/L=Herisau/ST=AR/C=CH Certificate Identifier: 743DD4855841D256DAFBD0448D957A439DEA593D SHA1 Fingerprint: 61:A6:DA:9A:3A:E7:F8:C0:E8:95:AC:26:EB:BD:E1:96:A4:9D:05:EE Issued 02/02/2017 Revoked 2017-09-06 08:42:42:42 Regarding the publication I have requestet the operation team. Best Regards Conny ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Certificate signed with SHA1 Violation BR 7.3.1
Am Montag, 11. September 2017 12:38:38 UTC+2 schrieb Gervase Markham: > Hi Connie, > > On 06/09/17 20:38, cornelia.enk...@gmail.com wrote: > > SwissSign has identified the following incident: > > two Certificate signed with SHA1: Violation BR 7.3.1 > > Thank you for this report. There have been a couple of reasonable > follow-up questions here in the m.d.s.p. group; could you please answer > them? > > > 6) > > The additional functionality introduced in January 2017 had a weak point. > > This vulnerability was only found because of the detailed error analysis > > performed by finding the certificate that was misissued. > > The misissued certificates where detected by the improved quality control. > > No further measures are currently planned. > > Have automated tests been put in place to make sure the operation of > reissuing a SHA-1 certificate always fails, even after further updates > to the software? > > Gerv Hi Gerv, yes automated test had put in place. The outcome is monitored. Best Regards Conny ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Certificate signed with SHA1 Violation BR 7.3.1
Hi Connie, On 06/09/17 20:38, cornelia.enk...@gmail.com wrote: > SwissSign has identified the following incident: > two Certificate signed with SHA1: Violation BR 7.3.1 Thank you for this report. There have been a couple of reasonable follow-up questions here in the m.d.s.p. group; could you please answer them? > 6) > The additional functionality introduced in January 2017 had a weak point. > This vulnerability was only found because of the detailed error analysis > performed by finding the certificate that was misissued. > The misissued certificates where detected by the improved quality control. No > further measures are currently planned. Have automated tests been put in place to make sure the operation of reissuing a SHA-1 certificate always fails, even after further updates to the software? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Incident Certificate signed with SHA1 Violation BR 7.3.1
Thanks for writing this incident report. The latter of the two certificates was issued after popular web browsers had ceased accepting SHA-1 as far as I understand it. As a result it seems likely that it would not have functioned as expected if a customer deployed it on a Web server. You mention that you reached out to the affected customer, did they indicate that they'd noticed any problem with their certificate? Do you have any reason to think that in practice it was not used? (e.g. customer ordered & received a SHA-256 cert for the same name shortly afterwards). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Certificate signed with SHA1 Violation BR 7.3.1
Hi Conny. Are you able to post those 2 certificates to some CT logs and provide crt.sh links? You've said that both certs have the same SHA-1 Fingerprint. Are you sure about that? On 06/09/17 20:38, cornelia.enke66--- via dev-security-policy wrote: SwissSign has identified the following incident: two Certificate signed with SHA1: Violation BR 7.3.1 1) During an internal audit on 05.09.2017 we found out that there are two certificates issued after 16.01.2015 and signed with a SHA1 hash. After the discovery of two certificates, the following actions where taken 05.09.2017 a) a security incident was opend b) contact the customers to revoke the two certificates c) identify the reason for the error d) the source of the error has been eliminated 2) On 06.09.2017 the Icident including a description of the treatment was reported to the community. 3) By identifying the error, the configuration of the software has been changed in such a way that the issuing of certificates with a SHA1 signature is no longer possible. 4) The following certificates were concerned: a) CN=v05dua. pnet. ch/Email=betriebit...@post.ch/OU=IT2/O=Post CH AG/L=Bern/ST=BE/C=CH Certificate Identifier: CEC009CA9554D878F118F9582749B3 SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: E1:96: A4:9D: 05: EE Issued: 16.01.2015 Revoked: 2017-09-05 15:37:10 b) CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik AG/L=Herisau/ST=AR/C=CH Certificate Identifier: 743DDD4855841D256DAFBD0448D957A439DEA593D SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: E1:96: A4:9D: 05: EE Issued 02/02/2017 Revoked 2017-09-06 08:42:42:42 5) The following reasons for misissunace have been identified: a) the correct configuration of the customer account to prevent the issuance of SHA1 certificates was activated delayed. b) a new functionality was introduced in the CA software in January 2017, which made it possible to reissue the certificate signed with SHA1. 6) The additional functionality introduced in January 2017 had a weak point. This vulnerability was only found because of the detailed error analysis performed by finding the certificate that was misissued. The misissued certificates where detected by the improved quality control. No further measures are currently planned. 7) The error has been fixed. Configurative measures ensured that no more certificates can be signed using SHA1. Best Regards Conny Enke -- 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
Incident Certificate signed with SHA1 Violation BR 7.3.1
SwissSign has identified the following incident: two Certificate signed with SHA1: Violation BR 7.3.1 1) During an internal audit on 05.09.2017 we found out that there are two certificates issued after 16.01.2015 and signed with a SHA1 hash. After the discovery of two certificates, the following actions where taken 05.09.2017 a) a security incident was opend b) contact the customers to revoke the two certificates c) identify the reason for the error d) the source of the error has been eliminated 2) On 06.09.2017 the Icident including a description of the treatment was reported to the community. 3) By identifying the error, the configuration of the software has been changed in such a way that the issuing of certificates with a SHA1 signature is no longer possible. 4) The following certificates were concerned: a) CN=v05dua. pnet. ch/Email=betriebit...@post.ch/OU=IT2/O=Post CH AG/L=Bern/ST=BE/C=CH Certificate Identifier: CEC009CA9554D878F118F9582749B3 SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: E1:96: A4:9D: 05: EE Issued: 16.01.2015 Revoked: 2017-09-05 15:37:10 b) CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik AG/L=Herisau/ST=AR/C=CH Certificate Identifier: 743DDD4855841D256DAFBD0448D957A439DEA593D SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: E1:96: A4:9D: 05: EE Issued 02/02/2017 Revoked 2017-09-06 08:42:42:42 5) The following reasons for misissunace have been identified: a) the correct configuration of the customer account to prevent the issuance of SHA1 certificates was activated delayed. b) a new functionality was introduced in the CA software in January 2017, which made it possible to reissue the certificate signed with SHA1. 6) The additional functionality introduced in January 2017 had a weak point. This vulnerability was only found because of the detailed error analysis performed by finding the certificate that was misissued. The misissued certificates where detected by the improved quality control. No further measures are currently planned. 7) The error has been fixed. Configurative measures ensured that no more certificates can be signed using SHA1. Best Regards Conny Enke ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
