info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WoSign and duplicate serial numbers
342 views
Skip to first unread message
Kurt Roeckx
Sep 26, 2016, 6:45:51 PM9/26/16
to mozilla-dev-s...@lists.mozilla.org
Hi,
In their report and the audit statement they talk about 392
duplicate serial numbers, with links to the crt.sh page for those
serial numbers.
But they in fact actually point to 393, the first group has 314
and not 313 duplicates in it. This was already the case before
they published their new report.
The last one in the group of 314 has the oldest SCT from September
the 7th. But the whole group was from 4 days during 2015 which we
were told were all send to the CT logs a week before that. This is
the one that was added later: https://crt.sh/?id=31258021
What is also not very clear from their report is that the
duplicates in the 314 group seem to have been from 2 different
issues. It seems there are also that belong to issue F:
https://crt.sh/?id=8573890
https://crt.sh/?id=30333598
https://crt.sh/?id=30333161
https://crt.sh/?id=7158549
https://crt.sh/?id=30333305
https://crt.sh/?id=30333303
https://crt.sh/?id=7190187
https://crt.sh/?id=30333436
https://crt.sh/?id=30333165
https://crt.sh/?id=30333160
There might be some more, I'm not sure what I should use as the
time limit for issue F, the report at least has an example of 204
seconds.
Looking at other cases for duplicate serial numbers, I also find
those not mentioned in the report:
2 for the same CA, but different URIs in it:
https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450
2 for the same CA with order fields different, and different URIs:
https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450
Kurt
In their report and the audit statement they talk about 392
duplicate serial numbers, with links to the crt.sh page for those
serial numbers.
But they in fact actually point to 393, the first group has 314
and not 313 duplicates in it. This was already the case before
they published their new report.
The last one in the group of 314 has the oldest SCT from September
the 7th. But the whole group was from 4 days during 2015 which we
were told were all send to the CT logs a week before that. This is
the one that was added later: https://crt.sh/?id=31258021
What is also not very clear from their report is that the
duplicates in the 314 group seem to have been from 2 different
issues. It seems there are also that belong to issue F:
https://crt.sh/?id=8573890
https://crt.sh/?id=30333598
https://crt.sh/?id=30333161
https://crt.sh/?id=7158549
https://crt.sh/?id=30333305
https://crt.sh/?id=30333303
https://crt.sh/?id=7190187
https://crt.sh/?id=30333436
https://crt.sh/?id=30333165
https://crt.sh/?id=30333160
There might be some more, I'm not sure what I should use as the
time limit for issue F, the report at least has an example of 204
seconds.
Looking at other cases for duplicate serial numbers, I also find
those not mentioned in the report:
2 for the same CA, but different URIs in it:
https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450
2 for the same CA with order fields different, and different URIs:
https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450
Kurt
Gervase Markham
Sep 27, 2016, 5:32:32 AM9/27/16
to Kurt Roeckx
Hi Kurt,
On 26/09/16 23:45, Kurt Roeckx wrote:
> In their report and the audit statement they talk about 392
> duplicate serial numbers, with links to the crt.sh page for those
> serial numbers.
>
> But they in fact actually point to 393, the first group has 314
> and not 313 duplicates in it. This was already the case before
> they published their new report.
>
> The last one in the group of 314 has the oldest SCT from September
> the 7th. But the whole group was from 4 days during 2015 which we
> were told were all send to the CT logs a week before that. This is
> the one that was added later: https://crt.sh/?id=31258021
We don't know who sends certs to the log. It could be that WoSign sent
this one in late, or it could be that someone else discovered it on the
web somewhere. This might speak to WoSign not having complete track of
all their certs, but without more evidence it's risky to speculate.
> What is also not very clear from their report is that the
> duplicates in the 314 group seem to have been from 2 different
> issues. It seems there are also that belong to issue F:
Yes, that seems to be the case. The time period of when Issue F was
active matches up.
> Looking at other cases for duplicate serial numbers, I also find
> those not mentioned in the report:
>
> 2 for the same CA, but different URIs in it:
> https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450
>
> 2 for the same CA with order fields different, and different URIs:
> https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450
Both of these are intermediates. Reissuing intermediates with new
information but the same serial number and key AIUI does happen
occasionally, although now I think about it, I guess it's as much an RFC
violation as when CAs do it with EE certs. Do any PKI people want to
chime in with views on this practice?
Gerv
On 26/09/16 23:45, Kurt Roeckx wrote:
> In their report and the audit statement they talk about 392
> duplicate serial numbers, with links to the crt.sh page for those
> serial numbers.
>
> But they in fact actually point to 393, the first group has 314
> and not 313 duplicates in it. This was already the case before
> they published their new report.
>
> The last one in the group of 314 has the oldest SCT from September
> the 7th. But the whole group was from 4 days during 2015 which we
> were told were all send to the CT logs a week before that. This is
> the one that was added later: https://crt.sh/?id=31258021
this one in late, or it could be that someone else discovered it on the
web somewhere. This might speak to WoSign not having complete track of
all their certs, but without more evidence it's risky to speculate.
> What is also not very clear from their report is that the
> duplicates in the 314 group seem to have been from 2 different
> issues. It seems there are also that belong to issue F:
active matches up.
> Looking at other cases for duplicate serial numbers, I also find
> those not mentioned in the report:
>
> 2 for the same CA, but different URIs in it:
> https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450
>
> 2 for the same CA with order fields different, and different URIs:
> https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450
information but the same serial number and key AIUI does happen
occasionally, although now I think about it, I guess it's as much an RFC
violation as when CAs do it with EE certs. Do any PKI people want to
chime in with views on this practice?
Gerv
Rob Stradling
Sep 27, 2016, 6:00:09 AM9/27/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Kurt Roeckx
On 27/09/16 10:31, Gervase Markham wrote:
<snip>
Issuer, and so it's a violation of RFC5280 for them to share the same
serial number.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
<snip>
>> Looking at other cases for duplicate serial numbers, I also find
>> those not mentioned in the report:
>>
>> 2 for the same CA, but different URIs in it:
>> https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450
>>
>> 2 for the same CA with order fields different, and different URIs:
>> https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450
>
>> those not mentioned in the report:
>>
>> 2 for the same CA, but different URIs in it:
>> https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450
>>
>> 2 for the same CA with order fields different, and different URIs:
>> https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450
>
> Both of these are intermediates. Reissuing intermediates with new
> information but the same serial number and key AIUI does happen
> occasionally, although now I think about it, I guess it's as much an RFC
> violation as when CAs do it with EE certs. Do any PKI people want to
> chime in with views on this practice?
Hi Gerv. You're correct. Each of these pairs of certs have the same
> information but the same serial number and key AIUI does happen
> occasionally, although now I think about it, I guess it's as much an RFC
> violation as when CAs do it with EE certs. Do any PKI people want to
> chime in with views on this practice?
Issuer, and so it's a violation of RFC5280 for them to share the same
serial number.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Kurt Roeckx
Sep 27, 2016, 6:53:30 AM9/27/16
to mozilla-dev-s...@lists.mozilla.org
On 2016-09-27 11:31, Gervase Markham wrote:
> Hi Kurt,
>
> On 26/09/16 23:45, Kurt Roeckx wrote:
>> In their report and the audit statement they talk about 392
>> duplicate serial numbers, with links to the crt.sh page for those
>> serial numbers.
>>
>> But they in fact actually point to 393, the first group has 314
>> and not 313 duplicates in it. This was already the case before
>> they published their new report.
>>
>> The last one in the group of 314 has the oldest SCT from September
>> the 7th. But the whole group was from 4 days during 2015 which we
>> were told were all send to the CT logs a week before that. This is
>> the one that was added later: https://crt.sh/?id=31258021
>
> We don't know who sends certs to the log. It could be that WoSign sent
> this one in late, or it could be that someone else discovered it on the
> web somewhere. This might speak to WoSign not having complete track of
> all their certs, but without more evidence it's risky to speculate.
I think someone on this list pointed to that cert on the censys.io site
> Hi Kurt,
>
> On 26/09/16 23:45, Kurt Roeckx wrote:
>> In their report and the audit statement they talk about 392
>> duplicate serial numbers, with links to the crt.sh page for those
>> serial numbers.
>>
>> But they in fact actually point to 393, the first group has 314
>> and not 313 duplicates in it. This was already the case before
>> they published their new report.
>>
>> The last one in the group of 314 has the oldest SCT from September
>> the 7th. But the whole group was from 4 days during 2015 which we
>> were told were all send to the CT logs a week before that. This is
>> the one that was added later: https://crt.sh/?id=31258021
>
> We don't know who sends certs to the log. It could be that WoSign sent
> this one in late, or it could be that someone else discovered it on the
> web somewhere. This might speak to WoSign not having complete track of
> all their certs, but without more evidence it's risky to speculate.
and that I actually submitted it to CT, but only to Aviator. This
should be in the archive somewhere.
Kurt
Gervase Markham
Sep 27, 2016, 7:28:20 AM9/27/16
to mozilla-dev-s...@lists.mozilla.org
On 26/09/16 23:45, Kurt Roeckx wrote:
> Looking at other cases for duplicate serial numbers, I also find
> those not mentioned in the report:
>
> 2 for the same CA, but different URIs in it:
> https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450
>
> 2 for the same CA with order fields different, and different URIs:
> https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450
These two instances of duplicate serials are now Issue O:
> those not mentioned in the report:
>
> 2 for the same CA, but different URIs in it:
> https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450
>
> 2 for the same CA with order fields different, and different URIs:
> https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_O:_Intermediates_with_Duplicate_Serial_Numbers_.28May_-_July_2015.29
Gerv
0 new messages