RCE used by Intermediate CA to issue certificates.

[John Han (hanyuwei70)]

Here is the story.
https://github.com/acmesh-official/acme.sh/issues/4659

Seems like they exploited acme.sh and let user to evade certificate issuing procedure.

Do we need to discuss this?

[Andrew Ayer]

The party in question (HiCA/QuantumCA) is not a certificate authority,
and I don't see any evidence that the actual CAs in question evaded any
validation requirements.

HiCA/QuantumCA is just acting as an intermediary between subscribers
and the issuance APIs operated by actual CAs[1]. Literally anyone can
do this and do monumentally stupid/insecure things; it's not productive
to have a discussion every time this happens.

Regards,
Andrew

[1] It's true they have a reseller relationship with ssl.com, who are
operating a white-label intermediate CA with "QuantumCA" in the
subject, but HiCA/QuantnumCA are also fronting other CAs, including
GTS, which doesn't require a reseller agreement to access their free
ACME API, so I don't see that aspect as being productive to discuss
either.

[Kurt Seifried]

More details:

https://twitter.com/aleksejspopovs/status/1666955050696966148

https://www.reddit.com/r/netsec/comments/144ygg7/acmesh_runs_arbitrary_commands_from_a_remote/

My one thought is this:

Shouldn't the root CA(s) that ultimately empower this reseller have some process to ensure they only mint trusted authorities that only mint trusted authorities and so on? And if a rogue intermediate/reseller CA pops up shouldn't they deal with it?

Because otherwise, I can stand up a root CA, and then sign intermediate CAs/resellers that do all the dirty/evil work and say "LOLZ. I'm a root CA. I didn't sign this. It's this bad intermediate/reseller CA, go punish them"

And seeing as how you can stand up an intermediate/reseller in literal minutes if you have a captive root CA to sign off on it...

I feel like the CCADB/Mozilla have abdicated responsibility in the sense of "well the root CA didn't do anything technically wrong..." rather than taking the approach of "shouldn't we encourage/force root CAs to be responsible for their downstream CAs and ensure a safe ecosystem for everyone?"

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20230609090430.3a4e8396e6e0b856fc81c6ab%40andrewayer.name.

--

Kurt Seifried (He/Him)
ku...@seifried.org

[mochaaP]

Hello,

Although HiCA is not a CA itself, the person own HiCA seems also owns (or at least works for) Quantum CA[1][2]. they also confirmed that Quantum CA is operated by both their team and SSL.com team[3].

I think this probably is not as simple as a white-label intermediate CA being abused, rather a CA that resells their own product to themselves to prevent being punished for bad behaviors.

[1]: https://github.com/xiaohuilam (see "Pinned" section)
[2]: https://github.com/quantumca (see "People" section)

[3]: https://github.com/acmesh-official/acme.sh/issues/4659#issuecomment-1584546150 (note that this person never clearified their relationship with Quantum CA and only replied with "So this isn't the evidence to proof HiCA is a CA which managed PKI.")

Regards,

Zephyr Lykos

[Xiaohui Lam]

Thanks John to share this topic to the dev-security forum.

This is HiCA founder, let me to explain your concern, Mr John ,
the RCE is fully used to finish the challenge which validated by CAs, in another word, the ACME.sh-enrolled certificates which passing this RCE, it does compliant with each CA's BR validation requirements. CA did nothing wrong. And also by this trick can enroll any CA's certificate before acme.sh fix patch.

and to Mr @mochaaP, you said to punish our team, we're NOT a public CA or private CA(in my understanding, a CA must manage a or more PKI infrastructure physically), [3]so the clarify relationship to HiCA w/ QuantumCA is no necessary, but we still told we runs HiCA inside QuantumCA project's source code, it's a sub-application inside it.

I agree @Andrew's opinion, CAs shouldn't take any responsibilities to the RCE incidents. or there are hundreds acme-tools for CAs need to concern.

[Thomas Zermeno]

We would like to clarify that SSL.com discontinued issuing Quantum certs in 2022, and haven't issued any certs from the Quantum branded ICAs in 2023. Furthermore, there is absolutely no association between HiCA and SSL.com. In fact, only through the recent acme.sh RCE public discussions were we made aware of the existence of HiCA.

As a result, we took the initiative to further investigate and discovered that QUANTUM CA LIMITED dissolved on November 1, 2022. We were not notified about this change by Quantum.

