Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Apple's response to the WoSign incidents

8,717 views
Skip to first unread message

certificate-au...@group.apple.com

unread,
Oct 1, 2016, 5:02:25 AM10/1/16
to dev-secur...@lists.mozilla.org


Blocking Trust for WoSign CA Free SSL Certificate G2

Certificate Authority WoSign experienced multiple control failures in their certificate issuance processes for the WoSign CA Free SSL Certificate G2 intermediate CA. Although no WoSign root is in the list of Apple trusted roots, this intermediate CA used cross-signed certificate relationships with StartCom and Comodo to establish trust on Apple products.

In light of these findings, we are taking action to protect users in an upcoming security update.  Apple products will no longer trust the WoSign CA Free SSL Certificate G2 intermediate CA.

To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19. They will continue to be trusted until they expire, are revoked, or are untrusted at Apple’s discretion.

As the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.

Regards,

Apple Root Certificate Program

ram...@gmail.com

unread,
Oct 1, 2016, 9:45:30 AM10/1/16
to mozilla-dev-s...@lists.mozilla.org
Do you have a link to that process and is it automated. Reason is I have a few hundred startSSL certs that my clients rely on.

Peter Bowen

unread,
Oct 1, 2016, 10:58:00 AM10/1/16
to ram...@gmail.com, mozilla-dev-s...@lists.mozilla.org
On Sat, Oct 1, 2016 at 6:40 AM, <ram...@gmail.com> wrote:
> Do you have a link to that process and is it automated. Reason is I have a few hundred startSSL certs that my clients rely on.

I can't speak for the specific process Apple is using, but in general
you can use https://crt.sh/ or
https://www.google.com/transparencyreport/https/ct/ (among many
others) to check and see if the certificates are logged in Certificate
Transparency logs.

As far as I know, StartCom has not actively logged certificates issued
in 2015 or earlier nor have they logged certificates issued in early
2016. So it is very probable that some certificates are not logged.

Thanks,
Peter
Message has been deleted

Eric Mill

unread,
Oct 1, 2016, 4:39:31 PM10/1/16
to ram...@gmail.com, mozilla-dev-s...@lists.mozilla.org
On Sat, Oct 1, 2016 at 6:40 AM, <ram...@gmail.com> wrote:

> Do you have a link to that process and is it automated. Reason is I have a
> few hundred startSSL certs that my clients rely on.
>

Apple's statement was limited specifically to WoSign. StartSSL certificates
won't be affected, though they implied that action against StartCom could
depend on further results of the investigation. But even the WoSign action
is it's a whitelist that's limited to future certificates, so existing
certificates of any kind shouldn't be affected.

-- Eric


> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

Kurt Roeckx

unread,
Oct 2, 2016, 12:03:38 AM10/2/16
to Percy, mozilla-dev-s...@lists.mozilla.org
On Sat, Oct 01, 2016 at 11:35:06AM -0700, Percy wrote:
> "Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19"
>
> It seems that Apple has taken the explicit white-listed approach despite the size drawback mentioned in the other thread.

>From what I get, they check that it's been logged in CT. And I'm
not sure what that means, like doing an online check against at CT
log, require that the SCT has been stappled or have a whitelist.


Kurt

Message has been deleted
Message has been deleted

Richard Wang

unread,
Nov 13, 2016, 8:29:15 AM11/13/16
to Percy, mozilla-dev-s...@lists.mozilla.org
WoSign stopped to issue free SSL certificate from those two intermediate CAs since Sept 29.


Best Regards,

Richard

> On 13 Nov 2016, at 17:07, Percy <percy...@gmail.com> wrote:
>
> I just found out that Apple doesn't limit "CA 沃通免费SSL证书 G2" intermediate CA even though Apple limited "WoSign CA Free SSL Certificate G2" intermediate CA. An example of site signed by"CA 沃通免费SSL证书 G2" intermediate CA is https://www.chelenet.com/
>
> Those two intermediate certs are treated by WoSign the same way and the translation of "CA 沃通免费SSL证书 G2" is "WoSign CA Free SSL Certificate G2". Users can select whether the end cert is signed by "CA 沃通免费SSL证书 G2" or "WoSign CA Free SSL Certificate G2". All control measures are the same and the only difference is the language for marketing reasons.
>
> Hence, because Apple has chose to blocked "WoSign CA Free SSL Certificate G2", it makes sense to apply the same sanction on "CA 沃通免费SSL证书 G2", as they're in all senses the same.
Message has been deleted
Message has been deleted

