Hi All, SHECA would like to confirm a question with the community: In accordance with the current provisions of BR 4.2.1, the verification materials for domains or IPs have a 398-day reusability period. Regarding the certificates that SHECA needs to revoke this time, for those certificates whose organizational and domain verification materials are still within the validity period, is it allowed to reissue them directly under the original orders without re-conducting domain and organizational verification? And does this practice comply with BR requirements? Best Regards!
On Friday, October 10, 2025 at 7:38:41 PM UTC+8 Alvin Wang wrote: > Hi, Linh > SHECA recognizes that the forum discussions are rooted not only in a > supervisory intent but also in a desire to support the refinement of our > work. SHECA has consistently upheld the principles of openness and > transparency, with no intention of withholding any information. SHECA > greatly values the attention and discussions surrounding this matter, and > kindly asks that all participants maintain an objective stance throughout > our communications. SHECA deems it inappropriate to make judgments without > a factual basis. > > Inspection of API users, SHECA attaches great importance to it and carried > out a review immediately. The specific situation is explained as follows: > During the National Day holiday (October 1st - October 8th), as the team > conducted the first round of inspection through remote collaboration, due > to the limitations of resource allocation and remote communication > efficiency during the holiday, the initial inspection scope failed to fully > cover all API types. On the first working day after the holiday (October > 9th), we have arranged the R&D team to conduct a detailed and comprehensive > secondary inspection of all logs. > After final confirmation, there are two partners that have called the > relevant APIs: one is Xinnet, which has been reported previously, and the > other is China Mobile Cloud. Among them, China Mobile Cloud uses an old - > version API which was not included in the standard API list for the first > round of inspection, resulting in omissions during the first round of > inspection. > > APIs Involved in Xinnet: > /open-api/v2/order/download-zip > Function: Download certificates in all formats > Subscriber-provided parameters: Private key and order number > SHECA returns: An encrypted ZIP file containing certificates in various > formats, including Nginx, Tomcat, and Apache. > > /open-api/v2/tools/gen-csr > Function: Generate a certificate request (CSR) > Subscriber-provided parameters: None > SHECA returns: Certificate request (CSR) and private key. > > Certificates Involved in Xinnet: > All valid certificates issued under the two roots (Xinnet DV SSL, Xinnet > OV SSL) before 24:00 on October 9, 2025. SHECA will publish the relevant > certificate list in subsequent cases. > > APIs Involved in China Mobile Cloud: > /openApi/v1/order/getCertInfo > Function: Download certificates in all formats > Subscriber-provided parameters: Private key and order number > SHECA returns: An encrypted ZIP file containing certificates in various > formats, including Nginx, Tomcat, and Apache. > > Certificates Involved in China Mobile Cloud: > All valid certificates issued under China Mobile Cloud accounts before > 24:00 on October 9, 2025. > SHECA will publish the relevant certificate list later in the cases. > > Next Rectification Measures: > The three APIs have been offline according to the specified time nodes. > SHECA will revoke the affected certificates and contact customers for > replacement according to the MRIP&TP. Currently, communication with > customers has begun. > > Point-to-point Responses to Some Questions You Mentioned: > Question 1 > Regarding the tool for converting certificate formats included in the > directory for downloading certificates, SHECA implements it using > Javascript on the front - end. It has been made clear in the previous > discussion that this does not violate the BR regulations. SHECA has > provided the relevant code in the attachment(convert.txt) for community > review. Although SHECA has issued many ICAs, according to SHECA's internal > log screening, no other partners except Xinnet and China Mobile Cloud have > been found to call the above APIs. > Question 2 > Currently, SHECA has taken the above APIs offline, and plans to revoke all > subscriber certificates within validity related to the APIs. > Question 3 > SHECA would like to know through which platform you purchased the > certificate, so that SHECA can conduct verification accordingly. > Question 4 > First of all, SHECA has not received any notification regarding the > compromise of subscribers' private keys so far. > Secondly, it should be clearly stated that SHECA has never recorded any > subscribers' private keys in any form, and this is a security baseline we > strictly adhere to. Partial logs of the aforementioned two APIs of SHECA > are provided in the attachment(log1.png&log2.png), proving that the private > keys are independently kept by users themselves. > Finally, out of the principle of prudence and for the protection of > subscribers' rights and interests, SHECA has published announcements of the > mass revocation event to remind users to immediately cease their current > private keys, and not to use the CSR corresponding to this private key to > apply for any certificate on any platform, so as to mitigate potential > risks. > If you have any questions, you are welcome to discuss with us at any time. > Thank you! > On Thursday, October 9, 2025 at 1:34:40 AM UTC+8 Linh Bach Quang wrote: > >> Hi Alvin, >> >> To obtain a more complete view of the matter, I purchased an SHECA SSL >> certificate and discovered several issues: >> >> 1.The delivered materials included both public and private key >> information in multiple certificate formats, which corresponds to the >> /open-api/v2/order/download-zip interface. >> [image: Magic1.png] >> >> 1.1 There was also an instruction txt file that contained a tool guiding >> customers to upload their private keys for certificate format conversion >> (certificate installation reference: https://www.yuque.com/sheca/kfxgzb). >> In one of the pages, it includes an online certificate format conversion >> tool that receives users’ uploaded private keys. >> https://www.yuque.com/sheca/kfxgzb/gndrhghm75h205vl >> >> [image: Magic2.png] >> >> [image: Magic3.png][image: Magic4.png] >> >> >> 1.2 In your response above, you mentioned only two partners corresponding >> to two ICAs are using the relevant API >> >> -Xinnet DV SSL >> >> -Xinnet OV SSL >> >> However, it looks like the situation may differ significantly from what >> you described. Please reconfirm the scope of affected certificates and >> whether any other interfaces have access to users’ private keys. >> >> I have seen that under the UCA Global G2 Root (https://crt.sh/?caid=36110), >> there are more than 15 ICAs, including SHECA-branded certificates. And the >> current observations indicate they all present this risk. >> >> [image: Magic5.png][image: Magic6.png] >> >> >> >> Based on the above information, it is also needed to consider whether the >> response from the SHECA team is genuine. >> >> >> 2.The interface /open-api/v2/tools/gen-csr, used for generating private >> keys and CSRs, does provide a newPassword parameter to encrypt the private >> key, but it is not mandatory. For SHECA certificates applied from its >> partners, the private keys were encrypted using the default weak password >> 123456. >> >> [image: Magic7.png] >> >> 3.There was not any Subscriber Agreement during the ordering process. >> >> *>These API were authorized by partners when they were provided to them. >> Furthermore, when partners provided these methods to subscribers, they also >> signed corresponding subscriber agreements to obtain user authorization. >> Therefore, SHECA believes that the reason for revocation in this incident >> does not apply to the third point of 4.9.1.1.* >> >> >> 4.Both the /open-api/v2/tools/gen-csr and /open-api/v2/order/download-zip >> interfaces have access to users’ private keys. How does SHECA ensure that >> these private keys (CSRs) have not been used to request additional >> certificates beyond the intended scope? And how will SHECA prevent any >> continued use of these private keys in the future? >> >> Regards. >> >> Vào lúc 19:25:33 UTC+7 ngày Thứ Tư, 8 tháng 10, 2025, Alvin Wang đã viết: >> >>> Hi,everyone! >>> 1. Reply to Matt's comment >>> SHECA adopted this solution to provide partners with public and private >>> keys for identity authentication, and used JWT to verify partners' API >>> requests, because it can effectively prevent unauthorized data access and >>> ensure security. This authentication solution is widely used by Internet >>> companies as a security verification method for external API provision. >>> That's why this solution was considered by SHECA. >>> >>> 2. Which BR Regulation Should be Applied to the Revocation Reason >>> 2.1 Regarding Bastian's Description >>> "According to the definition of 'Key Compromise' in the BR, is the CA >>> considered an unauthorized person? If so, this would trigger revocation >>> within 24 hours in accordance with 4.9.1.1." >>> These API were authorized by partners when they were provided to them. >>> Furthermore, when partners provided these methods to subscribers, they also >>> signed corresponding subscriber agreements to obtain user authorization. >>> Therefore, SHECA believes that the reason for revocation in this incident >>> does not apply to the third point of 4.9.1.1. >>> >>> 2.2 Regarding Matt's Description >>> "If that CSR contains the public key corresponding to the returned >>> private key (and I'm not sure how it could be anything else), and that CSR >>> is later used by SHECA to issue a publicly-trusted certificate that >>> contains serverAuth or anyEKU, that would appear to be a BR violation, per >>> the last paragraph of 6.1.1.3: >>> >>> If the Subscriber Certificate will contain an extKeyUsage extension >>> containing either the values id-kp-serverAuth [RFC5280] or >>> anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on >>> behalf of a Subscriber, and SHALL NOT accept a certificate request using a >>> Key Pair previously generated by the CA. >>> This violation requires revocation within 24 hours, per 4.9.1.1, point >>> 4." >>> >>> SHECA believes that 4.9.1.1 point 4 is not applicable to this case. This >>> is because the generation method of the public and private keys has not >>> been compromised, and external attackers cannot calculate the subscriber's >>> private key from the public key through any known methods (including those >>> mentioned in 6.1.1.3(5)). >>> >>> 2.3 Summary >>> SHECA acknowledges that the aforementioned two interfaces do violate the >>> following rules in BR 6.1.1.3: >>> "If the Subscriber Certificate will contain an extKeyUsage extension >>> containing either the values id-kp-serverAuth [RFC5280] or >>> anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on >>> behalf of a Subscriber, and SHALL NOT accept a certificate request using a >>> Key Pair previously generated by the CA." >>> As well as BR 9.6.3: >>> "The Applicant is obligated and warrants to take all reasonable measures >>> to ensure control, confidentiality, and proper protection at all times of >>> the private key corresponding to the public key included in the requested >>> Certificate (as well as any related activation data or devices, such as >>> passwords or tokens);" >>> SHECA believes that the most appropriate revocation reason for this case >>> is per 4.9.1.1, point 16. Although there is no risk in the method SHECA >>> uses to generate CSRs and private keys, the act of SHECA providing APIs for >>> generating CSRs and private keys does carry certain risks. In the event >>> that SHECA's system is compromised, it could lead to the leakage of >>> subscribers' private keys. SHECA will comply with BR regulations, revoke >>> all certificates applied for through the above two API interfaces within >>> five days, and require users to generate new CSRs and private keys to >>> reapply for certificates. >>> >>> SHECA will open a case on Bugzilla to report follow-ups. >>> Please feel free to ask if you have any other questions. >>> >>> On Wednesday, October 8, 2025 at 7:19:54 AM UTC+8 Matt Palmer wrote: >>> >>>> On Tue, Oct 07, 2025 at 04:52:56AM -0700, Alvin Wang wrote: >>>> > SHECA provides partners with public and private keys for >>>> authenticating >>>> > their API requests. >>>> >>>> That seems like a terrible idea, but would appear to be outside the >>>> remit of the BRs. >>>> >>>> > /open-api/v2/order/download-zip >>>> > Function: Download certificates in all formats >>>> > Subscriber-provided parameters: Private key and order number >>>> >>>> ... again, doesn't appear to be a BR violation, but seems to be an >>>> even more terrible idea. >>>> >>>> > /open-api/v2/tools/gen-csr >>>> > Function: Generate a certificate request (CSR) >>>> > Subscriber-provided parameters: None >>>> > SHECA returns: Certificate request (CSR) and private key. >>>> >>>> If that CSR contains the public key corresponding to the returned >>>> private key (and I'm not sure how it could be anything else), and that >>>> CSR is later used by SHECA to issue a publicly-trusted certificate that >>>> contains serverAuth or anyEKU, that _would_ appear to be a BR >>>> violation, >>>> per the last paragraph of 6.1.1.3: >>>> >>>> > If the Subscriber Certificate will contain an extKeyUsage extension >>>> > containing either the values id-kp-serverAuth [RFC5280] or >>>> > anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair >>>> on >>>> > behalf of a Subscriber, and SHALL NOT accept a certificate request >>>> using >>>> > a Key Pair previously generated by the CA. >>>> >>>> This violation requires revocation within 24 hours, per 4.9.1.1, point >>>> 4. >>>> >>>> - Matt >>>> >>> -- 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c020082f-a661-403b-be68-82de5bca0545n%40mozilla.org.
