When Five Network Perspectives Must Agree - What Geo Restriction, Geolocation Routing, and Allow-Listed Origins on AWS Do to Domain Validation

First Published: 2026-10-21
Last Updated: 2026-10-21

Public Certificate Authorities (CAs) must verify that an applicant controls a domain before issuing a certificate. Section 3.2.2.9 of the CA/Browser Forum's Baseline Requirements (BR) requires this verification to be supported by multiple, remote Network Perspectives, rather than a single point. This mechanism is called Multi-Perspective Issuance Corroboration (MPIC). Under BR v2.3.1, a minimum of five remote perspectives will be required from December 15, 2026.

A perspective is a single requester on the internet. What a perspective sees is the site's DNS and web server settings, the same as any other user sees. Amazon CloudFront's geographic restrictions, AWS WAF's geo match, Amazon Route 53's geolocation routing, and origin allow lists all modify responses based on the requester's location and IP address. CloudFront excludes validation requests for CloudFront managed certificates from geographic restrictions, specifically for the /.well-known/pki-validation/ path. HTTP-01 for external ACME clients, AWS WAF rules, Route 53 geolocation records, and origin allow lists, however, present the same configuration to the perspective as they do to the end user.

This article reads these settings as contract tables for each AWS setting, rather than as an explanation of MPIC standards. For each setting, the tables list what is visible from the perspective, what AWS has already handled, what no statement was found for, and what remains the responsibility of the user. This article does not rank the suitability of geographic restrictions, AWS WAF, or DNS-01, nor does it discuss pricing.

The information in this article was verified as of October 21, 2026. Section 8 presents observations of AWS's behavior within a single AWS account, observed from the operator's side. No certificate requests were submitted to a CA. The remaining sections are based on reviewing available documentation.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. The Big Picture: Which Layers a Perspective Reaches
4. Section 3.2.2.9 of the BR: Phases, Quorum, and Covered Methods
5. The CA Side: Let's Encrypt and Amazon Trust Services
6. How Each AWS Setting Looks to a Perspective
7. The Paths AWS Has Exempted, and What Stays With You
8. What This Configuration Returned: A Record of AWS-Side Behavior
9. What Cannot Be Confirmed
10. Failure Modes
11. Frequently Asked Questions About Five Network Perspectives and Domain Validation
12. Summary
13. References

1. Scope and Assumptions

This section first sets out the intended readers, the scope, what MPIC protects against, and the sources read. The conclusions come first:

Requirements: Section 3.2.2.9 of BR v2.3.1 outlines the phased increase in the number of perspectives for MPIC. Four phases, from March 15, 2025, to June 15, 2026, are in effect as of the check date. The phase scheduled for December 15, 2026, requires five or more remote perspectives.
CA announcement: Let's Encrypt has announced an increase in the number of remote perspectives from four to six. Staging is planned for October 27, 2026, and production for November 10, 2026. Let's Encrypt does not publish a list of the IP addresses it uses for validation.
The path AWS has exempted: CloudFront excludes requests to the /.well-known/pki-validation/ path for managed certificates from geographic restrictions. CloudFront documentation specifically mentions MPIC as the reason for this exclusion.
What stays with you: External ACME clients' /.well-known/acme-challenge/ directories, AWS WAF rules, Route 53 geolocation records (in the absence of default records), and origin allow lists will remain visible to the perspectives, as configured by the user. No statement was found in the sources that AWS automatically handles these elements for validation requests.
What cannot be confirmed: No statement of where the perspectives are was found in the sources. The BR quorum allows for one or two non-corroborating perspectives. The documentation does not determine whether applying geographic restrictions will result in issuance failures. This article will address this as an inference.

1.1 Intended Readers

This article is intended for developers and operations personnel who:

Operate publicly accessible websites on AWS and use CloudFront geographic restrictions, AWS WAF geo match, Route 53 geolocation routing, and origin allow lists.
Are automatically renewing certificates using AWS Certificate Manager (ACM), Let's Encrypt, and commercial Certificate Authorities (CAs).
Are operating under the assumption that geographic restrictions are not related to certificate validation, and that AWS automatically handles validation. They may also believe that Let's Encrypt validates from five remote perspectives, and that MPIC only applies to HTTP validation. Furthermore, they might assume that Route 53 geolocation routing applies to all records for a domain.

None of these assumptions matches the sources this article read, or each covers a different scope. CloudFront's exclusion is limited to the /.well-known/pki-validation/ path for managed certificates (Section 6.2). Among the settings this article read, this is the only path AWS has exempted (Section 7). CloudFront's geographic restrictions apply to an entire distribution (Section 6.1). Let's Encrypt has four remote perspectives before the announced change and six after it (Section 5.1). BR requires MPIC for DNS methods, as well as for DNS contact methods via email and phone, and for CAA checks (Section 4.5). Route 53 geolocation records are created per combination of name and type (Section 6.4).

1.2 What This Article Covers and What It Does Not

This article addresses the following:

The phases, quorum, distance between perspectives, ban on reuse, and covered methods in Section 3.2.2.9 of the BR.
What Let's Encrypt and Amazon Trust Services publish about their perspectives.
How the following AWS configurations appear from a perspective standpoint: CloudFront's geographic restrictions and managed certificates, AWS WAF's geo match, Route 53 geolocation, geoproximity, and latency-based routing, and origin allow lists that use the CloudFront origin-facing managed prefix list.

This article does not investigate other AWS configurations. It will not make any statements regarding configurations not listed in the table.

This article does not cover:

Pricing and billing mechanisms.
A ranking of geographic restrictions, AWS WAF, DNS-01, and similar options. When a source itself makes a recommendation, this article quotes it as the source's text.
CAA's accounturi and validationmethods, the reuse of domain validation results, and the DNSSEC condition in RFC 8657. This site's What CAA Can and Cannot Stop When DNS Control Is the Weak Link covers these topics.
The history of Ballot SC067 (2024) and the March 15, 2025, phase. This site's TLS Certificate Ecosystem History and Timeline covers these topics.
The schedule for the end of ACM's email validation. This site's Moving AWS Certificate Manager Off Email Validation covers this topic.
General principles regarding Route 53 routing policies. This site's Amazon Route 53 DNS Architecture Guide covers this topic.
General principles regarding origin protection. This site's Amazon CloudFront Origin Architecture Guide covers this topic.
Post-quantum certificates. This site's Post-Quantum Certificates for Public TLS Are Three Proposals That Disagree covers this topic.
Procedures for splitting perspectives, hijacking routes, poisoning DNS caches, or misissuing certificates.

