I am sure it is revoked, please check it again, thanks.
Best Regards, Richard -----Original Message----- From: dev-security-policy [mailto:[email protected]] On Behalf Of Patrick T Sent: Thursday, September 1, 2016 5:07 PM To: [email protected] Subject: Re: Reuse of serial numbers by StartCom 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: [email protected] <xmpp:[email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
