Hi Ryan, Regarding the client code issue you mentioned, SHECA has assigned personnel to perform an emergency fix. Due to the current public holiday in China, the incident handling process may be slightly slower. I will continue to monitor the progress of the fix.
Regarding the API issue you mentioned, I need to consult with my colleagues for details, and it's late at night in mainland China, so I can't reach them immediately. SHECA will respond to you as soon as possible tomorrow. Best Regards! On Tuesday, October 7, 2025 at 12:09:42 AM UTC+8 Ryan Hurst wrote: > The insecure (fallback to math.random() for entropy) and non-production > quality of the client-side CSR tool is one thing but if this new > information about the server-side API is correct, this represents what I > believe to be a direct BR violation. > > If correct, your API requires subscribers to POST their private key to > your server. This at a minimum suggests a fundamental misunderstanding of a > CA's role and the purpose of a CA. The BRs are so predicated on the > assumption that CAs understand that good key management requires the > subscriber's obligation to protect their own key, the rules don't even > explicitly state that a CA should not undermine that obligation. By > offering this API, you signal to customers that this dangerous practice is > secure, when the CA is supposed to be the expert on these requirements. > > Specifically, section 9.6.3 of the Baseline Requirements mandates that CAs > require subscribers to agree to the following: > > An obligation and warranty by the Applicant to take all reasonable > measures to assure control of, keep confidential, and properly protect at > all times the Private Key that corresponds to the Public Key to be included > in the requested Certificate(s)... > > If the thread is correct, your API makes it impossible for a subscriber to > uphold this warranty. The defense that "SHECA will not record any user's > private key information" is irrelevant. The prohibition is against access, > not just storage. This is why for TLS certificates, CAs are not allowed to > generate the keys for the subscriber at all. *Section 6.1.1.3* states: > > 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... > > The moment the key hits your server, the associated security > properties achieved through those statements are broken. > > Again, if true, this server-side API, viewed alongside the client-side > code, paints a disturbing picture. > > Ryan Hurst > > On Sun, Oct 5, 2025 at 8:31 AM 王家泰 <[email protected]> wrote: > >> Hi Linh, >> >> According to the previous discussion, the SHECA SSL Online Order Platform >> and its externally provided APIs are used for selling SSL certificates of >> the SHECA brand and international CA brands. >> >> The two APIs mentioned in the email are specifically provided to partners >> for generating CSR and converting certificate formats for international CA >> brand certificates. >> >> The service is executed on the server side, but in the process of calling >> these two APIs, SHECA will not record any user's private key information. >> >> Please feel free to ask if you have any other questions. >> >> >> >> Original: >> >> - From：Linh Bach Quang <[email protected]> >> - Date：2025-10-05 14:08:11(中国 (GMT+08:00)) >> - To：[email protected]<[email protected]> >> - Cc：Alvin Wang <[email protected]> , Ryan Hurst <[email protected]> >> , [email protected]<[email protected]> , Lambert Evans < >> [email protected]> >> - Subject：Re: SHECA:TLS certificate key generation online >> >> Alan, >> >> I saw an API documentation of SHECA, involving two API paths and >> parameters related to private key. >> >> In section 3.2 Tools, it describes the function of using API call to >> generate the CSR online. Both the response parameters and the response >> examples include information related to the private key. >> >> Request URL:/open-api/v2/tools/gen-csr >> >> >> [image: lQDPD3hjOCZL783NATrNA9SwwchEd55XrvkIvgJ4IML5AA_980_314.jpg.png] >> >> [image: lQDPM4dMBKLZz83NAwTNA-iwqNgr43W5ekgIvgJ4IQJKAA_1000_772.jpg.png] >> >> >> In section 3.3.14 Dowload Certificates, the API request parameters also >> include private key information. >> >> Request URL:/open-api/v2/order/download-zip >> [image: lQDPD3bTCrJnVo3NArjNA5SwdbQTlUiJ5ssIvgKXH94wAA_916_696.jpg.png] >> [image: lQDPD4USHZPz9o3NAbDNA5SwbU0txNzOUSAIvgKXH3TJAA_916_432.jpg.png] >> >> I am wondering if these two functions are performed on the server side? >> Will providing the service in this way pose a security threat to the >> customer's private key? >> >> Regards. >> Vào lúc 23:16:54 UTC+8 ngày Thứ Bảy, 4 tháng 10, 2025, Alvin Wang đã viết: >> >>> Hi Ryan, >>> >>> Thank you very much for your professional reply. SHECA has forwarded the >>> code implementation issues you mentioned to our R&D department, who are >>> currently evaluating a corrective action plan. Once the corrective action >>> is completed, SHECA will release the complete code on GitHub for community >>> review. >>> >>> Once again, thank you for your support and assistance! >>> >>> On Saturday, October 4, 2025 at 5:42:06 AM UTC+8 Ryan Hurst wrote: >>> >>>> Thanks for sharing the details and code. >>>> >>>> From my perspective, this isn’t inherently non-compliant with the TLS >>>> Baseline Requirements. The relevant section is 6.1.1.3 – Subscriber Key >>>> Pair Generation: >>>> >>>> 6.1.1.3 Subscriber Key Pair Generation >>>> >>>> If the CA generates the Key Pair on behalf of the Subscriber, then the >>>> CA SHALL NOT archive the Subscriber Private Key. The CA SHALL encrypt the >>>> Subscriber Private Key for transport to the Subscriber. The CA SHALL NOT >>>> have access to the Subscriber's Private Key once the Subscriber has taken >>>> possession of it. >>>> >>>> If the Subscriber generates the Key Pair, the CA MUST use a process >>>> that verifies that the Key Pair meets the minimum requirements of Section >>>> 6.1.5 and SHALL reject CSRs that are incapable of being used to issue a >>>> certificate that complies with these Requirements. >>>> >>>> Nothing in the BRs prohibits a CA from distributing software or code >>>> that performs client-side key generation. A JavaScript-based CSR tool >>>> isn’t >>>> automatically out of scope. >>>> >>>> However, this implementation is not production-grade: >>>> >>>> - >>>> >>>> Weak entropy fallback, the code relies on jsrsasign for key >>>> generation. While modern browsers support >>>> window.crypto.getRandomValues(), >>>> the implementation lacks proper handling when this isn’t available. It >>>> can >>>> silently fall back to weak sources like Math.random() and time-based >>>> seeding. The correct behavior is to fail closed if WebCrypto is >>>> unavailable. >>>> - >>>> >>>> Hand-rolled JavaScript cryptography is fragile; timing side >>>> channels, integer handling quirks, and lack of formal verification >>>> introduce significant risk. WebCrypto (SubtleCrypto) exists precisely >>>> to >>>> avoid these problems, with constant-time native implementations. Not >>>> using >>>> it means choosing a weaker, more vulnerable approach when a stronger >>>> mechanism is built in. >>>> - >>>> >>>> Deprecated code path, the CSR helper shown (CSRUtil.newCSRPEM) is >>>> deprecated within jsrsasign. Deprecated paths may contain unserviced >>>> security defects or bugs, making them unsuitable for a CA-promoted tool. >>>> - >>>> >>>> Plaintext key delivery, the tool delivers the private key to the >>>> user as plaintext PEM. While not strictly prohibited by the BRs when >>>> the >>>> subscriber generates the key pair, this is risky in practice. Keys left >>>> in >>>> download folders or synced to backups are routinely lost track of. When >>>> we >>>> built our STIR/SHAKEN CA at Martini Security, we required encrypted >>>> private-key downloads for this reason—it was the only reliable way to >>>> prevent inevitable sprawl and exposure. >>>> >>>> In my view, the minimum bar for subscriber-side CSR generation should >>>> be: >>>> >>>> 1. >>>> >>>> WebCrypto for keygen and entropy (SubtleCrypto.generateKey + >>>> crypto.getRandomValues). Fail closed if unavailable. >>>> 2. >>>> >>>> Encrypted private-key export (PKCS#8 EncryptedPrivateKeyInfo with >>>> PBES2/PBKDF2). >>>> 3. >>>> >>>> Auditable and pinned build: strict CSP, SRI on bundles, offlineable >>>> package for transparency. >>>> 4. >>>> >>>> Reject CSRs that don’t meet minimum key strength per BR 6.1.5. >>>> >>>> Bottom line from my perspective is that this isn’t a direct BR >>>> violation, but as implemented, it is not the kind of key-generation flow a >>>> publicly trusted CA or reseller should provide. If a CA chooses to offer >>>> such a tool, it needs to be held to the same standard of care as any other >>>> critical part of the certificate issuance process. >>>> >>>> Ryan Hurst >>>> >>>> On Fri, Oct 3, 2025 at 10:50 AM Alvin Wang <[email protected]> wrote: >>>> >>>>> Hi, Ryan. >>>>> >>>>> The following is SHECA's response to your question: >>>>> >>>>> Technology Used >>>>> SHECA uses JavaScript code to implement the relevant encryption >>>>> functions. The relevant core code is attached for your reference. >>>>> >>>>> Code Execution Environment >>>>> All encryption-related operations are performed using JavaScript in >>>>> the client browser. Specifically, when the client submits a certificate >>>>> request, JavaScript code is called to generate the required encrypted >>>>> data. >>>>> Therefore, no JavaScript server-side processing is involved. >>>>> >>>>> The core code is attached for further review and optimization as >>>>> needed. >>>>> >>>>> -- >>>>> 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/c3da349d-3c96-4a6e-8ae9-29e6eaf302b7n%40mozilla.org >>>>> >>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c3da349d-3c96-4a6e-8ae9-29e6eaf302b7n%40mozilla.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >> -- >> 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/AJ6ArQDQJioQTCkvQJAb5aq2.3.1759674705244.Hmail.wangjiatai%40sheca.com >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AJ6ArQDQJioQTCkvQJAb5aq2.3.1759674705244.Hmail.wangjiatai%40sheca.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/231a29b7-2a97-423e-af01-f4ddabd94ddfn%40mozilla.org.