Richard Wang

unread,
Nov 13, 2016, 6:27:49 PM11/13/16
to Percy, mozilla-dev-s...@lists.mozilla.org
I said many times that I am the Acting CEO of Wo sign now till the new CEO arrives.

Even I am not the CEO instead of an employee, I think I can response the email about WoSign that just tell everyone the fact, not representing the company making any new decision.

Please check my previous replied emails.

Best Regards,

Richard

> On 14 Nov 2016, at 04:46, Percy <percy...@gmail.com> wrote:
> Richard,
> As the management reshuffling is part of WoSign/StartCom's response, may I ask under what capacity are you still representing WoSign on this forum?

谭晓生

unread,
Nov 13, 2016, 7:08:26 PM11/13/16
to Richard Wang, Percy, mozilla-dev-s...@lists.mozilla.org
We looking for the new CEO of Wosign actively and talking with several candidates, as the current situation as you know, it is a little bit difficult to make the candidates accept the offer, but it will be done soon, please be patient a little bit.

Thanks,
Xiaosheng Tan



在 2016/11/14 上午7:25,“dev-security-policy 代表 Richard Wang”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 ric...@wosign.com> 写入:

I said many times that I am the Acting CEO of Wo sign now till the new CEO arrives.

Even I am not the CEO instead of an employee, I think I can response the email about WoSign that just tell everyone the fact, not representing the company making any new decision.

Please check my previous replied emails.

Best Regards,

Richard

> On 14 Nov 2016, at 04:46, Percy <percy...@gmail.com> wrote:
>
>> On Saturday, October 1, 2016 at 2:02:25 AM UTC-7, certificate-au...@group.apple.com wrote:

Tarah Wheeler

unread,
Nov 14, 2016, 7:30:41 PM11/14/16
to dev-secur...@lists.mozilla.org
If Apple is using wildcards that permit an otherwise-banned certificate, it seems like not only a regex problem--and who hasn¹t had those before?-- but also a rather disturbing workaround for certs that otherwise should not be respected. I just hit this site in Safari on a Mac and got no popup or interstitial but also saw about 20 insecure content errors (not that everyone has Error Console running all the time). I also just hit a site I knew had an invalid certificate, and got a popup. Both sites show https inURL.


Respectfully,

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineering, Website Security
Symantec
ta...@symantec.com


