Re: ETSI auditors still not performing full annual audits?
Am Montag, 19. Juni 2017 21:15:09 UTC+2 schrieb Kathleen Wilson: > I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an > audit statement that I received for SwissSign. I have copied the bug > description below, because I am concerned that there still may be ETSI > auditors (and CAs?) who do not understand the audit requirements, see below. > > ~~~ > SwissSign provided their annual audit statement: > https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299 > > Problems noted in it: > -- "Agreed-upon procedures engagement" - special words for audits - does not > necessarily encompass the full scope > -- "surveillance certification audits" - does not necessarily mean a full > audit (which the BRs require annually) > -- "point in time audit" -- this means that the auditor's evaluation only > covered that point in time (note a period in time) > -- "only intended for the client" -- Doesn't meet Mozilla's requirement for > public-facing audit statement. > -- "We were not engaged to and did not conduct an examination, the objective > of which would be the expression of an opinion on the Application for > Extended Validation (EV) Certificate. Accordingly, we do not express such an > opinion. Had we performed additional procedures, other matters might have > come to our attention that would have been reported to you." -- some of the > included root certs are enabled for EV treatment, so need an EV audit as well. > > > According to section 8.1 of the CA/Browser Forum's Baseline Requirements: > "Certificates that are capable of being used to issue new certificates MUST > ... be ... fully audited in line with all remaining requirements from this > section. > ... > The period during which the CA issues Certificates SHALL be divided into an > unbroken sequence of audit periods. An audit period MUST NOT exceed one year > in duration." > > So, a full period-in-time audit is required every year. > > After I voiced concern > (https://bugzilla.mozilla.org/show_bug.cgi?id=1142323#c27) the CA provided an > updated audit statement to address the concerns I had raised in the bug: > https://bugzilla.mozilla.org/attachment.cgi?id=8867948 > I do not understand how the audit statement can magically change from > point-in-time to a period-in-time. > ~~~ > > I will greatly appreciate thoughtful and constructive input into this > discussion about what to do about this SwissSign audit situation, and if this > is an indicator that ETSI auditors are still not performing full annual > audits that satisfy the CA/Browser Forum's Baseline Requirements. > > Thanks, > Kathleen Hello togehter the Report is the annual Attestation letter. I agree htat the Format was not the best, I also agree that it would be worth to have a confirmed Audit Statement what is understandable and readable by the relevant responsible persons. Thanks 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 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 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
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
Re: Mississuance of EV Certificates
Am Dienstag, 12. Dezember 2017 11:10:00 UTC+1 schrieb cornel...@swisssign.com: > 1)How your CA first became aware of the problem (e.g. via a problem report > submitted to your Problem Reporting Mechanism, a discussion in > mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the > time and date. > > We became aware of the problem during an internal review of the configuration > change from last week at Monday December 11 2 .30 p.m. UTC. > > 2) A timeline of the actions your CA took in response. A timeline is a > date-and-time-stamped sequence of all relevant events. This may include > events before the incident was reported, such as when a particular > requirement became applicable, or a document changed, or a bug was > introduced, or an audit was done. > > •2017/12/04 2 p.m. UTC: Test Setup with wrong configuration has been set up. > •2017/12/06 12.10 p.m. UTC – 2017/12/08 3.40 p.m. UTC: 10 Certificates were > issued using the wrong configuration. The configuration should have been > using an internal not public trusted CA. > •2017/12/11 2.30 p.m. UTC: Wrong setup was detected during the internal > setup review process. > •2017/12/11 3.00 p.m. UTC: The affected configuration has been suspended. > •2017/12/11 3.30 p.m. UTC: Affected Certificates were immediately revoked > after a short internal review. > •2017/12/11 3.00 p.m. UTC: The affected configuration has been corrected. > •2017/12/12 10:00 p.m. UTC: Incident report was submitted to Mozilla > > > 3) Whether your CA has stopped, or has not yet stopped, issuing certificates > with the problem. A statement that you have will be considered a pledge to > the community; a statement that you have not requires an explanation. > > The affected configuration has been corrected. Since then, no such > certificates have been issued. > > 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. > > The subject information in the affected certificates were not validated > correctly due to the misconfiguration. 10 certificates were issued based on > this misconfiguration between 2017/12/06 12.10 p.m. UTC and 2017/12/08 3.40 > p.m. UTC. > > 5) The complete certificate data for the problematic certificates. The > recommended way to provide this is to ensure each certificate is logged to CT > and then list the fingerprints or crt.sh IDs, either in the report or as an > attached spreadsheet, with one list per distinct problem. > > https://crt.sh/?id=273776520 > https://crt.sh/?id=273776617 > https://crt.sh/?id=272950014 > https://crt.sh/?id=272950007 > https://crt.sh/?id=272950012 > https://crt.sh/?id=272950010 > https://crt.sh/?id=272166103 > https://crt.sh/?id=272166102 > https://crt.sh/?id=272166107 > https://crt.sh/?id=272166110 > > > > 6) Explanation about how and why the mistakes were made or bugs introduced, > and how they avoided detection until now. > > The employee wanted to set up a test set up for a partner and have made a > mistake in choosing the wrong template for the issuing CA (productive EV CA > instead of a untrusted internally used test CA). > > 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. > > The implemented controls detected the misconfiguration within 24 hours. The > incorrect configuration was nevertheless recorded as a security incident. The > handling of the security incident by the information security management team > is still underway. Further measures will be decided within this process. Update on the long-term countermeasures: At the first point - sorry for the delay. I missed to post my answer on Fryday. We The occurred error caused by a human error we decided as a long-term protection measure to carry out the setup in the 4 AP and all possible restrictions in case of test accounts. In this way, a repetition of the error is to be prevented. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mississuance of EV Certificates
I have to correct one thing: 7) The implemented controls detected the misconfiguration, when we detectetd the misconfiguration the report was given within 24 hours. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
