Hi, Arabella Thank you for your professional reply. SHECA will rigorously verify the two points you mentioned! Best Regards!
On Friday, October 10, 2025 at 9:00:56 PM UTC+8 Arabella Barks wrote: > Alvin, > > I believe reissuing without additional DCV is compliace if SHECA ensures: > - The domain name's status is not one of the following: expired, or > re-registered after expiration within the TLS validity period pending > revocation (the registration date can be checked using WHOIS); > - reissuing CSR generated by subscriber, not generated by SHECA; > > I believe it's compliance based on two prerequisites: > - CSR noncompliance does not affect the authenticity of the user's > intention to apply for SSL; > - BR defines a 13-month DCV for reuse and does not impose such additional > conditions. > > Correction is welcome. > > Arabella Barks > On Friday, October 10, 2025 at 8:13:01 PM UTC+8 Alvin Wang wrote: > >> 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/0cb5ded4-aaa4-4712-9e08-96bf5182a078n%40mozilla.org.