1.3 What MPIC Protects Against

Section 3.2.2.9 of the BR describes the purpose of MPIC as follows: This process can improve protection against equally-specific prefix Border Gateway Protocol (BGP) attacks or hijacks.

The appearance of a domain can vary depending on the location, influenced by the routing and DNS responses at that specific point. MPIC validates the assessment made by the Primary Network Perspective by confirming whether it remains consistent from remote, geographically distant perspectives. The identification of which attacks can be mitigated at which stage is detailed in this site's What CAA Can and Cannot Stop When DNS Control Is the Weak Link.

This article addresses the opposite side. As perspectives become more dispersed, configurations that alter responses based on location can present different appearances from each perspective.

1.4 Sources Read and the Check Date

This article was written after reviewing the following documents on October 21, 2026. Because the documents vary in type, this article and the accompanying table will indicate which document each statement originates from.

Kind	Sources
Normative document	CA/Browser Forum Baseline Requirements, Version 2.3.1 (`docs/BR.md` in `cabforum/servercert`, retrieved 2026-10-21), and the server certificate ballots page
CA documents	Let's Encrypt FAQ and "Challenge Types" (letsencrypt.org); Amazon Trust Services CP/CPS v2.7 (2026-08-19)
CA announcement	Let's Encrypt staff post "Let's Encrypt is adding two additional remote perspectives for domain validation" (community.letsencrypt.org, 2026-10-15)
Community wiki	"Multi-Perspective Validation & Geoblocking FAQ" (community.letsencrypt.org, created 2024-05-10, last edited 2025-01-30)
AWS documentation	CloudFront Developer Guide, AWS WAF Developer Guide, Route 53 Developer Guide and API Reference, CloudFormation Template Reference, ACM User Guide
AWS Knowledge Center	"How do I use AWS WAF to allow or block access to specific URI paths?" (repost.aws)

Let's Encrypt provides documentation in three forms: documents on letsencrypt.org, staff announcements on the community forum, and the community wiki. The wiki is a page that community members can edit and is not an official document from Let's Encrypt. This article will clearly identify which of these three sources each statement is derived from.

2. How to Read the Tables

This section defines the columns in the table presented in this article, as well as how to distinguish between the terms describing status, the values in the data, and the resulting inferences.

2.1 Shared Columns

The contract tables in this article use the following seven column names. The What a Perspective Sees column is unique to this article. The other six columns are common to two related articles on this site.

Column	What the cell holds
`Who Sets It`	The body that decides: a root program, the CA/Browser Forum, the IETF, or AWS
`What It Requires`	What the document requires or permits, in its own words
`Status on the Check Date`	The stage of the document on 2026-10-21, using the terms in Section 2.2
`What a Perspective Sees`	What a CA's Network Perspective receives from that setting, when the documented behavior is applied to the perspective as one more requester
`Where AWS Comes In`	What you can set on AWS today, and what AWS has already done
`No Statement Found`	What the sources do not state, with the sources searched
`What Stays With You`	What no document takes over and remains with the site operator

The What a Perspective Sees column describes the behavior of a setting as documented, but applied from the perspective of a CA's Network Perspective, treating it as one additional requester. This column does not directly state what the documents say; instead, the values represent inferences drawn by this article.

2.2 Terms for Status on the Check Date

The Status on the Check Date column holds only the following eight terms:

Term	Meaning in this article
`Draft policy`	A policy text published and marked as a draft
`Draft pull request`	A GitHub pull request marked as Draft
`Internet-Draft`	An active IETF Internet-Draft that the IESG has not approved
`In the RFC Editor queue`	Approved by the IESG and waiting for an RFC number
`Published RFC`	Published with an RFC number
`In effect`	Shipped in a product or in force in a published policy
`Scheduled`	A date written into a policy that is not a draft
`Announced`	A plan or intent stated in a blog post, slide, or group post, without a policy text

For rows with dates prior to the check date, this article writes In effect. For the row dated December 15, 2026, the date is specified in a published policy, so this article writes Scheduled. The addition of Let's Encrypt's perspectives was announced in a forum post, not within a policy text, so this article writes Announced.

2.3 Documented Values, This Article's Inferences, and Demo Values

The tables in this article contain only documented values, except the What a Perspective Sees column (Section 2.1). When a specific statement cannot be found in the sources, it is marked as No statement found, and the sources searched are named in the same cell or sentence. This article does not state that a particular function is unavailable. Findings derived from combining statements in the sources are presented as inferences in the main text.

The data presented in Section 8 reflects observations made within a single AWS account. The observations pertain to responses from AWS itself, and not to the responses a CA's Network Perspective receives. The Route 53 results include simulated responses returned by Route 53 based on hosted zone configurations, rather than actual DNS queries. These values are placed in a separate section from the documented values to avoid mixing the tables.

3. The Big Picture: Which Layers a Perspective Reaches

The layers that a perspective reaches depend on the validation method. This article divides configurations on AWS into three layers:

Authoritative DNS: This includes records in Route 53 public hosted zones. DNS methods, as well as methods for DNS contact information for email and phone, and CAA checks, are specific to this layer. HTTP and TLS methods also interact with this layer to resolve names.
Edge: This encompasses CloudFront distributions and the AWS WAF Web ACLs associated with those distributions. When the name points to CloudFront, HTTP and TLS methods reach this layer.
Origin: This refers to the servers behind CloudFront, or the servers directly referenced by the name. Allow lists restrict requesters at this layer.

Figure 1 illustrates how the Primary perspective and the five remote perspectives that the BR requires from December 15, 2026, interact with these three layers.

BR states that when performing domain control validation and CAA checks, either the same set of perspectives or a different set of perspectives can be used.

The CA MAY use either the same set, or different sets of Network Perspectives when performing Multi-Perspective Issuance Corroboration for the required 1) Domain Authorization or Control and 2) CAA Record checks

. Regardless of which set is used, the configurations at each layer are evaluated from each perspective.

4. Section 3.2.2.9 of the BR: Phases, Quorum, and Covered Methods

This section examines the BR v2.3.1 documentation. The BR documentation was obtained on October 21, 2026, from the cabforum/servercert repository, specifically from the docs/BR.md file. On the check date, the most recent ballot number listed on the CA/Browser Forum ballots page was SC105, whose title does not reference the dates specified in Section 3.2.2.9.

4.1 Definitions

Section 1.6.1 of the BR defines three terms as follows:

