Wang, Thank you for your clarification, and responsible attitude, Our community can be sure that Huandu is engaging to tell a marketing false, not CA non-compliance..
I have no further questions about SHECA. Thank all of you. On Wednesday, June 26, 2024 at 2:45:07 PM UTC+8 Alvin Wang wrote: > The following is the complete process of SHECA verifying the IP address > (113.10.156.232) for the above certificate: > > Step 1: ihuandu applies for an IP-supported SSL certificate from SHECA > through the operator platform provided by SHECA. > > Step 2: ihuandu obtains the file verification path and verification value > through the operator platform interface provided by SHECA, as shown in the > figure below > > [image: image] > > > Step 3: By default, SHECA scans the paths under ports 443 and 80 under the > IP to verify whether the expected values are configured. > > The domain name verification scan log of the relevant system is as follows: > > [image: image] > > From the log, we can see that SHECA scanned the expected value through the > 443 port of the IP, and judged that the domain name verification passed. > Since this discussion does not involve organization information validation, > it will not be described in detail here. > > > On Monday, June 24, 2024 at 8:45:57 PM UTC+8 Arabella Barks wrote: > >> Hello, Alvin Wang, >> >> Acorrding to ihuandu's article(now deleted), they have a IP ssl >> demonstration purposes: https://113.10.156.232. >> I found there are three certificates matches this hostname and issued by >> KeepTrust OV TLS RSA CA G1 >> https://crt.sh/?Identity=113.10.156.232&iCAID=299739: >> - https://crt.sh/?id=12806661692 >> - https://crt.sh/?id=12813257892 >> - https://crt.sh/?id=12807160321 >> >> Plesase disclosure the particulars how SHECA did perform domain(IP) >> control validation for 113.10.156.232? >> If you can provide the verification server logs would be more convincing >> to the community. >> >> Thank you. >> On Sunday, June 23, 2024 at 1:33:21 AM UTC+8 Alvin Wang wrote: >> >>> On behalf of SHECA, I am responding to the points that need >>> clarification in this discussion. >>> >>> Thank you, Aaron Gable, for your attention. SHECA immediately reviewed >>> our CPS content after seeing your comment. The latest CPS from SHECA can be >>> found at: >>> https://assets-cdn.sheca.com/documents/sheca-certification-practice-statement-en-v3.6.3.pdf >>> . >>> >>> In the CPS, section 3.2.6 describes the rules for IP address >>> verification: >>> >>> - 1.Section 3.2.6 does not state the use of BR 3.2.2.5.4 for IP >>> verification because this method was prohibited on July 31, 2019. >>> - 2.The section describes SHECA's IP verification methods, where the >>> second item (1) and (2) corresponds to BR 3.2.2.5.1, and (3) corresponds >>> to >>> BR 3.2.2.5.3. >>> >>> >>> Huandu is SHECA's distributor (agent) and does not have any authority or >>> responsibility to issue or verify SSL certificates. SHECA's SSL certificate >>> issuance process strictly adheres to BR regulations. >>> All external disclosures regarding SSL certificate verification rules >>> must be conducted through SHECA's CPS, with no other disclosure channels. >>> Huandu published an inaccurate marketing article without SHECA's consent, >>> and we have urgently contacted Huandu to address this issue. >>> >>> *We hope this clarifies your concerns!* >>> >>> On Saturday, June 22, 2024 at 12:59:29 AM UTC+8 Aaron Gable wrote: >>> >>>> The BRs define an Authorized Port as "One of the following ports: 80 >>>> (http), 443 (https), 25 (smtp), 22 (ssh)". >>>> >>>> The UCA Global G2 Root is operated by SHECA, and their CPS >>>> <https://www.sheca.com/repository> says that they use method >>>> 3.2.2.5.1, as well as potentially method 3.2.2.5.4. (It also lists two >>>> other methods, labeled (2) and (3), which do not appear to correspond to >>>> BRs-approved methods.) >>>> >>>> The BRs say that IP address validation method 3.2.2.5.1 "Agreed-Upon >>>> Change to Website" must occur "via HTTP/HTTPS over an Authorized Port". It >>>> is unclear to me whether using HTTP/HTTPS over port 25 or 22 would be >>>> acceptable given the parenthetical nature of the protocol annotations, >>>> even >>>> setting aside the technical hurdle of actually doing so. >>>> >>>> If we assume that using HTTP/HTTPS over port 25 or 22 is allowed, then >>>> I believe the claim in the linked article could be both accurate and >>>> acceptable by the BRs. >>>> If we assume that using HTTP/HTTPS over port 25 or 22 is not allowed, >>>> or if the actual validation conducted by Huandu on behalf of SHECA occurs >>>> over a different port, then I believe the article's claim would not be >>>> acceptable by the BRs. >>>> >>>> Aaron >>>> >>>> On Fri, Jun 21, 2024 at 8:33 AM Arabella Barks <[email protected]> >>>> wrote: >>>> >>>>> I recently find a Chinese ssl reseller ihuandu.com says they provide >>>>> a ssl product which secures ip address and needn't 80/443 DCV. >>>>> >>>>> > The SSL certificate does not need to force the use of port 80 or 443 >>>>> to verify the public IP management permission, and has a more flexible >>>>> authentication port to help users obtain the SSL certificate of the >>>>> public >>>>> IP in a relatively short time. >>>>> >>>>> https://www.ihuandu.com/pr/hddt/771.html >>>>> >>>>> Does it compliant BR? >>>>> The BR defines: >>>>> > 3.2.2.5 Authentication for an IP Address >>>>> > This section defines the permitted processes and procedures for >>>>> validating the Applicant’s ownership or control of an IP Address listed >>>>> in >>>>> a Certificate. The CA SHALL confirm that prior to issuance, the CA has >>>>> validated each IP Address listed in the Certificate using at least one of >>>>> the methods specified in this section. Completed validations of Applicant >>>>> authority may be valid for the issuance of multiple Certificates over >>>>> time. >>>>> In all cases, the validation must have been initiated within the time >>>>> period specified in the relevant requirement (such as Section 4.2.1 of >>>>> this >>>>> document) prior to Certificate issuance. For purposes of IP Address >>>>> validation, the term Applicant includes the Applicant’s Parent Company, >>>>> Subsidiary Company, or Affiliate. After July 31, 2019, CAs SHALL maintain >>>>> a >>>>> record of which IP validation method, including the relevant BR version >>>>> number, was used to validate every IP Address. >>>>> > >>>>> > 3.2.2.5.1 >>>>> > Agreed‑Upon Change to Website >>>>> > Confirming the Applicant’s control over the requested IP Address by >>>>> confirming the presence of a Request Token or Random Value contained in >>>>> the >>>>> content of a file or webpage in the form of a meta tag under the >>>>> “/.well‐known/pki‐validation” directory, or another path registered with >>>>> IANA for the purpose of validating control of IP Addresses, on the IP >>>>> Address that is accessible by the CA via HTTP/HTTPS over an Authorized >>>>> Port. The Request Token or Random Value MUST NOT appear in the request. >>>>> If >>>>> a Random Value is used, the CA SHALL provide a Random Value unique to the >>>>> certificate request and SHALL not use the Random Value after the longer >>>>> of >>>>> i. 30 days or ii. if the Applicant submitted the certificate request, the >>>>> time frame permitted for reuse of validated information relevant to the >>>>> certificate (such as in Section 4.2.1 of this document). >>>>> > >>>>> > 3.2.2.5.2 >>>>> > Email, Fax, SMS, or Postal Mail to IP Address Contact >>>>> > Confirming the Applicant’s control over the IP Address by sending a >>>>> Random Value via email, fax, SMS, or postal mail and then receiving a >>>>> confirming response utilizing the Random Value. The Random Value MUST be >>>>> sent to an email address, fax/SMS number, or postal mail address >>>>> identified >>>>> as an IP Address Contact. Each email, fax, SMS, or postal mail MAY >>>>> confirm >>>>> control of multiple IP Addresses. The CA MAY send the email, fax, SMS, or >>>>> postal mail identified under this section to more than one recipient >>>>> provided that every recipient is identified by the IP Address >>>>> Registration >>>>> Authority as representing the IP Address Contact for every IP Address >>>>> being >>>>> verified using the email, fax, SMS, or postal mail. The Random Value >>>>> SHALL >>>>> be unique in each email, fax, SMS, or postal mail. The CA MAY resend the >>>>> email, fax, SMS, or postal mail in its entirety, including re‐use of the >>>>> Random Value, provided that the communication’s entire contents and >>>>> recipient(s) remain unchanged. The Random Value SHALL remain valid for >>>>> use >>>>> in a confirming response for no more than 30 days from its creation. The >>>>> CPS MAY specify a shorter validity period for Random Values, in which >>>>> case >>>>> the CA MUST follow its CPS. pg. 36 >>>>> > >>>>> > 3.2.2.5.3 Reverse Address Lookup >>>>> > Confirming the Applicant’s control over the IP Address by obtaining >>>>> a Domain Name associated with the IP Address through a reverse‐IP lookup >>>>> on >>>>> the IP Address and then verifying control over the FQDN using a method >>>>> permitted under Section 3.2.2.4. >>>>> > >>>>> > 3.2.2.5.4 >>>>> > Any Other Method >>>>> > Using any other method of confirmation, including variations of the >>>>> methods defined in Section 3.2.2.5, provided that the CA maintains >>>>> documented evidence that the method of confirmation establishes that the >>>>> Applicant has control over the IP Address to at least the same level of >>>>> assurance as the methods previously described in version 1.6.2 of these >>>>> Requirements. CAs SHALL NOT perform validations using this method after >>>>> July 31, 2019. Completed validations using this method SHALL NOT be >>>>> re‐used >>>>> for certificate issuance after July 31, 2019. Any certificate issued >>>>> prior >>>>> to August 1, 2019 containing an IP Address that was validated using any >>>>> method that was permitted under the prior version of this Section 3.2.2.5 >>>>> MAY continue to be used without revalidation until such certificate >>>>> naturally expires. 3.2.2.5.5 Phone Contact with IP Address Contact >>>>> Confirming the Applicant’s control over the IP Address by calling the IP >>>>> Address Contact’s phone number and obtaining a response confirming the >>>>> Applicant’s request for validation of the IP Address. The CA MUST place >>>>> the >>>>> call to a phone number identified by the IP Address Registration >>>>> Authority >>>>> as the IP Address Contact. Each phone call SHALL be made to a single >>>>> number. In the event that someone other than an IP Address Contact is >>>>> reached, the CA MAY request to be transferred to the IP Address Contact. >>>>> In >>>>> the event of reaching voicemail, the CA may leave the Random Value and >>>>> the >>>>> IP Address(es) being validated. The Random Value MUST be returned to the >>>>> CA >>>>> to approve the request. The Random Value SHALL remain valid for use in a >>>>> confirming response for no more than 30 days from its creation. The CPS >>>>> MAY >>>>> specify a shorter validity period for Random Values. >>>>> > >>>>> > 3.2.2.5.6 ACME “http‑01” method for IP Addresses >>>>> > Confirming the Applicant’s control over the IP Address by performing >>>>> the procedure documented for an “http‐01” challenge in RFC 8738. >>>>> > >>>>> > 3.2.2.5.7 ACME “tls‑alpn‑01” method for IP Addresses >>>>> > Confirming the Applicant’s control over the IP Address by performing >>>>> the procedure documented for a “tls‐alpn‐01” challenge in RFC 8738. >>>>> >>>>> And I am curious much about Does it compliant BR(which method are they >>>>> requiring)? >>>>> and how they conduct reviews to ensure that the IP website identity is >>>>> not being misused? >>>>> >>>>> Root CA: >>>>> CN = UCA Global G2 Root >>>>> O = UniTrust >>>>> C = CN >>>>> >>>>> Intermedia CA: >>>>> CN = KeepTrust OV TLS RSA CA G1 >>>>> O = Shanghai Huandu Info Tech Co. Ltd. >>>>> C = CN >>>>> >>>>> -- >>>>> 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 on the web visit >>>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8f7dfd56-20dc-4a9f-bea2-1137d9289255n%40mozilla.org >>>>> >>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8f7dfd56-20dc-4a9f-bea2-1137d9289255n%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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f72e09ce-9346-41ca-af9e-643423135c38n%40mozilla.org.
