iPAddress certificate bypass DCV on port 80 or 443? Does it compliant BR?

[Arabella Barks]

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

[Aaron Gable]

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 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

--
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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8f7dfd56-20dc-4a9f-bea2-1137d9289255n%40mozilla.org.

[Alvin Wang]

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!

[Suchan Seo]

while SHECA may not doing that It would worth to make a ruleling about if HTTP/HTTPS over port 25 or 22 is/should be allowed as 3.2.2.4.18 has same wording. ACME version of challanges (3.2.2.4.19/20) doesn't have this leeway, because RFCs referanced specified to which port to start

Becase there is no challanges that uses ssh protocal, If not allowed it's redundant and should removed from BR: in context Old version (1.4 era) allowed port 115 (SimpleFTP)  but it was later removed from port list later but other ports are survived.

2024년 6월 23일 일요일 오전 2시 33분 21초 UTC+9에 Alvin Wang님이 작성:

[Alvin Wang]

First, let me clarify a mistake. In the previous comments, the version of SHECA's CPS was wrong.
The latest version of the cps address is as follows:  https://assets-cdn.sheca.com/documents/UniTrust%20Certification%20Practice%20Statement%20v3.7.8.pdf
In CPS, Section 3.2.2.5 describes the rules for IP address verification, and the content is consistent with what I described above.

[Arabella Barks]

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:

[Alvin Wang]

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).

[Alvin Wang]

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

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:

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:

[Arabella Barks]

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.