Multi-Perspective Issuance Corroboration: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance
Network Perspective: A system that initiates communication for validation and CAA checking. Its location is defined as The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective.
Primary Network Perspective: The perspective used by the CA to determine its own authority to issue a certificate for the domain and the applicant's authority or control over the domain.

The location of a perspective is determined by the point where traffic is passed to the Internet, not by the physical location of the server. The way CloudFront and AWS WAF determine a requester's country is separate from this (Sections 6.1 and 6.3).

4.2 Five Phases

The Phased Implementation Timeline at the end of Section 3.2.2.9 lists the following five phases:

Effective	Remote Network Perspectives (at least)	Quorum Requirements	Corroborating perspectives across RIR service regions	`Status on the Check Date`
2025-03-15	2	Not required to block issuance	Not stated	`In effect`
2025-09-15	2	MUST be satisfied	Not stated	`In effect`
2026-03-15	3	MUST be satisfied	At least 2 distinct RIRs	`In effect`
2026-06-15	4	MUST be satisfied	At least 2 distinct RIRs	`In effect`
2026-12-15	5	MUST be satisfied	At least 2 distinct RIRs	`Scheduled`

The March 15, 2025, phase states that certificate issuance may proceed even if the number of non-corroborating perspectives exceeds the number the quorum table allows. The original text is

The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table

. The phases from September 15, 2025, onward state that the CA must not proceed with issuance unless the table's conditions are met.

The original text of the December 15, 2026, phase begins with

Effective 2026-12-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives

. It goes on to require that the remote perspectives that corroborate the Primary's determination fall in the service regions of at least two distinct Regional Internet Registries (RIRs).

The list of dates in Section 1.2.2 of the BR includes only one entry for Section 3.2.2.9, dated March 15, 2025. The later four phases are written only in the body of Section 3.2.2.9.

4.3 Quorum, Distance, and RIRs

The BR's Quorum Requirements table maps the number of remote perspectives used to the number of non-corroborations allowed.

# of Distinct Remote Network Perspectives Used	# of Allowed non-Corroborations
2-5	1
6+	2

The criteria for counting perspectives are as follows:

Distance: Network Perspectives are considered distinct when the straight-line distance between them is at least 500 km. BR considers perspectives that are distinct from both the Primary and other perspectives participating in the quorum as remote perspectives.
DNS Resolvers: The recursive resolvers used by a perspective do not need to be co-located with the perspective. However, they must be in the same RIR region as the perspective. Any pair of resolvers used in a single attempt must be at least 500 km apart from each other.
Two Sets: When separate sets of perspectives are used for domain control validation and for CAA checks, the quorum requirements must be met by both sets.

The values in the table represent the range allowed by BR. The CA determines the actual number of perspectives used and the number of non-corroborating perspectives allowed.

4.4 No Reuse, and Retries

The BR forbids reusing the results of one perspective in validation through other perspectives.

Results or information obtained from one Network Perspective MUST NOT be reused or cached when performing validation through subsequent Network Perspectives

.

BR states that immediate retries are permitted, regardless of the method used. For example, when ACME's HTTP method does not corroborate, BR's example retries using the Email to DNS TXT Contact method. Retries must not rely on corroborations from earlier attempts: When retrying Multi-Perspective Issuance Corroboration, CAs MUST NOT rely on corroborations from previous attempts.

Regarding CAA checks, corroboration results may be reused for up to 398 days: A CA MAY reuse corroborating evidence for CAA record quorum compliance for a maximum of 398 days. This site's What CAA Can and Cannot Stop When DNS Control Is the Weak Link addresses the reuse of domain validation results.

4.5 Covered Methods

The BR states which methods use MPIC in the subsection of each method. This article counted the instances of the phrase MUST implement Multi-Perspective Issuance Corroboration as specified within Sections 3.2.2.4 and 3.2.2.5. This phrase appears in the following 14 methods.

Method	Name in the BR	Corroboration observes	End date in Section 1.2.2
3.2.2.4.7	DNS Change	The same challenge information (Random Value or Request Token)	None
3.2.2.4.13	Email to DNS CAA Contact	The same selected contact address	2028-03-15
3.2.2.4.14	Email to DNS TXT Contact	The same selected contact address	2028-03-15
3.2.2.4.16	Phone Contact with DNS TXT Record Phone Contact	The same selected contact address	2027-03-15
3.2.2.4.17	Phone Contact with DNS CAA Phone Contact	The same selected contact address	2027-03-15
3.2.2.4.18	Agreed-Upon Change to Website v2	The same challenge information (Random Value or Request Token)	None
3.2.2.4.19	Agreed-Upon Change to Website - ACME	The same challenge information (token)	None
3.2.2.4.20	TLS Using ALPN	The same challenge information (token)	None
3.2.2.4.21	DNS Labeled with Account ID - ACME	The same token	None
3.2.2.4.22	DNS TXT Record with Persistent Value	A Persistent DCV TXT Record with the same `accounturi` parameter	None
3.2.2.5.1	Agreed-Upon Change to Website	The same challenge information (Random Value or Request Token)	None
3.2.2.5.3	Reverse Address Lookup	The same FQDN	2027-03-15
3.2.2.5.6	ACME "http-01" method for IP Addresses	The same challenge information (token)	None
3.2.2.5.7	ACME "tls-alpn-01" method for IP Addresses	The same challenge information (token)	None

In Sections 3.2.2.4.18, 3.2.2.4.19, and 3.2.2.4.20, the MPIC sentence begins with Except for Onion Domain Names. Sections 3.2.2.4.13 and 3.2.2.4.14 SHOULD NOT be used starting March 15, 2026. Similarly, Sections 3.2.2.4.16 and 3.2.2.4.17 also SHOULD NOT be used from that date.

Of the methods that are not retired, the following five do not contain MPIC text in their respective sections:

Method	Name in the BR	End date in Section 1.2.2
3.2.2.4.4	Email to a Constructed Address	2028-03-15 (`SHOULD NOT be used` from 2026-03-15)
3.2.2.4.12	Validating Applicant as a Domain Contact	None
3.2.2.5.2	Email, Fax, SMS, or Postal Mail to IP Address Contact	2027-03-15 (`SHOULD NOT be used` from 2026-03-15)
3.2.2.5.5	Phone Contact with IP Address Contact	2027-03-15 (`SHOULD NOT be used` from 2026-03-15)
3.2.2.5.8	DNS TXT Record with Persistent Value in the Reverse Namespace	None

