SHECA:TLS certificate key generation online
Lambert Evans
I have been doing some research recently and discovered a Chinese company offering various online tools for SSL certificates. Among which, I noticed its CSR generation tool and it reminded me of the discussions the community had before on certificate resellers and key security. https://groups.google.com/g/mozilla.dev.security.policy/c/Xio6mrdxp2M/m/m38TJkblAgAJ
This vendor provides CSR creation tool with two methods, online generation and browser generation. However, I'm not yet pretty sure about its implementation details and whether they will store the private keys generated.
CSR Creation Tool:
https://tools.imtrust.cn/#/cert-utils/csr_create.html
Online Toolbox:
https://tools.imtrust.cn/#/home
I further checked the domain imtrust.cn and discovered an SSL online purchase platform https://order.imtrust.cn/ under this domain. And the vendor was found to be SHECA, a trusted CA and full member of CABF.
It shows that, the order placement page also offers the option of CSR online generation. https://order.imtrust.cn/
This situation might be different from the previous discussion on reseller generating key pairs on behalf of end customers. Because SHECA is operating as a CA and offers CSR online generation tool.
I'm not sure whether this site has been included into the audit scope and whether its operation and data protection schemes have been propoerly reviewed. It is also not clear that whether this practice violates the requirements of BR 6.1.1.3.
I'd like to discuss this situation together and also request SHECA to provide a response regarding this matter.
Alvin Wang
Hi, Lambert.
Thank you very much for your report. I will be responding to this incident on behalf of SHECA. SHECA is currently conducting an internal investigation and will respond to this matter as soon as possible.
Best Regards,
Alvin Wang
1. Explanation of CSR Submission Methods on the SHECA SSL Online Order Platform (https://order.imtrust.cn/)
The platform (https://order.imtrust.cn/) provides two CSR submission methods:
Browser Generation
This method is implemented via front-end JavaScript code. All CSRs are generated on the customer's browser (in a plug-in-like manner). The generated CSR and private key will be automatically downloaded to the customer's browser download directory.
Paste CSR
This method allows customers to generate their own CSRs and paste them directly into the platform for submission. The generation of CSRs is entirely completed independently by customers.
2. Explanation of CSR Generation Methods on the online Tool Website (https://tools.imtrust.cn/)
Browser Generation
The principle is the same as described above.
SHECA will make the relevant front-end code publicly available for community inspection to ensure transparency and security. SHECA is willing to discuss with the community whether the use of the above method complies with BR 6.1.1.3.
Online Generation
This method generates CSRs by calling a back-end service interface. The back-end service is independent of SHECA's WebTrut systems (CA system, RA system, Validation system,etc.) and provides an access entry through a separate domain name. This system is not within the scope of the audit.
SHECA does not record or store users' private keys in any form. Meanwhile, SHECA will provide recent back-end service logs for the community to review, so as to ensure transparency. In accordance with the recommendations of the Compliance Department, SHECA has immediately suspended this method pending the results of community discussions.
SHECA provides this certificate tool website because it acts as a reseller for certificates of multiple CA brands.
To optimize the customer experience, SHECA has provided relevant functions to simplify the process for customers to apply for certificates. SHECA respects the results of community discussions and will cooperate without hesitation if rectification is required.
Please feel free to ask any other questions at any time!
Ryan Hurst
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/bfae9a93-9de6-4e43-8530-da95fef66c2an%40mozilla.org.
Alvin Wang
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.
Ryan Hurst
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:
-
WebCrypto for keygen and entropy (SubtleCrypto.generateKey + crypto.getRandomValues). Fail closed if unavailable.
-
Encrypted private-key export (PKCS#8 EncryptedPrivateKeyInfo with PBES2/PBKDF2).
-
Auditable and pinned build: strict CSP, SRI on bundles, offlineable package for transparency.
-
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
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c3da349d-3c96-4a6e-8ae9-29e6eaf302b7n%40mozilla.org.
Alvin Wang
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!
王家泰
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.
- From：Linh Bach Quang <linhbac...@gmail.com>
- Date：2025-10-05 14:08:11(中国 (GMT+08:00))
- To：dev-secur...@mozilla.org<dev-secur...@mozilla.org>
- Cc：Alvin Wang <wangj...@sheca.com> , Ryan Hurst <ryan....@gmail.com> , dev-secur...@mozilla.org<dev-secur...@mozilla.org> , Lambert Evans <lamber...@hotmail.com>
- 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.
Linh Bach Quang
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.
Hi Ryan,
Ryan Hurst
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
extKeyUsageextension containing either the valuesid-kp-serverAuth[RFC5280] oranyExtendedKeyUsage[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
Alvin Wang
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!
Bastian Blank
> The moment the key hits your server, the associated security
> properties achieved through those statements are broken.
Compromise" in the BR? This would trigger a 24 hour revocation
according to 4.9.1.1.
Bastian
--
Killing is wrong.
-- Losira, "That Which Survives", stardate unknown
Alvin Wang
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.
Roman Fischer
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
In section 3.3.14 Dowload Certificates, the API request parameters also include private key information.
Request URL:/open-api/v2/order/download-zip
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1fc46c6e-a9d1-42b6-aeaa-8b1b716af271n%40mozilla.org.
Alvin Wang
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.
Arabella Barks
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.
Matt Palmer
> SHECA provides partners with public and private keys for authenticating
> their API requests.
> /open-api/v2/order/download-zip
> Function: Download certificates in all formats
> Subscriber-provided parameters: Private key and order number
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.
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
> a Key Pair previously generated by the CA.
This violation requires revocation within 24 hours, per 4.9.1.1, point 4.
- Matt
Alvin Wang
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."
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."
"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.
Linh Bach Quang
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.
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
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.
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.
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.
Alvin Wang
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
Function: Generate a certificate request (CSR)
Subscriber-provided parameters: None
SHECA returns: Certificate request (CSR) and private key.
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
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!
Alvin Wang
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!
Arabella Barks
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
Alvin Wang
Thank you for your professional reply. SHECA will rigorously verify the two points you mentioned!
Best Regards!
Lambert Evans
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.
Arabella Barks
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
Matt Palmer
> 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.
the best of my knowledge, a solution widely used by Internet companies.
> 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)).
revocation within 24 hours is required.
- Matt
Alvin Wang
Thank you very much for your attention and support regarding this incident! As a member of the CA/Browser Forum community, SHECA always strictly adheres to relevant community standards. This is our consistent principle.
Regarding your first question, I have compiled a detailed document (https://github.com/SHECA-Alvin/CASE/blob/main/jwt.md) that details SHECA's approach to using public and private keys for interface authentication. I hope it will be helpful for your reference. I also look forward to further communication with you through this document to reach a consensus on the relevant details.
Regarding the certificate revocation you mentioned, SHECA is currently working on the matter and has applied for a delayed revocation (https://bugzilla.mozilla.org/show_bug.cgi?id=1994051). We will promptly update you on any further progress.
If you have any further questions, please feel free to contact us.
Best regards！
Alvin.Wang
Matt Palmer
> Thank you very much for your attention and support regarding this incident!
> As a member of the CA/Browser Forum community, SHECA always strictly
> adheres to relevant community standards. This is our consistent principle.
6.1.1.3. Please do not engage in marketing hyperbole in a technical
forum, it does not benefit SHECA in any way, and only serves to indicate
that SHECA does not take these matters seriously enough to engage in
clear and honest communication with the community.
> Regarding the certificate revocation you mentioned, SHECA is currently
> working on the matter and has applied for a delayed revocation
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1994051).
it is not possible to "appl[y] for a delayed revocation", as a great deal
of prior discussion, and Mozilla's own policies, make abundantly clear.
> Regarding your first question, I have compiled a detailed document
> (https://github.com/SHECA-Alvin/CASE/blob/main/jwt.md) that details SHECA's
> approach to using public and private keys for interface authentication. I
> hope it will be helpful for your reference.
security engineering posture. It mentions that HS256 is the default
algorithm, even though that algorithm uses a shared key (with no
indication of where this shared key comes from), then later in the
"Signature" section it specifically acknowledges that "The private key
should only be accessible to the user", yet the document also states
that "SHECA generates public and private keys in the order system",
which violates this principle. Further, there appears to be confusion
about where the JWT is even generated, as the document states "After
receiving the JWT from the server", which would strongly imply, if a
private key was used to produce the signature, that the private key is
being stored, or is at least continuously accessible in some way, by the
server.
I repeat: this is *not* the way that private keys are used in JWT by
"Internet companies as a security verification method". Examples of how
they are used can be found in specifications like OIDC, where the public
key is provided so that the JWT can be verified, without exposing the
private key to disclosure to *any* other party.
> I also look forward to further
> communication with you through this document to reach a consensus on the
> relevant details.
consulting.
Given that this poor practice around key handling for JWTs, whilst deeply
concerning with regards to SHECA's security practices overall, does not
directly impact Mozilla or the BRs, it's probably not appropriate to
continue discussing this point in this forum, anyway.
- Matt