Community, Here’s my comments on this thread.
Generating keys and CSRs purely via frontend JavaScript or webassembly should not be treated as a problematic practice. Since CAs never come into contact with private keys, this approach does not violate the TLS BR. When it comes to back-end storage of keys, two scenarios need to be distinguished: - *Well-encrypted private keys*: An encrypted private key, acting as a form of additional entropy, should not be equated to the original-unencrypted private key. If the encryption salt used is information that CAs cannot guess or obtain, this storage method should also be deemed compliant with TLS BR (ref a similar case, see: [Sectigo: Reseller ZeroSSL and Private Key Generation](https://bugzilla.mozilla.org/show_bug.cgi?id=1699756) ), unless: - *Unencrypted or weak-encrypted private keys*: Such cases would require further discussion within the community to determine compliance. Disclosure of interest: I have no relevant conflicts of interest. In fact, I previously raised questions and challenges regarding SHECA. Ara. On Tuesday, October 7, 2025 at 7:52:56 PM UTC+8 Alvin Wang wrote: > Hello, Roman! > > SHECA provides partners with public and private keys for authenticating > their API requests. These public and private keys are unrelated to the > functionality of the APIs themselves. This discussion focuses on the > following two APIs SHECA provides to assist partners in requesting > certificates: > > /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. > > If you have any further questions, please feel free to ask. > > On Tuesday, October 7, 2025 at 7:03:45 PM UTC+8 Roman Fischer wrote: > >> Dear Alvin, >> >> >> >> Do I understand correctly that the keypair generated by SHECA in this >> case is only used to authenticate the customer who wants to access the API? >> The keypar is not used in any certificate issued by SHECA? >> >> >> >> Rgds >> Roman >> >> >> >> *From:* [email protected] <[email protected]> *On Behalf >> Of *Alvin Wang >> *Sent:* Dienstag, 7. Oktober 2025 12:45 >> *To:* [email protected] >> *Cc:* Ryan Hurst <[email protected]>; Linh Bach Quang < >> [email protected]>; [email protected] <[email protected]>; >> Lambert Evans <[email protected]>; 王家泰 <[email protected]> >> *Subject:* Re: SHECA:TLS certificate key generation online >> >> >> >> Hi Ryan! >> >> 1. The following is the detailed description of the above API: >> >> API Authentication >> SHECA will generate a pair of public and private keys for each subscriber >> that requests the API. The partner's public key will be stored in SHECA. >> When a partner initiates a request to SHECA, it first needs to generate a >> JWT (JSON Web Token) signed with its private key and send the JWT to SHECA >> along with the request. SHECA parses the user information in the JWT to >> find the corresponding public key of the partner, then uses the public key >> to verify the signature of the JWT. If the signature verification passes, >> the request proceeds normally; if it fails, the request is rejected. >> >> /open-api/v2/order/download-zip >> >> - Function: Download all certificate formats >> - Parameters provided by the subscriber: Private key and order number >> - Information returned by SHECA: An encrypted ZIP file containing >> certificates in various formats compatible with nginx, tomcat, apache, etc. >> >> SHECA ensures the security of the above API interactions through security >> mechanisms such as JWT authentication, account-bound public keys, and >> encrypted communication. Up to now, SHECA has not encountered any private >> key leakage issues caused by this. >> >> 2. SHECA recognizes that there may indeed be some risks, so it will take >> these two API offline immediately. >> The specific deactivation dates are as follows: >> >> - Certificate Download /open-api/v2/order/download-zip: Deactivation >> Date: 2025-10-07 (UTC+8) >> - CSR Generation /open-api/v2/tools/gen-csr: Deactivation Date: >> 2025-10-09 (UTC+8) >> >> 3. Request for Comments >> According to the log query of the past year, currently only two partners >> corresponding to two ICAs (Issuing Certificate Authorities) are using the >> above API, namely: >> >> - Xinnet DV SSL >> - Xinnet OV SSL >> >> There are a total of more than 5,400 valid subscriber certificates under >> these two ICAs. Although no private key leakage incident has occurred so >> far, SHECA is seeking comments from the community on whether it is >> necessary to revoke and reissue these certificates. >> >> Please feel free to ask if you have any other questions. >> >> 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 >> >> >> >> >> >> In section 3.3.14 Dowload Certificates, the API request parameters also >> include private key information. >> >> Request URL:/open-api/v2/order/download-zip >> >> >> >> 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/1fc46c6e-a9d1-42b6-aeaa-8b1b716af271n%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1fc46c6e-a9d1-42b6-aeaa-8b1b716af271n%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/f3dd9834-001a-4399-9765-503da42f3346n%40mozilla.org.