Section 3.2.2.5.8 is brief and delegates the format of the record to the definition in Section 3.2.2.4.22, which does contain MPIC text. However, Section 3.2.2.5.8 itself does not contain any MPIC text.

The methods that use email cannot be grouped together. Section 3.2.2.4.4 does not contain MPIC text, while Sections 3.2.2.4.13 and 3.2.2.4.14 do. In these two, what perspectives corroborate is the contact address selected from DNS, not the delivery of the email.

Among the HTTP methods, 3.2.2.4.18 places the file in the /.well-known/pki-validation directory. Section 3.2.2.4.19 refers to the HTTP challenge described in Section 8.3 of RFC 8555. RFC 8555, not the BR, defines the path /.well-known/acme-challenge/. Both methods say a 2xx HTTP status code must be received.

4.6 DNSSEC

The BR has required DNSSEC validation of DNS queries by the Primary Network Perspective since March 15, 2026. The email methods (3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14) have a partial exception in Section 4.2.2.2.3. For remote perspectives, Section 4.2.2.2.6 says MAY be performed.

DNSSEC validation is not required of remote perspectives. Details regarding the Primary conditions can be found on this site in TLS Certificate Ecosystem History and Timeline.

5. The CA Side: Let's Encrypt and Amazon Trust Services

This section examines publicly available statements from CAs about their perspectives. The numbers in the BR are minimums and do not reflect the actual number used by the CA.

5.1 The Let's Encrypt Announcement

Let's Encrypt staff announced the following on the community forum on October 15, 2026. The announcement was titled Let's Encrypt is adding two additional remote perspectives for domain validation.

The announcement details the number of domain validation requests as follows:

we will make seven total validation requests, one from the primary datacenter and six from remote perspectives (previously four)

.

Regarding dates, the announcement states that validation in the new regions will begin in staging on Tuesday, October 27th, 2026. The production rollout is planned for Tuesday, November 10th, 2026, subject to the condition Assuming all goes well. Both dates are after the check date.

The announcement gives the condition for validation to succeed as the primary server and a quorum of remote perspectives must receive the correct challenge response. No statement was found in the announcement on how many non-corroborations Let's Encrypt allows.

5.2 Let's Encrypt's Official Documentation

The documents on letsencrypt.org say the following about where validation comes from:

FAQ: We don't publish a list of IP addresses we use to validate, and these IP addresses may change at any time
Challenge Types, HTTP-01: Let's Encrypt sends requests potentially multiple times from multiple vantage points. The HTTP-01 challenge can only be done on port 80. It accepts redirects up to 10 levels, and only accepts redirects to ports 80 or 443, either using http: or https:.
Challenge Types, DNS-01: This involves setting a value in the TXT record for _acme-challenge.<YOUR_DOMAIN>. It supports issuing wildcard certificates.
Challenge Types, TLS-ALPN-01: This is performed over TLS on port 443.

5.3 The Community Wiki

The community forum includes a wiki page titled Multi-Perspective Validation & Geoblocking FAQ. The page was not originally written by Let's Encrypt staff. It was last edited on January 30, 2025. The number of perspectives listed on the page refers to a count prior to the announcement in Section 5.1. This article does not quote the page's numbers.

The wiki describes the traffic to leave open to obtain a certificate, stating Worldwide access to your public authoritative DNS server for all methods. For HTTP-01, it specifies Worldwide access to port 80 (unencrypted http) for requests to the /.well-known/acme-challenge/ path.

The wiki says about geographic blocking: we don't recommend geoblocking the requests that are used in order to validate your domain name. It suggests DNS-01 as an alternative for situations where the web server cannot be exposed externally. This recommendation comes from contributors to the wiki and does not represent official Let's Encrypt documentation.

5.4 ACM and Amazon Trust Services

The ACM User Guide describes the issuer of public certificates as

Public certificates requested through ACM come from Amazon Trust Services, an Amazon-managed public certificate authority (CA)

. For the remainder of this article, Amazon Trust Services will be referred to as ATS. The same user guide indicates that domain ownership can be verified through DNS validation, email validation, or HTTP validation. Regarding HTTP validation, the ACM page states HTTP validation is available only through the CloudFront Distribution Tenants feature. The redirect source that ACM gives is a file under http://example.com/.well-known/pki-validation/.

The ACM User Guide did not contain any descriptions of the number or location of perspectives. On October 21, 2026, this article searched the AWS documentation with three queries, incorporating the terms multi-perspective, Network Perspective, vantage point, and corroboration. The results were the ACM User Guide, the ACM FAQ, and a Knowledge Center page, none of which described the number or location of perspectives.

ATS's CP/CPS v2.7 (August 19, 2026) includes the following sentence in Section 3.2.2:

Validations are performed by Primary Network Perspectives and corroborated by at least the minimum quorum of Remote Network Perspectives defined in the CABF TLS BRs effective at the time of validation.

This sentence links the corroborating quorum of remote perspectives to the minimum defined in the CABF TLS BRs at the time of validation. The location of the perspectives used by ATS was not found in the CP/CPS.

The same section lists, by number, eleven validation methods that ATS uses. These include methods 3.2.2.4.7, 3.2.2.4.18, and 3.2.2.4.19. Neither the ACM User Guide nor the CP/CPS contained any descriptions indicating which of these numbered methods correspond to ACM's DNS validation and HTTP validation.

ACM's email validation has been announced to end by September 30, 2027. Details regarding this timeline can be found on this site under Moving AWS Certificate Manager Off Email Validation.

6. How Each AWS Setting Looks to a Perspective

This section examines how four different AWS settings behave as documented, interpreting this behavior from the perspective of a single requester. The findings presented here are inferences, as defined in Section 2.1.

6.1 CloudFront Geographic Restrictions

The CloudFront Developer Guide states the following regarding geographic restrictions:

Scope: Geographic restrictions apply to an entire distribution
Action when restricted: CloudFront returns an HTTP status code 403 (Forbidden) to the user
Location determination: CloudFront determines the location of your users by using a third-party database
Location unknown: If CloudFront can't determine a user's location, CloudFront serves the content that the user has requested

Geographic restrictions are not path-specific. If a perspective in a restricted country accesses /.well-known/acme-challenge/, CloudFront will return a 403 error. Section 3.2.2.4.19 requires a 2xx response, so that perspective's result does not count as a corroboration. This conclusion is an inference based on combining information from the documentation.

