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/200ca00c-1094-4834-817f-93c98a578c92n%40mozilla.org.
