GlobalSign misissuance: 4 certificates with invalid CN
Today our post issuance checker notified us of 4 certificates were issued with invalid CN values this afternoon. We posted our incident report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1552586 In summary, 4 certificate were issued from an API that had been depreciated, but not functionally disabled. All customers were migrated from this API but the API was not disabled. One of our custom on-premise applications was misconfigured to use this old API. The CN of the certificates is: "madmin's macboo.int.mlsel.com" They were immediately revoked. Additional detail and ongoing status will be posted in the Mozilla incident. smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certinomis Issues
On 17/05/2019 07:21, Jakob Bohm wrote: > On 17/05/2019 01:39, Wayne Thayer wrote: >> On Thu, May 16, 2019 at 4:23 PM Wayne Thayer wrote: >> >> I will soon file a bug requesting removal of the “Certinomis - Root CA” >>> from NSS. >>> >> >> This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374 >> > > To more accurately assess the impact of distrust, maybe someone with > better crt.sh skills than me should produce a list of current > certificates filtered as follows: > > - Sort by O= (organization), thus grouping together certificates that > were issued to the same organization (for example, there are many > issued to divisions of LA POSTE). > - Exclude certificates that expire on or before 2019-08-31, as those > will be unaffected by a September distrust. > - Exclude certificates issued after 2019-05-17 (today), as Certinomis > should be aware of the likely distrust by tonight. > To clarify, this is intended as an improvement to the statistics Andrew Ayer posted at https://bugzilla.mozilla.org/show_bug.cgi?id=1552374#c1 . I am posting it in the thread to increase the chance someone with the skills will see it and run the query. I expect it to show a surprisingly small number of certificate holders, indicating the real impact of revocation to be much smaller than one would expect from the raw count of 1381 certificates. This in turn could inform the mitigations or other proactive steps to reduce relying party (user) impact of distrust, if distrust is accepted by Kathleen. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certinomis Issues
On Fri, May 17, 2019 at 1:21 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/05/2019 01:39, Wayne Thayer wrote: > > On Thu, May 16, 2019 at 4:23 PM Wayne Thayer > wrote: > > > > I will soon file a bug requesting removal of the “Certinomis - Root CA” > >> from NSS. > >> > > > > This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374 > > > > To more accurately assess the impact of distrust, maybe someone with > better crt.sh skills than me should produce a list of current > certificates filtered as follows: If you feel this is important to consider, especially if it may impact any proposals, may I ask why you waited so long to suggest this, and how you see this information being used now? There is value in analyzing the information when exploring options, and I have no doubt, given how trivial it is to explore this information from CT, that it was and has been taken into consideration. It was certainly something I looked at when Wayne proposed options, and it’s clear that Andrew Ayer has run similar analysis. However, I do not believe it valuable or productive to be suggesting at this venture, and I think it’s a particularly unhelpful way to engage to suggest to do so. If you feel that such information should change how things progress, or you’re unsure of whether it has been taken into consideration, it seems that concern could have been raised over the past month of discussion. The suggestion, as presented, does not lead to any concrete behavior changes - it’s merely presented as information for informations sake. If there is a feeling that it should change something: the proposed next steps, the timeline, the implementation details of the action, that the next steps are too risky, etc, then it is far more productive to simply state that, and explain your point of view, so as to justify why you believe it valuable to look at this information. It has been considered. If you would like to consider it for yourself, the information is readily available. If you believe the information should change things, you should say so, and during the community discussion phase. As presented though, I’m not sure it’s a very useful or helpful statement, so something clearer would be much more beneficial. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