Whether or not issuance fails depends on the number of perspectives in restricted countries and the number of non-corroborations that the CA permits. Neither was found in the sources (Section 9). This article does not definitively state that issuance will fail.

CloudFront mentions using a third-party geolocation service to restrict access to only certain files within a distribution. For combining geolocation with other conditions, the AWS WAF Developer Guide says to use the AWS WAF geo match statement (Section 6.3).

6.2 The Exclusion for CloudFront Managed Certificates

The Geographic Restrictions page includes the following note:

Geographic restrictions do not apply to certificate validation requests for CloudFront managed certificates. When you use a CloudFront managed certificate, requests to the /.well-known/pki-validation/ path are excluded from geographic restriction rules.

The same note explains the reason:

This makes sure that Certificate Authorities can validate your certificate from the multiple geographically distributed network perspectives required for issuance and renewal, regardless of your geographic restriction configuration

.

The same note also provides a note regarding AWS WAF:

If you use AWS WAF with your distribution, make sure that your AWS WAF rules (including bot control rules) do not block requests to the /.well-known/pki-validation/ path

. The exclusion applies to geographic restrictions; it is the user's responsibility to verify AWS WAF rules.

The managed certificate page describes the same exclusion. This page names MPIC. It states:

Certificate Authorities verify domain ownership from multiple geographically distributed network perspectives (Multi Perspective Issuance Corroboration) to protect against BGP hijacking

. It continues:

If you previously removed geographic restrictions as a workaround for certificate validation failures, you can safely re-apply them

.

The exclusion applies under two conditions: when using a CloudFront managed certificate and when the request is directed to the /.well-known/pki-validation/ path. Managed certificates are a feature of CloudFront distribution tenants. CloudFront obtains certificates, validated via HTTP, from ACM on behalf of the user.

For managed certificate requests, the ValidationTokenHost setting chooses who serves the validation token.

cloudfront: CloudFront serves the HTTP validation token automatically. This is the choice when the domain has no existing traffic, or when its DNS can point to CloudFront right away.
self-hosted: The token is served from your existing infrastructure. This is the choice when moving a domain with existing traffic, and the certificate can be issued before DNS points to CloudFront. The token file is placed on the existing server, or a 301 redirect is configured to point to the ACM validation endpoint.

When using self-hosted, the validation request is delivered to the existing server, not CloudFront. If there is geographic blocking in front of that server, the CloudFront exclusion does not reach it. This is this article's inference. The managed certificate page does not describe the relationship between self-hosted and geographic restrictions.

6.3 AWS WAF Geo Match

The AWS WAF Developer Guide states the following regarding geo match rules:

Location Determination: AWS WAF determines the country and region based on the IP address of the request. By default, it uses the IP address from which the web request was sent. If you enable forwarded IP configuration, it uses the IP address from headers such as X-Forwarded-For.
Database: AWS WAF determines the location of requests using MaxMind GeoIP databases
Nesting: Nestable – You can nest this statement type

The same page also discusses its relationship with the CloudFront geographic restriction feature. It notes if you use the CloudFront geo restriction feature, be aware that the feature doesn't forward blocked requests to AWS WAF. It continues,

If you want to block requests based on the geography plus other criteria that you can specify in AWS WAF, use the AWS WAF geo match statement and don't use the CloudFront geo restriction feature

.

An AND statement matches when all of its nested statements match. A NOT statement inverts the result of its nested statement. An article in the AWS Knowledge Center states To allow or block access to specific URI paths by IP address, HTTP header, or geolocation, use a match rule statement. That page is a Knowledge Center article, not the AWS WAF Developer Guide.

An example in the same Knowledge Center article, in the section Block access to specific URI paths by geolocation, combines a URI path rule with a country rule, and selects Negate statement results for the country rule. This configuration blocks requests originating from countries outside the specified list, attempting to access that particular URI path.

If the negation is moved to the path statement, the rule will effectively ensure that only requests whose country matches and whose path does not start with /.well-known/acme-challenge/ are blocked, while allowing requests from all other countries. This configuration has the negation reversed compared to the example in the Knowledge Center and is not an exact match for the example provided. Whether a perspective's requests pass under that rule is an inference from statements in the sources. Section 8 describes a single configuration where the response from AWS was observed.

The country that geo match determines and the BR's definition of a perspective's location are separate criteria (Section 4.1). No statement was found on whether the country where a CA places its perspective matches the country AWS WAF determines.

6.4 Route 53 Geolocation, Geoproximity, and Latency Routing

The Route 53 Developer Guide states regarding default geolocation records: If you don't create a default record, Route 53 returns a "no answer" response for queries from those locations.

Geolocation records are created per combination of name and type. The CloudFormation reference states,

You can't create non-geolocation resource record sets that have the same values for the Name and Type elements as geolocation resource record sets

. The default record * matches, for the same name and type, the locations that no other geolocation record covers. Queries originating from IP addresses that cannot be associated with a specific location are also handled by the default record.

Therefore, geolocation routing does not apply to all records within a domain. For example, if you create a geolocation record for the TXT record _acme-challenge and do not create a default record, queries from locations not covered by that geolocation record will receive a "no answer" response. If the A record of the same name is a simple record, it answers regardless of location.

Route 53 determines the location of a query as described in the EDNS0 documentation. If the resolver does not support edns-client-subnet, Route 53 estimates the location based on the resolver's originating IP address. When the resolver does support it, Route 53 utilizes a portion of the user's IP address sent by the resolver.

The BR requires a perspective's resolver to fall in the same RIR service region as the perspective (Section 4.3). The location that Route 53 determines is based either on the resolver's IP address or the client subnet value. No statement on whether CA resolvers send edns-client-subnet was found in the materials reviewed. The search included BR, Let's Encrypt's FAQ and Challenge Types, two forum pages, the full text of ATS CP/CPS v2.7, and web searches.

Geoproximity routing is described as It sends traffic to the closest available resource. Latency-based routing, on the other hand, routes responses to resources in the AWS region with the lowest latency. Both methods can return different records based on location. If the value of a validation record differs by location, different perspectives may receive different values. Many BR methods require the same challenge information for corroboration (Section 4.5). Reading these two together is this article's inference.

Regarding CAA records, the Route 53 documentation states, You can't create a CAA record and a CNAME record that have the same name. This site's What CAA Can and Cannot Stop When DNS Control Is the Weak Link discusses the proper format for CAA values.

6.5 Origin Allow Lists

The CloudFront Developer Guide describes CloudFront's managed prefix list as follows:

