Thank you for your attention! I will listen to your opinions and describe the specific details of the domain name (IP) control verification of these three certificates in the follow-up comments. This will take some time, and I will announce it before 2024-06-26 09:00:00 (UTC+8).
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/3d1682fd-8e9c-4bbb-8700-475fcc862162n%40mozilla.org.