> On Nov 13, 2016, at 1:01 PM, "dev-security-...@lists.mozilla.org" <dev-security-...@lists.mozilla.org> wrote:
>
> Send dev-security-policy mailing list submissions to
> dev-secur...@lists.mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.mozilla.org/listinfo/dev-security-policy
> or, via email, send a message with subject or body 'help' to
> dev-security-...@lists.mozilla.org
>
> You can reach the person managing the list at
> dev-security...@lists.mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dev-security-policy digest..."
>
>
> Today's Topics:
>
> 1. Re: Action on undisclosed intermediates (Peter Bowen)
> 2. Re: Action on undisclosed intermediates (Rob Stradling)
> 3. Re: Comodo issued a certificate for an extension (Eric Mill)
> 4. Re: Apple's response to the WoSign incidents (Percy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 12 Nov 2016 09:43:36 -0800
> From: Peter Bowen <pzb...@gmail.com>
> To: Gervase Markham <ge...@mozilla.org>
> Cc: "mozilla-dev-s...@lists.mozilla.org"
> <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Action on undisclosed intermediates
> Message-ID:
> <CAK6vND_0OdJSgOa5ZxhxryEG...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
>> On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham <ge...@mozilla.org> wrote:
>> I'd like to take some action about persistent failures to properly
>> disclose intermediates. The deadline for this was June, and CAs have had
>> a number of reminders, so there's no excuse.
>>
>> Of course, if intermediates aren't disclosed, we can't be certain what
>> they are, but crt.sh has a good idea of many of them:
>> https://crt.sh/mozilla-disclosures#undisclosed
>>
>> There is also a list on that page of certs which CAs have disclosed but
>> not provided audit info, but given that you can get off that list by
>> putting _anything_ in the relevant box in Salesforce, I'm worried about
>> perverse incentives if we go after people on that list at the moment:
>> https://crt.sh/mozilla-disclosures#disclosureincomplete
>
> Based on data this morning, it looks like there are only two left on
> that undisclosed list. One of them is RSA, who is already scheduled
> for removal. The other is TurkTrust, which announced they are leaving
> the server auth cert business:
> https://cabforum.org/pipermail/public/2016-September/008475.html
>
> So it seems this problem has resolved itself. No need to invent
> random selection schemes.
>
> Now, the real fun is going to be seeing if the supplied audit report
> URLs actually point to reports and if all the CAs claimed to be
> covered are actually covered ;)
>
> Thanks,
> Peter
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 12 Nov 2016 20:11:50 +0000
> From: Rob Stradling <rob.st...@comodo.com>
> To: Peter Bowen <pzb...@gmail.com>, Gervase Markham
> <ge...@mozilla.org>
> Cc: "mozilla-dev-s...@lists.mozilla.org"
> <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Action on undisclosed intermediates
> Message-ID: <734f7b4e-9911-d28e...@comodo.com>
> Content-Type: text/plain; charset=windows-1252
>
>> On 12/11/16 17:43, Peter Bowen wrote:
>> <snip>
>> So it seems this problem has resolved itself. No need to invent
>> random selection schemes.
>
> ISTM that the threat of random selection schemes may have been what
> resolved the problem. ;-)
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 12 Nov 2016 23:12:48 -0500
> From: Eric Mill <er...@konklone.com>
> To: Robin Alden <ro...@comodo.com>
> Cc: Nick Lamb <tiala...@gmail.com>,
> "mozilla-dev-s...@lists.mozilla.org"
> <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Comodo issued a certificate for an extension
> Message-ID:
> <CANBOYLUeST3c8sZL62a4wJY2...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Thank you for the update and for making it super clear, Robin.
>
> -- Eric
>
>> On Thu, Nov 10, 2016 at 2:52 PM, Robin Alden <ro...@comodo.com> wrote:
>>
>> Eric Mill, on 03 October 2016 03:14, said..
>>>>> On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb <tiala...@gmail.com> wrote:
>>>>> On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote:
>>>>> There is some good news. The CA/Browser Forum has already addressed
>>>>> this, even prior to the current discussions. Ballot 169
>>>>> (https://cabforum.org/2016/08/05/ballot-169-revised-
>>>> validation-requirements/)
>>>>> revises 3.2.2.4 considerably.
>>>>
>>>> I'm aware of Ballot 169
>>>>
>>>>> Under the new rules, which should be in
>>>>> effect as of 1 March 2017, validating www.<domain> will not be a
>> valid
>>>>> method of showing control of <domain>. The name is true for any
>> valid
>>>>> hostname under <domain>. The only note is that names in the form
>>>>> _<something>.<domain> (that is starting with an underscore) can be
>>>>> used to validate <domain>.
>>>>
>>>> I wish I shared your confidence. My expectation is that if we leave
>> this
>>>> as it is, in April 2017 subscribers will still be able to get a
>> certificate
>>>> issued using this lackadaisical validation, and the issuing CA will say
>>>> they feel it's not "really" disobeying the rules, that it's just a
>>>> "technicality" and anyway what's the harm, it's so much more convenient
>>> for
>>>> their customers this way?
>>>>
>>>> Comodo's document never actually says that they're abolishing this
>> "rule"
>>>> as a result of Ballot 169. It lets you choose to draw that implication,
>> by
>>>> specifying that their current practices pre-date Ballot 169's changes,
>> but
>>>> it never says as much. Hence I think Mozilla's rep should take this to
>>>> CA/B, or it should go in one of the bulk CA communications, to find out
>> at
>>>> least how widespread the crazy is and whether it's even consistent in
>> how
>>>> it works from one CA to the next.
>>>
>>> It would be nice for Comodo to make it explicit that this practice will
>>> cease when Ballot 169 takes effect, and the lack of an explicit update
>>> jumped out at me immediately when I read it. But the BRs post-169 seem
>>> crystal clear on this, and I don't think CAs would be able to write off
>>> this practice as a technicality or misinterpretation.
>>>
>>> -- Eric
>>
>> I'm happy to state definitively that this practice will cease when Ballot
>> 169 takes effect.
>>
>> To avoid suggestions of weasel-words around the CA/B forum's struggle with
>> their IP policy my understanding is that at least Microsoft, and I hope
>> other browsers too, will incorporate the Ballot 169 wording into their
>> policy regardless of whether the CA/B has ratified it by then.
>>
>> Comodo will have implemented some or all of the new validation methods
>> described in Ballot 169 before 1 March 2017.
>> Comodo will be withdrawing any and all validation methods which do not
>> conform with Ballot 169, and/or which rely on the pre-Ballot 169 3.2.2.4.7
>> 'any-other-equivalent method' rule before 1 March 2017.
>>
>> Regards
>> Robin Alden
>> Comodo
>
>
> --
> konklone.com | @konklone <https://twitter.com/konklone>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 13 Nov 2016 01:08:49 -0800 (PST)
> From: Percy <percy...@gmail.com>
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Apple's response to the WoSign incidents
> Message-ID: <e741fbd7-8a40-4129...@googlegroups.com>
> Content-Type: text/plain; charset=UTF-8
>
> I just found out that Apple doesn't limit "CA ????SSL?? G2" intermediate CA even though Apple limited "WoSign CA Free SSL Certificate G2" intermediate CA. An example of site signed by"CA ????SSL?? G2" intermediate CA is https://www.chelenet.com/
>
> Those two intermediate certs are treated by WoSign the same way and the translation of "CA ????SSL?? G2" is "WoSign CA Free SSL Certificate G2". Users can select whether the end cert is signed by "CA ????SSL?? G2" or "WoSign CA Free SSL Certificate G2". All control measures are the same and the only difference is the language for marketing reasons.
>
> Hence, because Apple has chose to blocked "WoSign CA Free SSL Certificate G2", it makes sense to apply the same sanction on "CA ????SSL?? G2", as they're in all senses the same.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> ------------------------------
>
> End of dev-security-policy Digest, Vol 95, Issue 49
> ***************************************************