The CloudFront managed prefix list contains the IP address ranges of all of the CloudFront globally distributed origin-facing servers

. The names of these prefix lists are com.amazonaws.global.cloudfront.origin-facing (IPv4) and com.amazonaws.global.ipv6.cloudfront.origin-facing (IPv6). Restricting incoming traffic with this prefix list is described as which prevents non-CloudFront traffic from reaching your origin.

When a domain name points to CloudFront, HTTP requests are routed through CloudFront to the origin. From the origin's side, the source is the CloudFront origin-facing server.

When a domain name points directly to the origin, HTTP requests do not pass through CloudFront. If the origin only allows traffic from the origin-facing prefix list, requests will not reach the origin. HTTP-01 challenges will not be corroborated in this scenario. This conclusion is an inference derived from combining information from various documentation sources.

The design for protecting your origin is discussed in detail in the Amazon CloudFront Origin Architecture Guide on this site.

6.6 CloudFront and AWS WAF Contract Tables

Surface	`Who Sets It`	`What It Requires`	`Status on the Check Date`	`What a Perspective Sees`
CloudFront geographic restriction (standard distribution)	AWS (CloudFront Developer Guide)	Applies to an entire distribution; returns 403 to blocked users	`In effect`	403 on every path, including `/.well-known/acme-challenge/`, if CloudFront places the perspective in a blocked country
CloudFront managed certificate, `ValidationTokenHost` of `cloudfront`	AWS (CloudFront Developer Guide)	Requests to `/.well-known/pki-validation/` are excluded from geographic restriction rules	`In effect`	The validation token from CloudFront, regardless of the blocked countries
CloudFront managed certificate, `ValidationTokenHost` of `self-hosted`	AWS (CloudFront Developer Guide)	You serve the token from existing infrastructure, or redirect to the ACM validation endpoint	`In effect`	Whatever your existing server returns
AWS WAF geo match	AWS (AWS WAF Developer Guide)	Country from the request IP address, using MaxMind GeoIP databases; nestable	`In effect`	The rule action for the country that AWS WAF assigns to the perspective's IP address

Surface	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
CloudFront geographic restriction (standard distribution)	The allowlist or blocklist of countries	Any exclusion for `/.well-known/acme-challenge/` (geographic restriction page, managed certificate page)	Whether blocked countries are acceptable for external ACME HTTP-01
CloudFront managed certificate, `ValidationTokenHost` of `cloudfront`	CloudFront excludes the validation requests from geographic restriction	None	Keeping AWS WAF rules, including bot control rules, from blocking `/.well-known/pki-validation/`
CloudFront managed certificate, `ValidationTokenHost` of `self-hosted`	The token file, or the ACM validation endpoint to redirect to, from CloudFront	How geographic blocking on your existing infrastructure interacts (managed certificate page)	Any geographic blocking in front of your existing server
AWS WAF geo match	AND and NOT statements; a Knowledge Center example of geolocation with URI paths	Whether the country AWS WAF assigns matches the location the CA assigns to its perspective (AWS WAF geo match page, BR)	Writing and testing any path exclusion for validation requests

6.7 Route 53, Origin Allow List, and ACM Contract Tables

Surface	`Who Sets It`	`What It Requires`	`Status on the Check Date`	`What a Perspective Sees`
Route 53 geolocation records on validation names	AWS (Route 53 Developer Guide, CloudFormation Template Reference)	Without a default record, "no answer" for unmatched locations; records per Name and Type	`In effect`	No answer for that Name and Type, if the location Route 53 assigns matches no record
Route 53 geoproximity and latency records on validation names	AWS (Route 53 Developer Guide)	The closest available resource, or the Region with the lowest latency	`In effect`	Possibly a different record value from another perspective
Origin allow list with the CloudFront origin-facing prefix list	AWS (CloudFront Developer Guide)	Only CloudFront origin-facing servers reach the origin	`In effect`	No response from the origin, if the name points straight to the origin
ACM HTTP validation	AWS (ACM User Guide)	Available only through CloudFront distribution tenants; redirect from `/.well-known/pki-validation/`	`In effect`	The token or redirect at `/.well-known/pki-validation/`, from CloudFront or from your existing server

Surface	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
Route 53 geolocation records on validation names	The default (`*`) record; EDNS0 `edns-client-subnet` support	Whether CA resolvers send `edns-client-subnet` (Route 53 EDNS0 page, BR)	Whether validation names carry a routing policy, and a default record if they do
Route 53 geoproximity and latency records on validation names	The routing policy per record	Whether CA resolvers send `edns-client-subnet` (Route 53 EDNS0 page, BR)	Keeping one value per validation name
Origin allow list with the CloudFront origin-facing prefix list	The managed prefix list, kept up to date by CloudFront	None	Where the name points during validation
ACM HTTP validation	CloudFront serves or redirects the validation path	Which BR method number ACM's DNS and HTTP validation use (ACM User Guide, ATS CP/CPS v2.7)	Keeping the redirect reachable from every location

7. The Paths AWS Has Exempted, and What Stays With You

This section divides the information from Section 6 into two parts: what AWS has already implemented, and what stays with users as configured. This section will not recommend a specific choice.

Which Validation Paths AWS Already Exempts

Among the settings this article read, AWS has already exempted one path: CloudFront excludes requests to the /.well-known/pki-validation/ path of managed certificates from geographic restrictions. The CloudFront documentation states No action is required to use this functionality.

What stays with the site operator, as configured, is the following:

AWS WAF rules for the managed certificate path: The note regarding geographic restrictions requests that users configure their AWS WAF rules to ensure that /.well-known/pki-validation/ is not blocked.
The managed certificate's self-hosted: Your existing infrastructure serves the token. Blocking in front of it is outside CloudFront's exclusion (inference).
External ACME clients using HTTP-01: An exclusion for /.well-known/acme-challenge/ was not found in the CloudFront documentation. CloudFront geographic restrictions apply to an entire distribution.
AWS WAF geo match: Any rule that excludes a path is yours to write and test. In the configuration described in Section 8, only requests to /.well-known/acme-challenge/ were permitted.
Route 53 routing policies on validation names: Geolocation records without a default record return a "no answer" response for locations they do not cover.
Origin allow lists: Whether a perspective's request arrives depends on where the name points during validation (inference).
Validation method selection: The wiki suggests using DNS-01 as an alternative. DNS-01 also touches the Route 53 records of the validation name.

8. What This Configuration Returned: A Record of AWS-Side Behavior