Based on this fact, we plan to revoke the Quantum branded subCAs and all associated end-entity certificates within 7 days, as mandated by section 4.9.1.2 of our CP/CPS.

Regards,

Tom

SSL.com 

[Kurt Seifried]

Is this an official statement from ssl.com? If so can you please provide proof that madca...@gmail.com is authorized to speak on behalf of ssl.com? 

Seriously, why do all these CA's lack the ability to host their own email?

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/528b5350-1a32-4730-8e7b-16644d135274n%40mozilla.org.

[Kurt Seifried]

Is this an official statement from  HiCA? If so can you please provide proof that inao...@gmail.com is authorized to speak on behalf of HiCA? 

Seriously, why do all these CA's lack the ability to host their own email?

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/431eb7de-181e-4a32-9d22-3698bc7b0d0bn%40mozilla.org.

[Xiaohui Lam]

Yes, I'm staff for HiCA which on behalf of HiCA officially.

Those mail is sent from our server, not CAs. It's another project for reselling ssl.com(no selling anymore half year ago)'s mail template. these projects they are included in one source code repository(screenshot-of-eab-notification-email-source-code.png), and email template/layout is shared between some of them. we copied mail layout/template from ssl.com notify email and forget to update to our information, it's no associated with ssl.com mailing system.

And  all

[Xiaohui Lam]

Sorry for a typo:

`It's another project for reselling ssl.com(no selling anymore half year ago)'s mail template` 

->

`It's another project for reselling ssl.com(no selling anymore half year ago)'s certificates` ...

[mochaaP]

Hi Xiaohui,

I think you may have misunderstood my message. What I meant to convey was that I am skeptical of your intention to resell your own CA for a dissolved Ltd. that was not subject to having its certificate revoked. We believe that this practice is uncommon for a reseller in such a case.

Please understand that my message was not intended to be hateful towards you or your team. If you believe that this was an honest mistake, please reply to this thread with more details. The community values transparency and trust, and we would be happy to hear your perspective.

Best regards,

Zephyr Lykos

[Xiaohui Lam]

Mr mochaaP,

We're running businesses under multi entities, one is UK company, and one is CN company, the UK company is registered and running by a former workmate which leaved our team, and CN company is registered and running by me.

We do stopped from selling SSL.com certificate due to business concern and the cross-sign root expiration concern, That meantime we do have some cooperates with other CAs without whitelabel/intermediateCA, some CAs are directly implemented and some are tier-2 implements(under other resellers). So, our website is kept running, including HiCA keeps.

But we will stop all misleading business to stop provide our Quantum brand products, only contain our China company's materials.

My KEY OPINION: our China entity has been kept in existence so we kept the reselling business.

Sincere.

Bruce Lam

[Kurt Seifried]

Is this really a situation where something extremely suspicious (remote code execution, CA's with multiple entities, some of which don't seem to properly exist, etc.) is going to be swept under the rug with a simple "yeah, we revoked this bad actors certificates, everything is fine"?

If HiCA can do this, how do we know there are not more intermediate/reseller CAs doing this?

https://news.ycombinator.com/item?id=36252310.

Just a note, apparently, websites have been shut down and stuff deleted with respect to HiCA.

Posting some of the threads here in case they get removed or whatever:

==================

egecks 1 day ago | prev | next [–]

I think the title buries the most horrifying part of this. The HiCA certificate authority is relying on an RCE to do an end-run around the semantics of the ACME HTTP-01 validation method.
Fucked up and they should be booted from every root program for this.

=================

0x0 1 day ago | prev | next [–]

Looks like they are issuing under a sub-CA of "ssl.com" according to https://github.com/acmesh-official/acme.sh/issues/4659#issue...
Interestingly, the mozilla dev-security-policy group seems to contain a recent discussion about including "ssl.com" in the root store here https://groups.google.com/a/mozilla.org/g/dev-security-polic...

Curious to know if this could, maybe it should, have ripple effects to the various SSL Root CA programs. Having someone run a subCA that actually exploits an RCE against ACME clients doesn't seem very trustworthy, and any CA enabling this behaviour should probably be kicked out of the trust stores?

reply


agwa 1 day ago | parent | next [–]

