On Wednesday, 31 August 2016 17:57:41 UTC+1, Eddy Nigg wrote: > On 08/31/2016 03:19 PM, Matt Palmer wrote: > > That bug appears to pre-date *all* of the certificates listed above. > > Further, the last communication on that bug (2014-09-22), from Eddy > > Nigg (of StartCom), said: > >> It's a hard and software related capacity issue of the queue managing the > >> certificates and the real solution will be only available after a hardware > >> upgrade we are planning for Nov-Dec this year. > > So that's presumably Nov-Dec 2014... and 12 months later, duplicate serial > > numbers were still appearing. > > Right, however we could limit this occurrence to a minimum at that time > - an entirely new infrastructure was in the pipeline already which > solved the problem completely. Please note that such infrastructures are > fairly complex and therefore also hard to deal with sometimes. I > acknowledged in the bug report that we were able significantly reduce > this issue, though not eliminate entirely. > > > It's somewhat disconcerting that the response from StartCom in that bug > > report was, essentially, a mixture of, "it's not our fault, the software did > > it" and "ain't no thang". To me, that isn't a particularly useful attitude > > for a CA operator. The correctness of the software which is deployed is of > > *crucial* importance to the trustworthiness of a CA. > > True, but as explained above, some more drastic changes had to be done > in order to correct this issue completely, not something done over > night. The corrective measure and eventual implementation was however > there on the way, even if it took some time. > > Regarding our "attitude", even though this issue was certainly not > desired, it wasn't comparable to a wrongful issuance leading to possible > abuse - some client software would however stopped working when > encountering a duplicate serial. And to my assessment this wasn't a > situation which required to take an entire system down in order to "fix" > it (which was necessary in this case). > > > Is anyone aware of any attempts by StartCom to proactively report these BR > > violations to Mozilla or any other trust store operator, at or around the > > time of issuance? I don't see any mention of the 2015 misissuances in the > > most recent BR audit report (https://startssl.com/ey-webtrust-br.pdf), > > either. Does this mean that StartCom were unaware that they had issued > > these duplicate certificates, despite having a history of doing so, or did > > they mislead their auditors? > > Neither - the software wasn't designed to issue certificates with > duplicate serials, neither was that done knowingly or willfully. Since > we are talking about an occurrence of perhaps one in 40-50 thousand > certificates or less, it's not really something that can be measured by > an auditor. What can be measured are software design, actions performed, > implementation of plans to solve a particular issue. > > PS. it appears that most certificates mentioned originally have already > expired, so there isn't much to revoke today except one. > > -- > Regards > Signer: Eddy Nigg, Founder > StartCom Ltd. <http://www.startcom.org> > XMPP: start...@startcom.org <xmpp:start...@startcom.org>
Are the certificates listed here also affected by this problem? https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662 There seem to be a number of duplicated-serial certificates, which aren't revoked and are still valid. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