This section documents the responses received within a single AWS account, specifically from Route 53, CloudFront, and AWS WAF. The focus is on the responses originating from AWS itself, and not on the responses received by a CA's Network Perspectives. The determination of the requesting user's country, made by CloudFront and AWS WAF, was based on the IP address of the user's connection and was not related to the location of a CA's perspective. No certificate was requested from a CA.

8.1 The Configuration

Region: us-east-1
Execution Date: October 21, 2026 (UTC)
AWS CLI: aws-cli/2.37.12
Route 53: Created a non-delegated public hosted zone. For the _acme-challenge TXT, only the geolocation record for country JP was added. For www, a simple A record and the geolocation TXT record for country JP were added. Later, a default record (*) was added to the _acme-challenge TXT.
Route 53 Queries: TestDNSAnswer was invoked in three ways: without a client subnet, using the operator's IP address range (/24), and using the address 192.0.2.44 from the documentation range. The resolver IP address was not specified, so all three used the IP address of a resolver in us-east-1. Additionally, a direct query was performed using dig from the operator's network to one of the zone's name servers.
CloudFront: Standard distribution was configured with an S3 bucket as the origin, using the default *.cloudfront.net domain. A managed certificate was not used. Initially, geographic restrictions were applied, blocking requests from country JP.
AWS WAF: Subsequently, the geographic restrictions were removed, and a Web ACL was added. The rule blocks requests originating from country JP that do not have a URI path starting with /.well-known/acme-challenge/. The default action is to allow the request.
CloudFront requests: Three files were requested over http and https from a line in Japan: one under /.well-known/acme-challenge/, one under /.well-known/pki-validation/, and /index.html.
Cleanup: After the tests, all created resources were deleted, and it was verified that no resources remained.

The Route 53 Developer Guide, in the page Checking DNS responses from Route 53, states

The tool doesn't submit queries to the Domain Name System, it only responds based on the settings in the records in the hosted zone

. The results from TestDNSAnswer are therefore responses returned by Route 53 based on the hosted zone's configuration, rather than responses received over the internet.

8.2 Route 53 Results

Case	Query	`ResponseCode`	Answer
Before the default record, no client subnet	TXT `_acme-challenge`	`NOERROR`	None
Before the default record, client subnet of the operator's IP /24	TXT `_acme-challenge`	`NOERROR`	The `JP` record
Before the default record, client subnet `192.0.2.44`	TXT `_acme-challenge`	`NOERROR`	None
Before the default record, no client subnet	A `www`	`NOERROR`	The simple record
Before the default record, no client subnet	TXT `www`	`NOERROR`	None
Before the default record, client subnet of the operator's IP /24	TXT `www`	`NOERROR`	The `JP` record
After the default record, no client subnet	TXT `_acme-challenge`	`NOERROR`	The default record
After the default record, client subnet of the operator's IP /24	TXT `_acme-challenge`	`NOERROR`	The `JP` record
After the default record, client subnet `192.0.2.44`	TXT `_acme-challenge`	`NOERROR`	The default record

A direct dig query to the zone's name server returned results even though the zone was not delegated. Before adding the default record, queries sent from the operator's network without a client subnet and with a /24 of the operator's IP address both returned a single TXT record with a NOERROR response.

8.3 CloudFront and AWS WAF Results

Setting	Path	http	https	Response page
CloudFront geographic restriction blocking `JP`	`/.well-known/acme-challenge/` file	403	403	CloudFront geographic restriction
CloudFront geographic restriction blocking `JP`	`/.well-known/pki-validation/` file	403	403	CloudFront geographic restriction
CloudFront geographic restriction blocking `JP`	`/index.html`	403	403	CloudFront geographic restriction
AWS WAF web ACL, no geographic restriction	`/.well-known/acme-challenge/` file	200	200	The object
AWS WAF web ACL, no geographic restriction	`/.well-known/pki-validation/` file	403	403	Request blocked
AWS WAF web ACL, no geographic restriction	`/index.html`	403	403	Request blocked

The Response page column classifies each response by the wording of its body. The bodies themselves were not saved.

8.4 What This Configuration Showed

Geolocation records without a default record: When there was no client subnet and when using 192.0.2.44, the response was empty and returned NOERROR. After the default record was added, both returned the default value. This does not contradict the "no answer" statement in Section 6.4.
Name and Type Combinations: Using the same name (www), a simple A record was returned even without a client subnet, while the geolocation TXT record was not returned.
Geographic Restrictions for a Distribution Without a Managed Certificate: Files under /.well-known/pki-validation/ also returned a 403 error. The exclusion on the CloudFront page applies when using a managed certificate. This configuration does not use a managed certificate, so it did not test the behavior of the exclusion.
AWS WAF Path Exclusions: Of the requests from the country that the rule matched, only those under /.well-known/acme-challenge/ returned a 200 status. The rule that Section 6.3 treated as an inference worked as written in this configuration.

These findings do not indicate that requests from a CA's perspectives receive the same response. This configuration does not show which country a CA's perspective is placed in, or whether a CA's resolver sends a client subnet (Section 9).

9. What Cannot Be Confirmed

Based on the materials reviewed for this article, the following cannot be confirmed:

Location of Perspectives: Let's Encrypt does not publicly disclose the list of IP addresses used for validation (Section 5.2). No perspective locations were found in the ATS CP/CPS either (Section 5.4). Users cannot determine, based on the available documentation, which countries the perspectives used in a particular validation originated from.
Number of Non-Corroborations Allowed by the CA: The BR table indicates that CAs can allow up to two non-corroborations when six or more remote perspectives are used. Let's Encrypt's announcement does not specify the number of non-corroborations it allows (Section 5.1).
Consistency of Country Determination: In the BR, a perspective's location is the point where its traffic is handed off to the internet. CloudFront uses a third-party database, while AWS WAF uses MaxMind's database to determine the country. The documentation does not reveal whether the location where a CA places its perspectives aligns with the country determined by CloudFront or AWS WAF (Sections 4.1, 6.1, and 6.3).
The location Route 53 sees: No statement was found on whether a CA's resolver sends edns-client-subnet (Section 6.4).
ACM Method Numbers: No statement was found on which BR methods correspond to ACM's DNS and HTTP validation methods (Section 5.4).

So the reading that geographic restrictions make issuance fail is this article's inference. Issuance can be read as failing when the number of perspectives located in a restricted country exceeds the number allowed by the CA, or when the Primary Network Perspective itself is in a restricted country. However, neither is visible to the user.