The sub CA is operated by ssl.com, not HiCA (which is not a trusted certificate authority). HiCA is relaying the certificate requests to ssl.com, which is properly validating the requests in accordance with all the requirements. ssl.com isn't doing anything wrong. That's why HiCA needs to exploit an RCE in acme.sh - ACME doesn't support relaying certificate requests to other CAs like this.
reply


0x0 23 hours ago | root | parent | next [–]

Someone posted a comment on github claiming they are the founder of Quantum (the sub CA of ssl.com - see https://crt.sh/?caid=200960 ) and that they are the provider of the HiCA service. So it does sound like there is a closer link here than your comment would indicate:
https://github.com/acmesh-official/acme.sh/issues/4659#issue...

reply


agwa 23 hours ago | root | parent | next [–]

Quantum is not a trusted CA. ssl.com has a white-labeled intermediate CA with the name "Quantum" in it, but this intermediate CA is operated by ssl.com under all the same controls as ssl.com's other intermediate CAs. Quantum has no ability to issue trusted certificates themselves.
reply


0x0 23 hours ago | root | parent | next [–]

So the person claiming to be the founder of "QuantumCA" does not possess the private key corresponding to https://crt.sh/?caid=200960 - can we be sure the private key is only accessible by ssl.com's CA system? So the certificates listed here aren't issued by this person, but by the ssl.com's system? https://crt.sh/?Identity=%25&iCAID=200960&exclude=expired&de...
Also, why would ssl.com even create a subCA named "QuantumCA"? Are they in business with this person claiming to be the founder of "QuantumCA" who appears to be responsible for exploiting this acme.sh 0day? What does this say about ssl.com's trustworthiness? Or is the person in the github comments lying?

reply


agwa 23 hours ago | root | parent | next [–]

> So the person claiming to be the founder of "QuantumCA" does not possess the private key corresponding to https://crt.sh/?caid=200960 - can we be sure the private key is only accessible by ssl.com's CA system? So the certificates listed here aren't issued by this person, but by the ssl.com's system? https://crt.sh/?Identity=%25&iCAID=200960&exclude=expired&de...
Correct. You can see the Quantum intermediates listed in ssl.com's most recent audit statement, meaning an auditor has verified that ssl.com has controls to protect the private key: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?at...

(The audit could be flawed, but it's the same amount of assurance we have for any intermediate CA's private key - the fact that "QuantumCA" is in the name does not change the risk calculus)

> Also, why would ssl.com even create a subCA named "QuantumCA"? Are they in business with this person claiming to be the founder of "QuantumCA" who appears to be responsible for exploiting this acme.sh 0day? What does this say about ssl.com's trustworthiness? Or is the person in the github comments lying?

There is a business relationship between QuantumCA and ssl.com. QuantumCA is a reseller of ssl.com, and they've paid extra to ssl.com so that the certificates they purchase get issued from an intermediate CA named "QuantumCA" rather than one of ssl.com's usual intermediate CAs which have "ssl.com" in the name. This lets QuantumCA pretend to be a real CA. This is a common practice in the industry, and I don't think it says anything about the trustworthiness of ssl.com, because the business relationship with QuantumCA doesn't in any way subvert the integrity of the WebPKI since ssl.com retains control of the issuance. Still, I wish intermediate CA white-labeling were banned because it causes terrible confusion about who is and isn't a CA.

reply


0x0 23 hours ago | root | parent | next [–]

I find it troubling that a root CA (ssl.com) is apparently OK with lending their name in a business relationship with an actor that is actively exploiting an acme.sh 0day.

tptacek 20 hours ago | root | parent | next [–]

This feels a little bit like doubling down to find ways to implicate the actual CA instead of the reseller. It's clear how mismanagement by a real CA would make a more interesting story than by this random no-longer-existing pseudo-reseller, but I don't think there's evidence to support that story yet.
reply


0x0 20 hours ago | root | parent | next [–]

But it's not a random pseudo-reseller? The one github comment from "the founder of Quantum CA" seems to say they are also the creator of HiCA, which is the entity that was exploiting the 0day in acme.sh. And the crt.sh link shows an intermediate CA cert named "QuantumCA", signed by ssl.com.
So QuantumCA == HiCA == exploiters of the acme.sh 0day, it's all the same entity? The intermediate CA could just as well be named "0dayexploitersCA"? Why is it not a huge concern that ssl.com is fine with operating such a "0dayexploitersCA" intermediate?

Am I missing something here?

reply

=================

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0f9174b3-02d6-4ff6-a7fa-3b931375076dn%40mozilla.org.

[Kurt Seifried]

Forwarding this to the list, I'm not comfortable with off list discussions in private.

On Sat, Jun 10, 2023 at 11:18 AM Xiaohui Lam <inao...@gmail.com> wrote:

Mr Seifried,

> Is this really a situation where something extremely suspicious (remote code execution, CA's with multiple entities, some of which don't seem to properly exist, etc.) is going to be swept under the rug with a simple "yeah, we revoked this bad actors certificates, everything is fine"?

We are a reseller, not a physical root CA. This is a widely accepted solution for cross border businesses. We have business accepts online payment, the China users needs pay via alipay or wechat, to sign up the merchant we must have a china company,

and foreign needs stripe, merchant must be a non-MainlandChina company. this is not suspicious.

*. I represent the above opinion of my company

> If HiCA can do this, how do we know there are not more intermediate/reseller CAs doing this?

Most CA has no necessary to exploiting this RCE, because they can natively compatible with RFC 8555, they can define own CPS and CP, which contains validation policy, we does because we are not CA and can't to provider RFC 8555 ACME endpoint like a CA does. so a physical root CA has no necessary to provide ACME simulation by RCE. and also there're more difficulties for a ssl reseller to provide ACME service which real CAs won't undergo.

- CSR stage difference: Most CA's subscriber request process or reseller API process, requires CSR be submitted in the `new-order` API, ACME requires CSR be submitted in `finalize` API. I have a topic in letsencrypt community years ago about this - https://community.letsencrypt.org/t/why-acme-requires-domain-auth-first-before-csr/98482

- Challenge difference: Most CA's  subscriber request process or reseller API process's DNS validation requires `_<md5>` / `_dnsauth` dnshost, and dnstype possibly CNAME or possibly TXT, But ACME's DNS validation dnshost is constant: `_acme-challenge`, dnstype `TXT`.  And in a more deep talk ACME's dnsvalue needs publickey's thumbprint + server token which is totally different than traditional way's dnsvalue.

My opinion is community can research how many ACME was publicly provided, and investigate is the provider a physical CA. if is natively compatible with RFC 8555, no worry about that one and continue do investigate next.

*. I represent the above opinion of my personal. not my company.

Sincere,

Bruce.

[Amir Omidi (aaomidi)]

Emailing on my personal capacity:

Xiaohui, can you please confirm that ssl.com was the only actual CA that was used for issuance through HiCA?

[Xiaohui Lam]

Sorry, Mr Seifried, 

It's not meant to PM, I mean to post publicly, i don't know the "post thread" and "reply author"' differences actually.

[Xiaohui Lam]

No, actually we implementing GTS, SSL.com and sometimes Let's Encrypt, Sectigo all the time. and especially SSL.com issued under SSL.com subCA, not under "Quantum Secure Site DV" acutally.

The CA

[Xiaohui Lam]

Because the Quantum security site has OCSP customized services, we must ensure that all certificates under it comply with Chinese regulations, otherwise the ICP filing of OCSP may be revoked. So we can't issue certificates for everyone by default.

在2023年6月11日星期日 UTC+8 10:02:14<Amir Omidi (aaomidi)> 写道：

[Xiaohui Lam]

We agree with SSL.com canceling the 90-day certificate customers under Quantum subCA, but we object to the annual customer service payment.

Should SSL.com refund some of the certificates because they were multi-year subscription certificates purchased?

If not, why not cancel the product purchase entrance for more than 365 days on your website and interface?

It's likely a fraud in business.

It might should not be involved in this dev security group, but we wanna some expanding of this topic with other resellers and CAs in the industry.

[Xiaohui Lam]

Kurt Seifried,

Because there's some translation problem with google groups poor translation, I did not distinguish effectively “reply all"(回复全部) and "reply author"(回复作者).

I clicked the last and triggered PM to your inbox.

It also bothers me that it doesn't show up in the list after I send it.

but the discriminatory connotation of this discomfort frustrates me, very.

在2023年6月11日星期日 UTC+8 02:08:47<Kurt Seifried> 写道：

[Kurt Seifried]

Would it perhaps be best if Mozilla disabled web posting? In my experience with other Google groups it has caused nothing but problems. I also think it is reasonable to assume people participating in this list will have access to a working email account that they can use to post and receive emails from the list. 

If requiring a working email address (ideally from the same domain as the one they claim to represent) is too high of a bar for CAs, then, well, I don't know what to say. I feel like a CA (root, intermediate, reseller or otherwise) should be able to set up their own email domain, no?

[James Kasten]

To be explicit, GTS does not have a business relationship with HiCA.

Normally ACME services have protections against these types of MitM-CAs, but the remote RCE allowed HiCA to bypass these controls [1, 2].

For instance, it is possible HiCA replaced the local client's key authorization during challenge validation with a key authorization provided by HiCA, granting authorization of the domain names to HiCA. HiCA could theoretically use these authorizations to continue to issue certificates for the affected domain names, or revoke the certificates that were issued. 

So clients of HiCA should also consider the lasting effects on the the domains in addition to your normal recovery procedures for an RCE. It may be prudent to reissue and revoke any certificates with your choice of CA directly and to watch certificate transparency logs for any future unintended issuance. GTS allows authorization reuse up to 28 days on our ACME endpoint and issues certificates with lifetimes up to 90 days. Other CAs may differ. By the current baseline requirements CAs can issue 398 day certificates and reuse the authorizations for 398 days [3].

James Kasten
Google Trust Services

1. https://datatracker.ietf.org/doc/html/rfc8555#section-6.4
2. https://datatracker.ietf.org/doc/html/rfc8555#section-10.2
3. https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.7.pdf

[James Kasten]

The final reference should be "3. https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.0.pdf" instead of the 1.8.7 link provided. (It doesn't change the discussion.) My apologies.

James Kasten

Google Trust Services

[Xiaohui Lam]

James Kasten,

We apologize for the impact of the security incident on GTS.
I want to say that we will not do bad things, but we lack the means of notarization.

But there is a suggestion:
GTS could evaluate to disable pre-authorizations for domain names or IP addresses for the next 90 days, to reduce potential impacts of the incident.

[Levi]

I think the key to this issue is "Is the CA should take actions to protect their third-party system security under authorized". This problem included the security of the system, public perception of their morality, and compliance issues. HiCA has used the RCE leak of ACME to add advertising to end users (or commercial activities) but as for now, there are not any security problems that destroy the security of CA reported. A few years ago, Quantum CA used the security leak of CA to issue the certificate which expires a period of 5 years, and now, HiCA used the security leak of ACME to add advertising to end users .

In conclusion, there are things we know:
1. There is not any reported security of CA issues (Sectigo, GTS, and more).
2. HiCA used the RCE leak of ACME but has not caused any security problems (as of now).
3. People think the CA must take action to protect the system security (not only for CA's system)

在2023年6月13日星期二 UTC+8 13:00:45<James Kasten> 写道：

[Thomas Zermeno]

In light of the ongoing HiCA discussion, we feel compelled to provide additional clarity on the subject. Not only were we unaware of the existence of HiCA until recently, but we were unaware that QuantumCA was distributing acme.sh. QuantumCA's reseller account was never enabled for ACME therefore no certs were issued from any of QuantumCA branded SubCAs via ACME at any time.

However, SSL.com's free community ACME 90-day certs have been available since 2021 and we have no involvement, collaboration, or control over any ACME client scripts or applications including HiCA's acme.sh. Our courtesy ACME service is available in a similar vein as other free publicly trusted ACME TLS certificate providers with no restrictions or consideration on which ACME clients are allowed access to this service.

We do not collaborate on any projects with our SSL/TLS SubCA resellers other than to provide them brandable certificates. Many members of the community find brandable SubCAs valuable to help build reputation without having to invest in a fully dedicated CA infrastructure, and most reseller customers handle the privilege of their SubCAs responsibly. Unfortunately, there are cases where abuse, intentional or otherwise, may crop up. At SSL.com, we make every effort to respond swiftly and firmly whenever we are alerted of any issues related to our branded SubCAs.

In particular, SSL.com has already planned revocation of the branded SubCAs within the required 7-day time window from the moment we discovered the dissolution of QUANTUM CA LIMITED, in full compliance with our CP/CPS and the CA/B Forum Baseline Requirements. We are also reaching out to individual subscribers affected by this upcoming revocation event to minimize the impact.

Still, there are lessons to learn from this event. Although our CP/CPS stipulates customers’/resellers’ obligation to notify SSL.com of any business registration modification (which includes dissolution), we plan to introduce proactive measures, such as applying periodic reverification of all SubCA resellers' business registrations.

Finally, we view unwarranted statements, which are probably in violation of the Mozilla Community Participation Guidelines, or individual customer-to-company issues such as “refunds” as off-topic and will directly communicate with the reseller on such matters. We consider dev-security-policy group to be a public Forum to discuss ecosystem-wide security/policy issues and good practices. For example, we could discuss with other CAs to adopt the above-mentioned periodic reverification to further protect the ecosystem. 

Thank you,

Tom

SSL.com

P.S. I have used my Google email address for the m.d.s.p. since 2017. I continued to use it in this public group, after I took on the role of Compliance Manager at SSL.com, as a means to continue the legacy of the account and maintain records of the previous discussions.  Unless otherwise stated, all posts from this address should be considered official replies from SSL.com.

[Xiaohui Lam]

Thomas Zermeno,

>   in full compliance with our CP/CPS and the CA/B Forum Baseline Requirements. We are also reaching out to individual subscribers affected by this upcoming revocation event to minimize the impact.

You mean to get in touch w/ our subscribers to purchase from SSL.com directly in the future? I don't think this is a behave friendly or good reputation of  a CA/Manufacturers to existing/former partners.

There is a proverb called "My customer's customer, isn't my customer".

We stand against poaching our clients, and I'm sure any reseller does too.

[Thomas Zermeno]

Bruce, We want to work with you on notifying the affected parties but we will proceed independently if we have to. We have no intention of "poaching"; we are trying to minimize the impact on those subscribers since the QUANTUM CA LIMITED entity no longer exists. If you want to assist SSL.com in contacting the affected subscribers, please contact us using the options in https://www.ssl.com/contact_us/ and we will route your request to the proper department. Regards,

Tom

SSL.com

[Watson Ladd]

On Sun, Jun 11, 2023 at 6:42 AM Xiaohui Lam <inao...@gmail.com> wrote:
>
> We agree with SSL.com canceling the 90-day certificate customers under Quantum subCA, but we object to the annual customer service payment.
> Should SSL.com refund some of the certificates because they were multi-year subscription certificates purchased?
>
> If not, why not cancel the product purchase entrance for more than 365 days on your website and interface?
>
> It's likely a fraud in business.

That's an interesting word to throw around for someone who has
committed what looks to all the world like a CFAA violation. I'm
struggling to understand why you would think this was acceptable
conduct to use an RCE in issuance, in short running code on sensitive
machines without user consent.

Furthermore the CA business is built on trust. SSL.com is doing the right thing.

Sincerely,
Watson Ladd

> --
> You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f8c61c43-44df-45af-b809-6692cc13edb0n%40mozilla.org.



--
Astra mortemque praestare gradatim

[John Liptak]

I want to point out that 上海帝熙科技有限公司 (HiCA's entity in China) is operating illegally in China. This company does NOT have 电子认证服务许可证, 电子认证服务使用密码许可证, and 电子政务电子认证服务批文 issued by the State Cryptography Administration (国家密码管理局). Moreover, I could not find this company's ICP License (ICP证) on https://tsm.miit.gov.cn/, so they cannot do e-commerce in China. They only have ICP beian, which means their websites can NOT be used to earn profits.

[Xiaohui Lam]

@Watson Ladd,

Again,

We agree ssl.com to cancel free certificates.
It means there aren't only free certificates we're providing.     But also paid certificates, if only annually(1 year) cert been cancelled it be fine we can take it, but there are many multiple year subscription purchased by our users(including some OV certs).
If you bought something with a period of many years, but delivered it on an annual basis, and the merchant ran away after one year, would you defend your consumer rights?
It should sounds fair to refund remaining subscriptions' fee if cancelled?   Especially we haven't to proof OV or EV is associated with HiCA because the CA's OV/OV won't become issued automatically after domain names been validated.     so HiCA didn't implement them ever.
We agree to revoke free certificates because our integrating on HiCA, certificates provided were only free.   No CA's paid product was integrated ever.

We mean we do not agree no additional proceeding for the subscriptions/(certificates to be issued) more than 1 year after revoked

personal word from me, Mr Ladd, It is recommended not to do serious injuries because that are not gentlemen.  Did you see someone disclose that the server was hacked after run `acme.sh --issue --server https://acme.hi.cn/directory` on the Internet, or did you get a completely offensive injection code?  We can accept a source code audit of the project w/ full git log and databases binlog if you're willing to bear the cost and we think it's fair because your keyboard swearing didn't pay for anything but electricity so you want to blame please prove it, if exists and we shall keep our ears open.

[Xiaohui Lam]

Mr John Liptak,

It's not against the regulations, it isn't against CA/B Forum BR or CA's CP & CPS at least.

First, the cryptography license license is mandatory only for CAs (organizations who operate PKI facilities);
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.

And your post is completely weering off topic.

[Xiaohui Lam]

OK,

We'll provide a list of domains of certificate which we've already proceeded replaced certificate to sup...@ssl.com from my email br...@quantumca.limited soon.

Please do not try to contact the email address and contact number of clients on the list.

: -)

Sincere,

Bruce

[Watson Ladd]

On Wed, Jun 14, 2023 at 10:46 AM Xiaohui Lam <inao...@gmail.com> wrote:
>
> @Watson Ladd,
>
> Again,
>
> We agree ssl.com to cancel free certificates.
> It means there aren't only free certificates we're providing. But also paid certificates, if only annually(1 year) cert been cancelled it be fine we can take it, but there are many multiple year subscription purchased by our users(including some OV certs).
> If you bought something with a period of many years, but delivered it on an annual basis, and the merchant ran away after one year, would you defend your consumer rights?

If the merchant broke into my home to deliver it, I'd be calling the police.

Sincerely,
Watson Ladd

[Amir Omidi]

Emailing on a personal capacity. 

If you’re offering to open source the RCE code you were using with this. I’m sure that would be helpful.

It is never acceptable to build a business on top of an RCE. The right move would’ve been to disclose this bug. 

--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/heXVr8o83Ys/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0c%3DjQwd035WhDnWJe-BfrKY8Xfxq0_cKUFHDj2W4oWe6-Q%40mail.gmail.com.

--

Amir Omidi (he/them)

[Xiaohui Lam]

Amir Omidi

> If you’re offering to open source the RCE code you were using with this. I’m sure that would be helpful.

We're involved to reveal the RCE working code analysis on my blog, before 17, June.

And reveal a new reveal unsafe variable injection/pollution problem on ACME.sh v3.0.6 on it.

Opensource repo to RCE one ACME.sh v3.0.5 would take some time, because desensitization for variables&datas, and independence from our main repository(HiCA it's a sub-application in it).

> It is never acceptable to build a business on top of an RCE. The right move would’ve been to disclose this bug. 

I didn't realize that this would cause serious security problems in the past(but now i do), I'm not a professional security researcher(I don't understand the RCE standard. The security vulnerabilities I have learned in the past are CSRF, SSRF and the like); so I used it for the domain of `/.well-known/pki-validation` validation out of the idea of building a cool tool(HiCA), a easier to disseminate free certificates to the community.

I now understand it was a mistake, My apologies.

[Xiaohui Lam]

Watson Ladd,

Are you advising our client to accept deprivation of the remaining 4 years of the certificate w/o CA' evaluation whether it is affected by RCE certificates of them ?
Sorry we dare not make such a suggestion because we are resellers. Nor Akamai's resellers won't if incidents happen.

Sincerely,
Bruce Lam.

[inao...@gmail.com]

> >  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?

We never operates the CRL and OCSP responders. But CA does(SSL.com can confirm it). 

Don’t do the uncertain charge if no evidence. Please provide the wrong information source! Before you provide this malicious fabrication I’ll share no more information on your post anymore.

> > 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.

Cryptography license isn’t required for reselling business. For sure. 

>> 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?

SSL.com didn’t verify the Licenses and Permits. So, 

there is no association between SSL.com CP/CPS 5.3.1 and conclusion in your words.

---

发自我的iPhone

------------------ Original ------------------

From: John Liptak <johnli...@gmail.com>

Date: Fri,Jun 16,2023 4:59 AM

To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Cc: Thomas Zermeno <madca...@gmail.com>, Xiaohui Lam <inao...@gmail.com>

Subject: Re: RCE used by Intermediate CA to issue certificates.

>  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?

[John Liptak]

[xiaohuilam]

Your horner Mozilla PKI Policy team and CA members,

The accusation is fabricated and I have good evidence that bir...@gmail.com and johnli...@gmail.com 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.


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:

(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:

- bir...@gmail.com

- johnli...@gmail.com

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

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.

But if we look up other real industry participants there must be a mail listing included.(i tried lookup, No offenses, Mr Kurt Seifried)

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 <bir...@gmail.com> 于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

[Roger M Lambdin]

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> 写道：

[Amir Omidi]

Mailing on a personal capacity. 

> please register an official ID to participate in the discussion

There has never been a requirement to do this, and it is not acceptable for you to suggest that someone needs to pass some arbitrary barrier before they’re allowed to participate. 

Second, you seem to know a lot about cybersecurity, and cyber attacks while also claiming you didn’t realize exploiting an RCE is a big deal. 

Furthermore, even though you made an offering (potentially not serious, but you still did make the offer). You’ve found various excuses on why you can’t open source the RCE code. 

Either way at this point I don’t think there’s much the MDSP can/should do about this. Your defensiveness against being called out on launching an attack does not bring confidence to your claim that there was no ill intent here.

--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/heXVr8o83Ys/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEi6wDMyvGa26QOoa4CzqqbW-cYJfWDpJDpxS3e1EaGG1TbOng%40mail.gmail.com.

--

Amir Omidi (he/them)

[Xiaohui Lam]

Mr  Amir Omidi,

You misunderstood me,

I never said i refuse to open source RCE poc.

I use to speak there's many business services in the same framework, i need to desensitization and withdrawal, and this will take a certain amount of time. I'll open source it I promise.

[Rob Stradling]

> > please register an official ID to participate in the discussion

I'm not aware of any jurisdiction in which an email address is an "official ID".

> There has never been a requirement to do this

+1

Periodic reminder, quoting https://wiki.mozilla.org/CA):

"If you are a regular participant in MDSP, then please add your name to the Policy Participants page"

...which, quoting https://wiki.mozilla.org/CA/Policy_Participants):

"is an optional list of the names, affiliations (if speaking for a company) and backgrounds of participants in the MDSP mailing list."

It's notable that email addresses do not feature in this page.

---

From: 'Amir Omidi' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: 16 June 2023 18:07
To: xiaoh...@e.hexdata.cn <xiaoh...@e.hexdata.cn>
Cc: John Liptak <johnli...@gmail.com>; Roger M Lambdin <bir...@gmail.com>; Thomas Zermeno <madca...@gmail.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Subject: Re: RCE used by Intermediate CA to issue certificates.

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAOG%3DJULbAtbs-nLrs8ZhapgNHj6-yno0hnytFV9F%3DQmPdMw4EQ%40mail.gmail.com.

[John Liptak]

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.

[inao...@gmail.com]

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 <johnli...@gmail.com>

Date: Sat,Jun 17,2023 10:33 AM

To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Cc: xiaohuilam <inao...@gmail.com>, Thomas Zermeno <madca...@gmail.com>

Subject: Re: RCE used by Intermediate CA to issue certificates.

[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

[Xiaohui Lam]

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. 

[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. 

[San Wong]

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 4.9.7 and 4.9.9.

[Thomas Zermeno]

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 (revoked 2023-06-15 15:53:15 UTC)
   
2. 663E22B3F73CCB78DC74369353AB24C3 (revoked 2023-06-15 15:53:16 UTC)
3. 50758BB068C7CA6BF84CC950ABC26539 (revoked 2023-06-15 15:53:17 UTC)
4. 3348510D6AA99654904848A14BE65170 (revoked 2023-06-15 15:53:18 UTC)
5. 0AF338327C1D48BA41753EBEB9EA6029 (revoked 2023-06-15 15:53:20 UTC)
6. 4EB6AD64EA15BA233C32B0D491670063 (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

[Jesper Kristensen]

Den man. 19. jun. 2023 kl. 21.24 skrev Thomas Zermeno <madca...@gmail.com>:

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. 

I do not follow your logic. According to the description I have seen, the purpose of exploiting the RCE was to use acme.sh with a CA that was not enabled for ACME.