Thijs Alkemade

unread,
Nov 15, 2016, 3:37:56 AM11/15/16
to Percy, mozilla-dev-s...@lists.mozilla.org
On 13 Nov 2016, at 10:08, Percy <percy...@gmail.com> wrote:
>
> I just found out that Apple doesn't limit "CA 沃通免费SSL证书 G2" intermediate CA even though Apple limited "WoSign CA Free SSL Certificate G2" intermediate CA. An example of site signed by"CA 沃通免费SSL证书 G2" intermediate CA is https://www.chelenet.com/
>
> Those two intermediate certs are treated by WoSign the same way and the translation of "CA 沃通免费SSL证书 G2" is "WoSign CA Free SSL Certificate G2". Users can select whether the end cert is signed by "CA 沃通免费SSL证书 G2" or "WoSign CA Free SSL Certificate G2". All control measures are the same and the only difference is the language for marketing reasons.
>
> Hence, because Apple has chose to blocked "WoSign CA Free SSL Certificate G2", it makes sense to apply the same sanction on "CA 沃通免费SSL证书 G2", as they're in all senses the same.

Hi Percy,

I’ve been following Apple’s security updates to determine when the announced block becomes active and how it is implemented. Using 10.11.6, with no updates available, it appears this block is not yet active for me. There are no errors when I try to visit https://inow.ua in Safari (https://crt.sh/?id=43120524 appears to be the last certificate issued by "WoSign CA Free SSL Certificate G2” which is currently still in use). In the file /System/Library/Security/Certificates.bundle/Contents/Resources/Allowed.plist I only see two CINNIC roots listed.

Could you tell us what OS and version you used to determine that Apple has limited "WoSign CA Free SSL Certificate G2”?

Best regards,
Thijs Alkemade
Message has been deleted
Message has been deleted
0 new messages