10. Failure Modes

The following mistakes are easy to make when the tables in this article are misread.

Reading that geographic restrictions do not affect validation: CloudFront's exclusion is limited to the /.well-known/pki-validation/ path of managed certificates. No statement was found on an exclusion for the external ACME /.well-known/acme-challenge/ path (Section 6.2).
Reading that a managed certificate also exempts AWS WAF: The note regarding geographic restrictions requests users to avoid blocking /.well-known/pki-validation/ through AWS WAF rules (Section 6.2).
Reading that the CloudFront exclusion works with self-hosted: Your existing infrastructure serves the token (Section 6.2).
Asserting that geographic restrictions will always cause issuance to fail: The location of the perspectives and the number of non-corroborations permitted by the CA were not found in the sources (Section 9).
Combining CloudFront geographic restrictions with paths: Geographic restrictions apply to an entire distribution, and blocked requests are not passed to AWS WAF. To combine geography with other conditions, use AWS WAF's geo match (Sections 6.1 and 6.3).
Writing that Let's Encrypt validates from five remote perspectives: The announcement gives four remote perspectives before the change and six after it, for seven total validation requests including the primary datacenter. Five is the minimum in the BR phase of December 15, 2026 (Sections 4.2 and 5.1).
Writing that ACM uses five perspectives: The number was not found in ACM's user guide. ATS's CP/CPS links corroboration to the minimum quorum of the BR in effect at the time of validation (Section 5.4).
Reading MPIC as only about HTTP validation: It also applies to DNS methods, as well as DNS contact methods using email and phone, and CAA checks (Section 4.5).
Treating the email methods as one: Section 3.2.2.4.4 has no MPIC sentence; Sections 3.2.2.4.13 and 3.2.2.4.14 do (Section 4.5).
Reading that remote perspectives also validate DNSSEC: The BR writes DNSSEC validation by remote perspectives as MAY (Section 4.6).
Reading geolocation routing as applying to every record of a domain: Geolocation records are per combination of name and type (Section 6.4).
Writing that the phase effective as of December 15, 2026, is already in effect: As of the check date, it is marked as Scheduled. The phase that is actually in effect is the one effective as of June 15, 2026, which requires four or more remote perspectives (Section 4.2).

11. Frequently Asked Questions About Five Network Perspectives and Domain Validation

This section answers the assumptions listed in Section 1.1, pointing to the sections of the text.

Q1. Do CloudFront geographic restrictions affect certificate validation?

It depends on the path. Requests to the /.well-known/pki-validation/ directory using a CloudFront managed certificate are excluded from geographic restrictions. No such exclusion was found for external ACME clients accessing the /.well-known/acme-challenge/ directory. Geographic restrictions apply to an entire distribution, and requests from countries where delivery is blocked will receive a 403 error (Sections 6.1 and 6.2).

Q2. From how many places does Let's Encrypt validate?

Let's Encrypt's announcement (October 15, 2026) describes a total of seven validation requests: one from the primary datacenter and six from remote perspectives. Until the change, there are four remote perspectives. The staging environment validation is scheduled for October 27, 2026, and the production environment for November 10, 2026, if all goes well (Section 5.1).

Q3. How many perspectives validate an ACM public certificate?

The ACM User Guide did not contain any relevant information. The ATS CP/CPS v2.7 states that validations are corroborated by, at a minimum, the lowest quorum of remote perspectives defined by the BR in effect at the time of validation. However, the location of these perspectives could not be found in the CP/CPS (Section 5.4).

Q4. Does MPIC apply to email validation?

It depends on the method. MPIC text is included in methods 3.2.2.4.13 (Email to DNS CAA Contact) and 3.2.2.4.14 (Email to DNS TXT Contact). What the perspectives corroborate is the contact address selected from DNS. MPIC text is not included in method 3.2.2.4.4 (Email to a Constructed Address) (Section 4.5).

Q5. Does Route 53 geolocation routing hide validation records?

If a default record is not defined, Route 53 returns a "no answer" response to queries from locations that no record covers. Geolocation records are defined by name and type combinations. This applies when validation looks up records that have routing policies applied. The records that validation looks up include TXT, CNAME, and CAA records, as well as A and AAAA records that HTTP and TLS methods resolve (Section 6.4).

Q6. Do remote perspectives also validate DNSSEC?

BR specifies DNSSEC validation by remote perspectives as MAY. For the Primary Network Perspective, validation has been required since March 15, 2026. There are some exceptions for email-based methods (Section 4.6).

Q7. Has the five-perspective requirement started?

As of the check date, October 21, 2026, it has not started. BR v2.3.1 states that from December 15, 2026, the number of remote perspectives must be five or more. As of the check date, the phase in effect is the one beginning June 15, 2026, which states that the number of remote perspectives must be four or more (Section 4.2).

Q8. When was this article checked?

The source materials were reviewed on October 21, 2026. The BR version is v2.3.1. The dates in the Let's Encrypt announcement were in the future on the check date, and this article did not confirm whether they took place. The observations described in Section 8 were conducted on October 21, 2026 (UTC), using a single AWS account (Sections 1.4 and 8).

12. Summary

The phase with five perspectives for BR is scheduled for December 15, 2026: The phase in effect at the check date requires four or more remote perspectives. Starting March 15, 2026, it is also required that the corroborating perspectives fall within at least two RIR regions (Section 4).
MPIC applies to methods other than HTTP, as well as CAA: Fourteen methods, which include DNS, DNS contact information for email and phone, HTTP, and TLS, contain MPIC text. However, the email method in Section 3.2.2.4.4 does not contain MPIC text (Section 4.5).
The sources do not show where the perspectives are: Let's Encrypt does not publish its validation IP addresses, and announced that they are increasing the number of remote perspectives from four to six. The ATS CP/CPS links corroboration to the minimum quorum in the BR and states no locations (Section 5).
What AWS has exempted is the /.well-known/pki-validation/ path of managed certificates: The CloudFront page names MPIC as the reason. AWS WAF rules and self-hosted tokens stay with the site operator (Sections 6.2 and 7).
External ACME, AWS WAF, Route 53, and allow lists are visible to perspectives, with their configurations intact: Geographic restrictions apply to an entire distribution. Geolocation records, for each combination of name and type, return no answer to unmatched locations if a default record is not present (Section 6).
The sources read do not settle whether issuance will fail: This is due to the lack of visibility regarding the location of perspectives and the number of non-corroborations that the CA permits (Section 9).

13. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi