Lambert, AI-gen contents is not reasonable here to comment. Because the same prompt might produce different answer by AI-model.
Here is mine AI-gen answer, generated by Gemini. https://g.co/gemini/share/78069859073c, he says "the answer is yes, the CA can reissue the certificate without performing domain validation again, provided the original validation is still within the allowed reuse period." and "the revocation was required because of a CA process failure (improper private key generation), not because the subscriber lost control of the domain. This distinction is crucial." So i suggest don't use AI generated answer in MSDP. Arabella Barks On Friday, October 10, 2025 at 11:05:02 PM UTC+8 Lambert Evans wrote: > Alvin, > Thank you for your reply. > > Since I’m not an expert in this field, I submitted the discussion URL to > ChatGPT to help me understand the issue better. > Below is the feedback I received. I’d like to share it here and ask other > experts to take a look and provide their thoughts. > > [image: mmexport1760107437586.jpg] > > On Friday, 10 October 2025 at 15:38:52 UTC+2 Alvin Wang wrote: > >> 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/ffd4e518-c801-4dad-ba55-6c4ace61b783n%40mozilla.org.
