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/638e6234-c160-43a9-b7c6-a149b7b1982bn%40mozilla.org.
