San,
The CRL that you are referencing reflects the status of our SubCAs, not the
status of our SSL/TLS and Client Subscriber Certificates.
>From our CP/CPS:
For the status of Subordinate CA Certificates and time-stamping
Certificates, SSL.com shall
update and reissue CRLs at least:
• once every* twelve (12) months* and
• within *twenty-four (24) hours* after revoking a Subordinate CA
Certificate,
and the value of the nextUpdate field must not be more than *twelve (12)
months* beyond the
value of the thisUpdate field.
It is acceptable for these CRLs to have 1 year validity periods.
The CRL contains the serial numbers:
1. 4E33A3DF038C94BD5611A51814F68CE9
<https://crt.sh/?sha1=C21028433BB62D1E64F5D54B592F9C94FFC5ADAE> (revoked
2023-06-15 15:53:15 UTC)
2. 663E22B3F73CCB78DC74369353AB24C3
<https://crt.sh/?sha1=1999B1FD1224DA4E9CFDB15D45B8FD3A81F06C52> (revoked
2023-06-15 15:53:16 UTC)
3. 50758BB068C7CA6BF84CC950ABC26539
<https://crt.sh/?sha1=B4C47116082859CE6D85114601352477413C5EBC> (revoked
2023-06-15 15:53:17 UTC)
4. 3348510D6AA99654904848A14BE65170
<https://crt.sh/?sha1=6F9D48936597B67880F1463E0F0459EEDB298DA4> (revoked
2023-06-15 15:53:18 UTC)
5. 0AF338327C1D48BA41753EBEB9EA6029
<https://crt.sh/?sha1=24C0B4AB0DDC29667F63417BF415E90ACFADAF13> (revoked
2023-06-15 15:53:20 UTC)
6. 4EB6AD64EA15BA233C32B0D491670063
<https://crt.sh/?sha1=3DCA8C6256D9AED555940DFB77BA7244EAB5D82C> (revoked
2023-06-15 15:53:21 UTC)
And it was issued one minute after the revocations:
Last Update: Jun 15 15:54:47 2023 GMT
Regards,
Tom
SSL.com <https://www.ssl.com>
On Saturday, 24 June 2023 at 14:04:09 UTC-5 San Wong wrote:
> According to the previous discussion, sslcom.cn should be actually
> controlled by ssl.com, but we found that both ocsp.sslcom.cn and
> crl.sslcom.cn are not compliant.
>
> 1. ocsp.sslcom.cn returned an incorrect response to the ocsp
> verification request, so the certificate could not be revoked.
> 2. crl.sslcom.cn responds to historical data (data before revoking),
> and the cache time is as long as 1 year.
>
>
> ```
> # openssl crl -inform DER -in
> http://crl.sslcom.cn/SSLcom-RootCA-RSA-4096-R1.crl -text -issuer -hash
> -lastupdate -nextupdate
> issuer=/C=US/ST=Texas/L=Houston/O=SSL Corporation/CN=SSL.com Root
> Certification Authority RSA
> 6fa5da56
> lastUpdate=Jun 15 15:54:47 2023 GMT
> nextUpdate=Jun 9 15:54:46 2024 GMT
> Certificate Revocation List (CRL):
> Version 2 (0x1)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: /C=US/ST=Texas/L=Houston/O=SSL Corporation/CN=SSL.com Root
> Certification Authority RSA
> Last Update: Jun 15 15:54:47 2023 GMT
> Next Update: Jun 9 15:54:46 2024 GMT
> CRL extensions:
> X509v3 Authority Key Identifier:
> keyid:DD:04:09:07:A2:F5:7A:7D:52:53:12:92:95:EE:38:80:25:0D:A6:59
>
> X509v3 CRL Number:
> 19
> Revoked Certificates:
> ...
> ```
>
> Not compliant with CPS
> <https://legal.ssl.com/documents/SSLcom-CP-CPS-v1.17.pdf> 4.9.7 and 4.9.9.
>
> 在2023年6月20日星期二 UTC+8 03:24:19<Thomas Zermeno> 写道：
>
>> This is to provide an update on the revocation of the QuantumCA SubCAs.
>> They were all revoked within the required timeframe. Since they were never
>> enabled for ACME, there was never an issue with these SubCAs being used in
>> the HiCA acme.sh RCE client.
>>
>> With regards to other issues raised in the discussion and which mention
>> SSL.com:
>>
>> Before issuing SubCAs to any resellers, SSL.com performs verification
>> equivalent to an Extended Validation review of the organization applying
>> for the SubCA(s). In summary, this includes verification of the legal,
>> physical and operational existence, and verification of the authorization
>> of the request. It does not include background checks, reputational
>> research, or any checks for criminal records of the organization
>> representatives, other than checks against the applicable sanctions lists.
>>
>> In the case of Quantum, our checks included doing lookups on the
>> organization using the UK Registry Companies House and a Qualified
>> Independent Information Source (QIIS), verifying the identity of contact
>> persons representing the organization and comparing them against several US
>> sanctions lists. Additionally, we performed live interviews with company
>> representatives over teleconference and via the verified means of
>> communication with the organization. All required verifications were
>> performed and approved before issuance of QuantumCA’s SubCAs.
>>
>> Furthermore, we confirm that the sole purpose of domain sslcom.cn was to
>> serve CRL and OCSP responses, and SSL.com is the only entity operating the
>> OCSP responders and CRL distribution points under that domain. There are no
>> active certificates relying on that domain.
>>
>> Finally, we would like to point out that section 5.3.1 of our CP/CPS only
>> applies to employees, agents or independent contractors of SSL.com and
>> delegated third parties which are engaged in the Certificate Management
>> Process. As a branded SubCA consumer, QuantumCA was not a delegated third
>> party of SSL.com. Although not required, SSL.com still performed EV review
>> on them as we do with all other SubCA resellers.
>>
>> To summarize, the Quantum SubCAs were never enabled for ACME by SSL.com
>> and they could not have been used to issue certificates with the vulnerable
>> acme.sh client. During the course of this discussion, due to the
>> dissolution of Quantum CA Limited, we took additional action in revoking
>> their SubCAs. We hope these statements address all relevant concerns
>> regarding HiCA’s use of Quantum SubCAs issued by SSL.com.
>>
>> On Saturday, 17 June 2023 at 12:58:13 UTC-5 Xiaohui Lam wrote:
>>
>>> John Liptak,
>>>
>>> For the www1.hi.cn,
>>>
>>> There have *no payment business* entry *at the web. *it only accepts
>>> payments only on command line. So this one is controversial, You can’t ask
>>> a website that provides only an online donation button for a blog to also
>>> go through the ICP revenue registration which needs taking more than 10,000
>>> yuan.
>>>
>>> So we think a website only published tutorials needn't ICP revenue
>>> business registration.
>>> You can check the website no member link to register/login, and cart
>>> functions to purchase product.
>>>
>>> - http://web.archive.org/web/20230330032620/https://www1.hi.cn/
>>>
>>> We have no plan to invest resources(about thousands dollars) to apply
>>> the ICP revenue registration for a dead business.
>>>
>>> ---
>>>
>>> For www.quantumca.com.cn it have revenue business online, that's our
>>> mistake and, we decide to apply ICP revenue business registration at Q3.
>>> Sounds a little off-topic about the question, this thread should closely
>>> talking about RCE security or things technical.
>>> 在2023年6月18日星期日 UTC+8 01:33:39<John Liptak> 写道：
>>>
>>>> > We looked up the crt.sh tool [^1], It is a widely accepted way for
>>>> subordinate CA customization resellers to provide domain for CA’s
>>>> different
>>>> OCSP hosting. Look up ocsp responder which public-suffixing .cn，We can
>>>> find
>>>> my many responders of Sectigo and DigiCerr own domain ICP but no business
>>>> ICP.
>>>>
>>>> This is a red herring fallacy. What I asked was your the person in
>>>> charge of the domain sslcom.cn is different from the person in the ICP
>>>> beian application you sent to the government. This is what I said:
>>>> *If it is operated by SSL.com, then that means you had provided false
>>>> materials to the government and the person/legal entity in charge of the
>>>> website is different from the person in your application*.
>>>>
>>>> Also, Tom from SSL.com has claimed "other than to provide them
>>>> brandable certificates"; however, I think you must have helped or assisted
>>>> SSL.com to establish this CRL/OCSP server in China. You are more than a
>>>> reseller.
>>>>
>>>> Since you mentioned digicert, I did look them up.
>>>>
>>>> digicert.cn is registered and operated by Digicert China. The ICP
>>>> beian also shows the domain belongs to Digicert China.
>>>>
>>>> dcocsp.cn is registered by iTrusChina. Do you have evidence that
>>>> iTrusChina is not operating dcocsp.cn? iTrusChina is listed in
>>>> Digicert's Trusted partners directory.
>>>> https://www.digicert.com/es/partners/trusted-partners-directory
>>>>
>>>> iTrusChina is a root CA and has obtained webtrust audits.
>>>> Moreover, iTrusChina has ICP license. They also have 电子认证服务许可证,
>>>> 电子认证服务使用密码许可证, and 电子政务电子认证服务批文 issued by the State Cryptography
>>>> Administration (国家密码管理局).
>>>>
>>>> Even iTrusChina is not operating dcocsp.cn, again, just because
>>>> someone else is doing the same thing doesn't mean it's not illegal.
>>>>
>>>> > And many of them have ICP license for domain, but no ICP business
>>>> license.
>>>> Since you asked this question: I want to point out Digicert has never
>>>> used digicert.cn to SELL certificates. However, you sell certificates
>>>> directly on your quantumca.com.cn and www1.hi.cn
>>>> On Saturday, June 17, 2023 at 1:54:11 AM UTC-4 [email protected] wrote:
>>>>
>>>>> Thank you for your further response and questions.
>>>>>
>>>>> > You claimed "We never operates the CRL and OCSP responders. But CA
>>>>> does(SSL.com can confirm it)," but you are serving CRLs and OCSP
>>>>> responses
>>>>> from the domain sslcom.cn, which is registered by 上海帝熙科技有限公司 and the
>>>>> ICP beian shows it belongs to 上海帝熙科技有限公司. If it is operated by SSL.com,
>>>>> then that means you had provided false materials to the government and
>>>>> the
>>>>> person/legal entity in charge of the website is different from the person
>>>>> in your application.
>>>>>
>>>>> We looked up the crt.sh tool [^1], It is a widely accepted way for
>>>>> subordinate CA customization resellers to provide domain for CA’s
>>>>> different
>>>>> OCSP hosting. Look up ocsp responder which public-suffixing .cn，We can
>>>>> find
>>>>> my many responders of Sectigo and DigiCerr own domain ICP but no business
>>>>> ICP.
>>>>> And many of them have ICP license for domain, but no ICP business
>>>>> license.
>>>>> So I think meantimes the subordinate CA’s created at, there’s no leads
>>>>> to reveal the way is illegal toChinese regulations or violations to
>>>>> CPS/CP.
>>>>>
>>>>>
>>>>> If my opinion wrong, correct it welcome
>>>>>
>>>>>
>>>>> [1]. https://crt.sh/ocsp-responders
>>>>>
>>>>> Sincere,
>>>>> Bruce Lam
>>>>> ------------------------------
>>>>> 发自我的iPhone
>>>>>
>>>>>
>>>>> ------------------ Original ------------------
>>>>> *From:* John Liptak <[email protected]>
>>>>> *Date:* Sat,Jun 17,2023 10:33 AM
>>>>> *To:* [email protected] <[email protected]>
>>>>> *Cc:* xiaohuilam <[email protected]>, Thomas Zermeno <
>>>>> [email protected]>
>>>>> *Subject:* Re: RCE used by Intermediate CA to issue certificates.
>>>>> I've been a member of chromium-dev group and am particularly
>>>>> interested in internet security. I choose not to reply all because I'm
>>>>> asking questions to specific people. The screenshot you've taken shows
>>>>> I'm
>>>>> asking that question to you and the SSL.com representative, not to
>>>>> everyone
>>>>> else.
>>>>>
>>>>> Because SSL.com CPS 5.3.1 claims they will verify the trustworthiness
>>>>> of an independent contractor and apparently you are doing this business
>>>>> illegally in China (e.g., selling digital certificates online without the
>>>>> ICP license), so I don't think they follow their CPS.
>>>>>
>>>>> You claimed "We never operates the CRL and OCSP responders. But CA
>>>>> does(SSL.com can confirm it)," but you are serving CRLs and OCSP
>>>>> responses
>>>>> from the domain sslcom.cn, which is registered by 上海帝熙科技有限公司 and the
>>>>> ICP beian shows it belongs to 上海帝熙科技有限公司. If it is operated by SSL.com,
>>>>> then that means you had provided false materials to the government and
>>>>> the
>>>>> person/legal entity in charge of the website is different from the person
>>>>> in your application.
>>>>>
>>>>> Again, all these evidence reveals SSL.com did not verify the
>>>>> trustworthiness of an independent contractor and I think they don't
>>>>> follow
>>>>> their CPS.
>>>>>
>>>>> I am not Chinese and I have no interest in attacking HiCA.
>>>>> Nevertheless, I am interested in whether SSL.com and you have followed
>>>>> the
>>>>> CPS and operated legally.
>>>>> On Friday, June 16, 2023 at 4:07:33 AM UTC-4 xiaohuilam wrote:
>>>>>
>>>>>> Your horner Mozilla PKI Policy team and CA members,
>>>>>>
>>>>>>
>>>>>> The accusation is fabricated and I have good evidence that
>>>>>> [email protected] and [email protected] appearing on this mailing
>>>>>> list are new potential detractors with the identity and speech style of
>>>>>> https://github.com/acmesh-
>>>>>> official/acme.sh/issues/4675 and DDOS attack criminals
>>>>>> https://hostloc.com/thread-1177834-1-1.html are highly similar (do
>>>>>> not care about technical and industry compliance or even RCE
>>>>>> vulnerability
>>>>>> itself, rather than trying to discredit a company as credible).
>>>>>>
>>>>>> I will introduce some of the origins of these IDs with me.
>>>>>> After Matthew Holt revealed that ACME.sh had an RCE vulnerability and
>>>>>> was exploited by HiCA, our 2 Chinese servers and 6 overseas servers were
>>>>>> severely attacked by DDOS, and also considered to so we try to close
>>>>>> HiCA
>>>>>> to avoid DDOS attacks from affecting our kernel business users (it is
>>>>>> web
>>>>>> page accepts CSR to issue certificates which registered online, which
>>>>>> has
>>>>>> nothing to do with ACME in command line).
>>>>>>
>>>>>> However, due to DNS cache and other reasons, the attack continued;
>>>>>> during this period, we analyzed the logs and switched routes to block a
>>>>>> large number of IPs. Later we saw that acme.hi.cn and www1.hi.cn had
>>>>>> no traffic at all and the attack was still affecting until we saw
>>>>>>
>>>>>> - https://hostloc.com/thread-1177834-1-1.html
>>>>>> (He tried to call on others to participate in the CC Flood/DDOS
>>>>>> website using the webbench tool made by golang, and we believe himself
>>>>>> participated)
>>>>>>
>>>>>> We contacted the attack source IP ASN owner/ISP: the abuse prevention
>>>>>> team of IPXO LLC, and finally blocked the attacker's IP.
>>>>>> [image: 网页捕获_16-6-2023_153756_help.ipxo.com.jpeg]
>>>>>>
>>>>>> When we collected all the evidence and prepared to report the case
>>>>>> added a statement on restored www1.hi.cn website and, the attacker’s
>>>>>> settlement new topic came, to compromise
>>>>>>
>>>>>> - https://hostloc.com/thread-1178837-1-1.html
>>>>>> - https://hostloc.com/thread-1179012-1-1.html
>>>>>>
>>>>>> The other party expressed their willingness to pay for the part of
>>>>>> the bill that we can prove to be related to him due to the loss caused
>>>>>> by
>>>>>> DDOS. We did not take the next legal action to advocate punishment for
>>>>>> the
>>>>>> network DDOS attackers because they did pay me:
>>>>>> [image: 1521686900808_.pic.jpg]
>>>>>> (Note that the memo information of the other party’s remarks is: DDOS
>>>>>> attack compensation. To protect the privacy of him we did mosaic)
>>>>>>
>>>>>>
>>>>>> We thought the matter was over. I had some unanswered questions on
>>>>>> twitter just before Matthew Holt's twitter reply. (Forgive the twitter
>>>>>> account I registered more than ten years ago that has not been used for
>>>>>> a
>>>>>> long time and cannot meet the risk control; it took a lot of time to
>>>>>> re-register one).
>>>>>>
>>>>>> Until this Issues appeared,
>>>>>> - https://github.com/acmesh-official/acme.sh/issues/4675
>>>>>>
>>>>>> It's hard to imagine such abusive voices in the community and on the
>>>>>> dev-security-policy mailing list. Even though it's an accusation we can
>>>>>> try
>>>>>> to respond to, it's frustrating that this post isn't a technical
>>>>>> accusation. And we found an interesting thing:
>>>>>>
>>>>>> The issuer ID gzchjz007 of
>>>>>> https://github.com/acmesh-official/acme.sh/issues/4675 is highly
>>>>>> similar to the criminal ID gzchenjz of our ddos server!
>>>>>>
>>>>>> When I pointed out that their slander is fake, this ID gzchjz007 and
>>>>>> gzchenjz stopped acting, but a new ID appeared, and came to this
>>>>>> dev-security-policy post. That's why I think they're suspicious:
>>>>>> - [email protected]
>>>>>> - [email protected]
>>>>>>
>>>>>>
>>>>>> Because they are Chinese speaking people, but pretend to be
>>>>>> non-asian. they made same mistake i did, they replied author only but
>>>>>> when
>>>>>> i respond they quick reposted one time suspicious
>>>>>> [image: image.png]
>>>>>>
>>>>>>
>>>>>> they are obviously Chinese to don't understand two button(“回复全部” and
>>>>>> “回复作者”)'s difference, they are very familiar with the Chinese network
>>>>>> but
>>>>>> pretend to be English nicknames and IDs and to bash competitors., and
>>>>>> what
>>>>>> is even more unbelievable is that they did not have any maillist
>>>>>> participation records before this mailing group.
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>>
>>>>>>
>>>>>> But if we look up other real industry participants there must be a
>>>>>> mail listing included.(i tried lookup, No offenses, Mr Kurt Seifried)
>>>>>> [image: image.png]
>>>>>>
>>>>>> I think everyone has the right to accuse because this is freedom, but
>>>>>> it doesn't mean that one person can play multiple roles to abuse this
>>>>>> dev-security-policy mailing list, besides who're affiliated with the
>>>>>> Cybercriminals DDoS Team.
>>>>>>
>>>>>> If they are really an industry participant who will not commit the
>>>>>> misconception that OCSP and CRL will be operated by resellers, please
>>>>>> register an official ID to participate in the discussion. We welcome it,
>>>>>> and I believe the community does too. But I am convinced that they are
>>>>>> the
>>>>>> ones who denial-of-service cyber attacks on our servers, and we have
>>>>>> decided to formally prosecute them for criminal acts.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Roger M Lambdin <[email protected]> 于2023年6月16日周五 14:34写道：
>>>>>>
>>>>>>> Dear members.
>>>>>>>
>>>>>>> I have conducted a background check on HiCA administrator Xiaohui
>>>>>>> Lam and would like to share the following with you. These findings are
>>>>>>> for
>>>>>>> reference only, so please evaluate them for yourself.
>>>>>>>
>>>>>>> First, in 2013, Xiaohui Lam hijacked AFF promotions by exploiting
>>>>>>> vulnerabilities in Aliyun forums, defrauded hostloc members by
>>>>>>> installing
>>>>>>> backdoors in Discuz forum plugins, and stole others' social accounts
>>>>>>> through leaked data from CSDN [^1].
>>>>>>>
>>>>>>> Second, in 2015, Xiaohui Lam exploited a vulnerability in the
>>>>>>> GlobalSign system to sell a large number of 5-year wildcard
>>>>>>> certificates,
>>>>>>> but all certificates were revoked after they were discovered [^2].
>>>>>>>
>>>>>>> I would like to emphasize that these are past actions of HiCA
>>>>>>> administrators and I do not think he will repeat the same mistakes
>>>>>>> again.
>>>>>>> However, these events show that he is not a developer who knows very
>>>>>>> little
>>>>>>> about security. In the past, he has been someone who knew how to mine
>>>>>>> vulnerabilities, exploit them and commit fraud and threats against
>>>>>>> customers.
>>>>>>>
>>>>>>> Based on the above findings, I believe we need to take the following
>>>>>>> steps:
>>>>>>>
>>>>>>> 1. Considering that he suggested users to execute his script RCE[^3]
>>>>>>> with root privileges on his official website, we should send a reminder
>>>>>>> email to all users who have applied for a certificate, asking them to
>>>>>>> evaluate whether there is unauthorized code on their machines.
>>>>>>>
>>>>>>> 2. the results of the query found that Mr. Lam has two CAs: HiCA and
>>>>>>> Quantum CA. the website for registration information about Quantum CA
>>>>>>> is
>>>>>>> acme.hi.cn. then we need to confirm whether they are using the same
>>>>>>> infrastructure and whether Quantum CA also uses RCE to issue
>>>>>>> certificates
>>>>>>> [^4].
>>>>>>>
>>>>>>> Mr. Lam has shut down HiCA's infrastructure after he was found to be
>>>>>>> using RCE, but we still need to do a more detailed assessment.
>>>>>>>
>>>>>>> As a member of the community, I believe transparency and trust are
>>>>>>> vital to us. I hope Mr. Lam will provide the community with a more
>>>>>>> complete
>>>>>>> statement and evidence so that the community can evaluate this incident.
>>>>>>>
>>>>>>> [^1]:
>>>>>>> https://web.archive.org/web/20130816004143/http://bbs.aliyun.com/read.php?tid=144441
>>>>>>> [^2]: https://v2ex.com/t/178503?p=1
>>>>>>> [^3]:
>>>>>>> https://web.archive.org/web/20230325041716/http://www1.hi.cn/docs/getting-started/acme.sh-installation
>>>>>>> [^4]: https://www.tianyancha.com/company/5599034293
>>>>>>> https://www.tianyancha.com/company/3435468365
>>>>>>>
>>>>>> 在2023年6月16日星期五 UTC+8 06:00:39<John Liptak> 写道：
>>>>>>>
>>>>>>>> > First, the cryptography license license is mandatory only for
>>>>>>>> CAs (organizations who operate PKI facilities);
>>>>>>>>
>>>>>>>> You are operating a CRL & OCSP server in China, right?
>>>>>>>>
>>>>>>>> > Secondly, There are many sole proprietorship (self-employed
>>>>>>>> people) are also selling SSL digital certificates and running their
>>>>>>>> own
>>>>>>>> websites, which is totally unable to enroll ICP Registration License.
>>>>>>>>
>>>>>>>> Just because someone else is doing the same thing doesn't mean it's
>>>>>>>> not illegal.
>>>>>>>>
>>>>>>>> > your post is completely weering off topic.
>>>>>>>>
>>>>>>>> I'm concerned with SSL.com CP/CPS 5.3.1. It claims "SSL.com
>>>>>>>> verifies the identity and trustworthiness of all personnel, whether as
>>>>>>>> an
>>>>>>>> employee,
>>>>>>>> agent, or an independent contractor, prior to the engagement of
>>>>>>>> such person(s)."
>>>>>>>>
>>>>>>>> If an independent contractor operates illegally in his/her country,
>>>>>>>> how can he/she be considered trustworthy?
>>>>>>>>
>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/64157954-dd43-41c3-9801-b7019f093f7en%40mozilla.org.
