Re: Reuse of serial numbers by StartCom

[Patrick T]

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. 
> XMPP: start...@startcom.org 


Are the certificates listed here also affected by this problem?

https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769=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

Re: Name issues in public certificates

[Patrick T]

On Tuesday, 17 November 2015 08:04:41 UTC, Peter Bowen  wrote:
> Inspired by Rob Stradling's work
> (https://cabforum.org/pipermail/public/2015-November/006269.html), I
> wrote a quick tool to check that commonNames and Subject Alternative
> Names in server auth certificates issued by public CAs were following
> the CA/Browser Forum baseline requirements.
> 
> The resulting report of anomalies is available at
> https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing
> 
> The rules are a rather strict interpretation of RFC 5280 and the
> Baseline Requirements.  Notably, it will complain if FQDNs are not
> converted to ASCII (as defined in 7.2 and 7.3 of RFC 5280) and will
> complain if there is an IP address flaged as a dNSName in a
> Generalized Name.
> 
> There are a couple of rules that may create false positives, so please
> don't assume every certificate on the sheet is problematic.
> 
> Thanks,
> Peter

I've found one of the certificates here (*.gov.bn, Symantec issued) seems to 
contain some NULL characters in the SAN.

https://crt.sh/?serial=331C896050CE23EFAB5CF53237AF093F
and
https://crt.sh/?id=7335256

Wasn't there an issue with spoofing using NULs in certificates several years 
ago?
Verisign back then claimed this couldn't be done, but the cert is recent.

http://www.symantec.com/connect/blogs/busy-day-black-hat
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy