What CAA Can and Cannot Stop When DNS Control Is the Weak Link - accounturi, validationmethods, Certificate Transparency, and What ACM Documents

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

Before issuing publicly trusted TLS certificates, Certificate Authorities (CAs) must verify that the applicant controls the domain. Many of these verification methods rely on DNS records or responses from the domain's web server. Therefore, anyone who can modify the authoritative DNS records for a domain can potentially pass domain validation as specified. Google reported in a blog post on October 6, 2026, that ccTLD registries were compromised, resulting in the modification of authoritative DNS records and the issuance of unauthorized HTTPS certificates. Google stated that it sees no reason to believe that the CAs that issued the certificates acted inappropriately.

Domain owners can use CAA records in DNS to specify which CAs are permitted to issue certificates for their domain. Using RFC 8657's accounturi and validationmethods, they can even specify which account at that CA can obtain a certificate and with which validation methods. However, the two take effect only at a CA that states it processes them. Publicly issued certificates are logged in Certificate Transparency (CT) logs, allowing users to monitor these logs and identify any unfamiliar certificates. However, what these mechanisms can and cannot prevent depends on what an attacker controls and at what point in time. Google itself notes that CAA records do not prevent issuance while the authoritative DNS is under an attacker's control, but that once control of the DNS is regained, it can serve as a defense, and that it can prevent some attacks targeting routing or HTTP.

This article presents tables that align the conditions domain owners can define with the means of finding certificates logged in public logs. Each row details who defines the condition, what it restricts, where it is defined, what is accepted if nothing is defined, and what it does not prevent, even when restricted. Furthermore, it correlates what AWS Certificate Manager (ACM) and Amazon Route 53 documentation state about each row, and what they do not address. Pricing and guidance on which CA to choose are not included. The information presented in this article was verified as of October 17, 2026.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. What CAA issue and issuewild Narrow
4. What accounturi and validationmethods Add
5. Three Things Called a Validation Method
6. Splitting by What the Attacker Controls and When
7. What the ACM and Route 53 Documents Say and Do Not Say
8. Finding Logged Certificates With Certificate Transparency
9. Failure Modes
10. Frequently Asked Questions About CAA and Certificate Transparency
11. Summary
12. References

1. Scope and Assumptions

This section first defines the intended audience, the scope of this article, the dates of verification, and the consulted materials. The conclusions are as follows:

CAA acts as a condition that must be verified before a CA can issue certificates. It is a necessary condition for issuance, but not a sufficient one. While an attacker controls the authoritative DNS, the CAA records themselves may also be modified.
The accounturi and validationmethods parameters can be expected to take effect only where the CA has stated that it processes them. RFC 8657 states that domains MUST NOT assume the restrictions are effective for a CA that has not explicitly indicated this.
ACM documentation mentions four CA domains for CAA and states that ACM currently ignores iodef. Regarding accounturi and validationmethods, no statement was found in the scope this article searched.

1.1 Intended Audience

This article is intended for the following audience:

Operations personnel who obtain certificates from ACM (using standard DNS validation or ACME endpoints) or other ACME Certificate Authorities, and who manage their own domain's DNS records, for example, using Route 53.
Security professionals who believe that publishing CAA records can prevent unauthorized certificate issuance, and that specifying the accounturi parameter can immediately enforce this control.

1.2 The Assumption Broken on October 6, 2026

The Google post describes the incident as follows. This article focuses solely on identifying which assumption was broken, without addressing the methods used or the organizations affected.

During these hijacks, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations. Due to the nature of the attacks, we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong.

In this article's reading, the assumption that was invalidated was the one that the DNS records verified by the Certificate Authority (CA) accurately reflected the domain owner's intentions. As for the CA's verification process itself, the quoted sentence states that Google has no reason to believe the CAs did anything wrong. The date associated with this incident is reflected in the entry for October 6, 2026, on this site's TLS Certificate Ecosystem History and Timeline. This article does not repeat that entry.

1.3 What This Article Covers and What It Does Not

This article covers the following four areas:

CAA's issue and issuewild: This includes the Properties defined in RFC 8659, as well as iodef and the critical flag (flags with a value of 128).
RFC 8657's accounturi and validationmethods: This covers their definitions, how they are handled when no values are specified, properties that cannot be met, the need for a CA to state that it processes them, and the requirements and effective dates outlined by the CA/Browser Forum's Baseline Requirements (BR).
ACM and Route 53 documentation: This concerns what they say about CAA and what this article searched for and did not find.
CT monitoring: This covers methods for locating certificates logged in CT, and what AWS notifications look at.

This article does not cover the following topics:

Timeline entries: This includes the publication dates of RFC 8659 and RFC 8657 (November 2019), the Ballot SC-098v2 (May 13, 2026), the BR requirements that take effect on March 15, 2027, and the periods for which domain validation records can be reused – information found in TLS Certificate Ecosystem History and Timeline.
Historical records of CT within ACM: This refers to the Certificate Transparency section in AWS History and Timeline regarding AWS Certificate Manager.
ACM's three issuance paths and ACME endpoints: Information found in How AWS Certificate Manager Issues Public Certificates.
ACM's migration of validation methods: Details found in Moving AWS Certificate Manager Off Email Validation.
DNSSEC design: Only the DNSSEC condition of RFC 8657 Section 5.6, in Section 6.5.
Specific attack methods, steps involved in hijacks, and the names of organizations affected.
Pricing, comparisons between CAs, and comparisons of third-party CT monitoring services.

1.4 The Date Checked and the Sources Read

The information presented in this article was verified on October 17, 2026. All descriptions of the system's state reflect its condition on that date. The materials reviewed are as follows:

Specifications: RFC 8659 (CAA), RFC 8657 (accounturi and validationmethods), BR version 2.3.1 (October 4, 2026), and the Ballot SC-098v2 page.
AWS: The "Set up" section of the ACM User Guide, specifically the CAA section; "Certification Authority Authorization (CAA) problems"; "AWS Certificate Manager concepts"; "ACME domain validation"; the page detailing Amazon EventBridge events; and the Document History (reviewed the PDF version dated September 28, 2026). Also reviewed the ACM API Reference, including DescribeAcmeAccount and CertificateOptions, and the ACM FAQ. Additionally reviewed the CAA article on the AWS re:Post Knowledge Center, the "Supported DNS record types" section (CAA) in the Route 53 Developer Guide, an AWS Security Blog article from 2018, and an AWS Public Sector Blog article from 2019.
CAs and Related Matters: The CAA page on Let's Encrypt (Last updated: October 4, 2026), Amazon Trust Services CP/CPS version 2.7, and the Google post from October 6, 2026.

This article did not publish CAA records and attempt issuance. All descriptions of CA behavior presented in this article are based on the reviewed materials.

2. How to Read the Tables

This section defines the columns and terms used in the tables presented in this article. The tables that describe issuance conditions use the same columns for who writes a condition, what it narrows, where it is written, what is accepted when nothing is written, and what it does not stop even when it is written.

2.1 Columns of the Condition Tables

The tables in Sections 3 and 4 use the following columns:

Column	What It Holds
`Narrowed By`	Who writes the condition
`Condition`	What the condition narrows
`Set In`	Where the condition is written
`If You Set Nothing`	What the receiver accepts when nothing is written
`What It Does Not Cover`	What the condition does not stop even when it is written
`What It Can Stop (Per the Source)`	What the sources say the condition can stop, in the sources' own strength

In this article, the receiver is the CA. Domain owners define the conditions, while the CA processes them. The What It Can Stop (Per the Source) column keeps the strength of the wording in the sources (such as can prevent some).

The first five of these columns are also used on this site in Which alg a JWT Library Accepts When You Do Not Say and NIST IR 8587 Mapped to AWS Controls.

2.2 Normative Language and the Intended Audience

The normative terms (MUST, MUST NOT, SHOULD, MAY) from RFCs and BRs are written in their original uppercase form. When this article quotes a normative term, it states in the same sentence whom the requirement is directed at. Three are easy to mix up in this article:

The MUST NOT in RFC 8657 §5.2 is directed at domains that write CAA records.
The MUST in RFC 8657 §3 on how a CA treats a Property, the MUST in §5.3, and the SHOULD in BR 4.2.2.1.2 and its MUST from March 15, 2027 are directed at CAs. The BR requirements are directed at CAs; they do not ask domain owners to publish CAA.
The recommendations in the Google post are directed at domain owners. They are not requirements in a specification.

2.3 When the Sources Do Not Say, and When Writing an Inference

When this article cannot find a statement, it says that no statement was found, with the sources searched and the date checked. It does not write that the feature does not exist. The wording used is no statement was found, or an equivalent sentence ending in was not found. When this article combines statements from the sources into its own reading, it says in the same sentence that this is its own reading.

3. What CAA `issue` and `issuewild` Narrow

This section describes what CAA's core Properties restrict and what they do not. RFC 8659 defines CAA as a condition that CAs must verify before issuing certificates.

3.1 CAA Is a Condition a CA Checks Before Issuance

RFC 8659, Section 1, describes the difference between CAA and TLSA as follows: CAA is a check performed by the CA before certificate issuance, while TLSA is a check performed by the party that receives the certificate after issuance.

The distinction between CAA and TLSA is that CAA records specify an authorization control to be performed by a CA before issuing a certificate and TLSA records specify a verification control to be performed by a Relying Party after the certificate is issued.

The same section clarifies that CAA is a necessary but not sufficient condition for issuance, and that Relying Parties, the parties that receive a certificate, MUST NOT use CAA records in certificate validation.

Conformance with a published CAA record is a necessary, but not sufficient, condition for the issuance of a certificate.

Relying Parties MUST NOT use CAA records as part of certificate validation.

The ACM "Set up" page also states that CAA records cannot substitute for the verification requirements imposed by the CA.

A CAA record isn't a substitute for the security requirements that are specified by your certificate authority, such as the requirement to validate that you're the owner of a domain.

In other words, even a CA named in a CAA record does not issue a certificate unless domain validation passes. Furthermore, the issue Property does not distinguish which account at the CA is making the request. RFC 8657, Section 3, states that a Property without an accounturi matches any account (Section 4.1). Therefore, CAA's issue restriction specifies which CAs are permitted to issue certificates.

3.2 Which CAA Records Are Used?

A CA searches for CAA records for each name in the certificate. RFC 8659, Section 3, states that the search climbs the DNS name tree until a record is found.

The search for a CAA RRset climbs the DNS name tree from the specified label up to, but not including, the DNS root "." until a CAA RRset is found.

The AWS re:Post Knowledge Center article on CAA records lists four points about ACM's CAA checks.

CAA record checking moves up the DNS name tree.
No CAA record means that any CA can issue certificates.
CAA record checking follows the CNAME record.
The "issue" tag can be used for both non-wildcard domains and wildcard domains, while "issuewild" tag affects only wildcard domains.

Therefore, if a CAA record is placed for example.com, that same record will be used for www.example.com unless a CAA record is specifically present for www.example.com. If the name is a CNAME, the CA will examine the CAA records associated with the name that the CNAME points to.

3.3 Record Format

The Route 53 Developer Guide explains that CAA records should be formatted with three settings, separated by spaces.

flags tag "value"

The Route 53 Developer Guide gives the following as three separate examples: the first line allows ca.example.net to issue, the second line allows it to issue wildcard certificates, and the third line, on its own, does not allow issuance by any CA.

0 issue "ca.example.net"
0 issuewild "ca.example.net"
0 issue ";"

Regarding the handling of issuewild, RFC 8659, §4.3, states that when requesting a wildcard name, if issuewild is present, issue is ignored.

If at least one issuewild Property is specified in the Relevant RRset for a Wildcard Domain Name, each issue Property MUST be ignored when processing a request for that Wildcard Domain Name.

The ACM "Set up" page states the same thing, but in the following way:

When there is an issuewild CAA record present that does not include an ACM CA value, then no wild cards can be issued by ACM. If there is no issuewild present, but there is an issue CAA record for ACM, then wild cards may be issued by ACM.

3.4 Table of `issue` and `issuewild`

Property	`Narrowed By`	`Condition`	`Set In`	`If You Set Nothing`	`What It Does Not Cover`	`What It Can Stop (Per the Source)`
`issue`	Domain owner	Which CA may issue for the name	`0 issue "ca.example.net"`	No CAA record: any CA can issue (re:Post Knowledge Center; RFC 8659 Section 3)	Issuance by the named CA to anyone who passes its domain validation; issuance while an attacker can rewrite the CAA record itself (RFC 8659 Section 5.4); certificates already issued	Issuance by CAs that process CAA and are not named (RFC 8659 Section 3)
`issuewild`	Domain owner	Which CA may issue wildcard certificates	`0 issuewild "ca.example.net"`	No `issuewild`: the `issue` records apply to wildcard requests (RFC 8659 Section 4.3; ACM Set up page)	Non-wildcard requests (`issuewild` is ignored for them); the same limits as `issue`	Wildcard issuance by CAs that process CAA and are not named in `issuewild` (RFC 8659 Section 4.3)
`issue ";"`	Domain owner	No CA may issue for the name, when it is the only `issue` Property	`0 issue ";"`	Not applicable	Certificates already issued; issuance while an attacker can rewrite the CAA record; a CA named in another `issue` Property for the same name (Route 53 Developer Guide Note)	Issuance by any CA that processes CAA, when it is the only `issue` Property (RFC 8659 Section 4.2)
`iodef`	Domain owner	Where a CA may send a report	`0 iodef "mailto:security@example.com"`	Not applicable; an RRset with only `iodef` does not restrict issuance (RFC 8659 Section 3)	Issuance itself; ACM currently ignores the `iodef` field (ACM Set up page)	Nothing; it is a reporting channel, not a restriction
Critical flag `128`	Domain owner	A CA must not issue if it does not recognize the property tag	`128 tbs "Unknown"` (RFC 8659 Section 4.5)	Flag `0`: an RRset with only unrecognized property tags does not restrict issuance (RFC 8659 Section 3)	Parameters inside a recognized property such as `issue` (no statement was found that extends the flag to parameters)	Issuance by CAs that do not implement the flagged property tag (RFC 8659 Section 4.5)

3.5 `iodef` and the Critical Flag

The iodef property specifies the destination for reports related to issuance requests or reports indicating that an issuance violates a domain's policy. RFC 8659, Section 3, states that a collection of only iodef records does not restrict issuance.

If the Relevant RRset for an FQDN or Wildcard Domain Name contains no Property Tags that restrict issuance (for instance, if it contains only iodef Property Tags or only Property Tags unrecognized by the CA), CAA does not restrict issuance.

BR, Section 4.2.2.1, requires CAs to process the iodef Property, but does not require them to take action based on its contents. The "Set up" page for ACM states that the iodef field is currently ignored.

Note that the iodef field is currently ignored.

In the flags field, the value 128 is the critical flag. RFC 8659, Section 4.5, and BR, Section 4.2.2.1, describe the critical flag as being associated with a property tag that the CA does not recognize. BR states:

CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set.

issue is a property tag recognized by the CA processing CAA. In the documents this article read – RFC 8659, RFC 8657, the BR, and the ACM and Route 53 documentation – no statement was found that the critical flag applies to the parameters of the issue value. RFC 8657, Section 5.2, states that the CA determines the meaning of the parameter (Section 4.4).

3.6 Delegated Subdomains, and Suppressed or Bogus CAA Records

CAA records are searched by traversing the DNS hierarchy upwards. Therefore, if the DNS for a subdomain has been delegated to another party, the CAA record of the parent domain alone is not an effective way to restrict issuance for that subdomain. RFC 8657, §5.7 states:

CAA records are therefore not an effective way of restricting or controlling issuance for subdomains of a domain, where control over those subdomains is delegated to another party (such as via DNS delegation or by providing limited access to manage subdomain DNS records).

Furthermore, RFC 8659, §5.4, indicates that a party that can suppress or insert bogus CAA records may be able to obtain certificates from unauthorized CAs.

Suppression of a CAA record or insertion of a bogus CAA record could enable an attacker to obtain a certificate from an Issuer that was not authorized to issue for an affected FQDN.

The same §5.4 advises CAs that, where possible, they SHOULD validate CAA records using DNSSEC. Anyone who can modify authoritative DNS records can also modify CAA records. Section 6 lays this out by what the attacker controls.

4. What `accounturi` and `validationmethods` Add

This section describes what the two parameters from RFC 8657 add to the issue and issuewild Properties. Both are added in the value of the CAA Property, following the CA domain name and separated by a semicolon (;).

4.1 Definitions of the Two Parameters

RFC 8657, Section 3, defines accounturi as a URI that identifies a specific CA's account. A Property with an accounturi authorizes issuance only if the CA recognizes the URI as identifying the account making the request. Section 3 states what happens when nothing is written and when the Property cannot be satisfied:

A Property without an "accounturi" parameter matches any account.  A Property with an invalid or unrecognized "accounturi" parameter is unsatisfiable.  A Property with multiple "accounturi" parameters is unsatisfiable.

The same Section 3 also states that a Property that combines a domain name belonging to one CA and an account belonging to another CA is unsatisfiable.

For example, a CAA "issue" Property that specifies a domain name belonging to CA A and an "accounturi" parameter identifying an account at CA B is unsatisfiable.

Section 3.1 states that an ACME (RFC 8555) account can be identified by a URI that points to the account object. CAs implementing both this specification and ACME MUST recognize this URI. Section 3 also states that the presence of an accounturi does not replace validating the domain name in the issue or issuewild Property in the manner of RFC 8659, and that CAs MUST still perform that validation.

RFC 8657, Section 4, defines validationmethods as a string of validation method labels separated by commas. A Property with a validationmethods value authorizes issuance only if the validation method used matches one of the labels specified. These labels can be either the labels from the IANA ACME Validation Methods registry, or CA-specific labels that begin with ca-.

How RFC 8657 Says a CA Reads accounturi and validationmethods

The diagram lists how RFC 8657, Sections 3, 4, and 5.2, treat these parameters. The left side shows the contents of the Property, while the right side shows how RFC 8657 treats it. A Property without an accounturi matches any account, and a Property with an invalid, unrecognized, or repeated accounturi, or one that names an account at another CA, is unsatisfiable. The two boxes at the bottom are the two sentences of Section 5.2; the upper box is a SHOULD directed at the CA, and the lower box is a MUST NOT directed at the domain. If the CA has not stated that it processes the parameters, the diagram does not treat the restriction in any row as effective.

4.2 Example Records

The Let's Encrypt CAA page provides examples of the two parameters, as follows. Both the CA domain name and the account number in these examples are values used on the Let's Encrypt page.

example.org CAA 0 issue "myca.org;validationmethods=dns-01"
example.org CAA 0 issuewild "myca.org"
example.org CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"

The same page explains that, in this example, MyCA can issue for example.org only with the DNS-01 validation method, MyCA can also issue wildcard certificates with any validation method, and OtherCA can only issue certificates for requests originating from account number 123456. This final condition is subject to the following limitation.

and only if OtherCA recognizes and knows how to correctly handle the accounturi restriction.

In this example, the flags value on the third line is 128. As mentioned in Section 3.5, the documentation reviewed for this article did not contain any statements indicating that the critical flag applies to CAA parameters.

RFC 8657, §5.9, notes that CAA records are publicly accessible, and therefore the accounturi value is also visible to third parties. This article does not use actual account URIs in its examples.

4.3 Table of `accounturi` and `validationmethods`

Parameter	`Narrowed By`	`Condition`	`Set In`	`If You Set Nothing`	`What It Does Not Cover`	`What It Can Stop (Per the Source)`
`accounturi`	Domain owner	Which account at the named CA may request issuance	`;accounturi=` followed by an account URI, after the CA domain name in `issue` or `issuewild`	The Property matches any account (RFC 8657 Section 3)	CAs that have not stated support (RFC 8657 Section 5.2); any other CA (RFC 8657 Section 5.1); an attacker who can use the authorized account; delegated subdomains (RFC 8657 Section 5.7); certificates already issued	According to Let's Encrypt, this can be used to ensure that someone who temporarily hijacks the domain but does not have the ACME account key cannot issue malicious certificates, at a CA that handles the parameter
`validationmethods`	Domain owner	Which validation methods the named CA may use	`;validationmethods=` followed by comma-separated labels, after the CA domain name in `issue` or `issuewild`	RFC 8657 Section 4 states that the presence of the parameter constrains the Property; it has no sentence for the absent case like the one for `accounturi`	The same limits as `accounturi`; an attacker who can pass one of the allowed methods	According to Let's Encrypt, it can be used to restrict validation to methods that you trust more

4.4 Do Not Assume It Is Effective Unless the CA States It

RFC 8657, §5.2, states that the parameters of issue and issuewild Properties form a namespace specific to each CA, and that each CA determines which parameters it recognizes. It then asks CAs, with SHOULD, to document which parameters they support, and forbids domains, with MUST NOT, from assuming that the restrictions are effective for a CA without such an indication.

CAs that implement this specification SHOULD make available documentation indicating as such, including explicit statements as to which parameters are supported.  Domains configuring CAA records for a CA MUST NOT assume that the restrictions implied by the "accounturi" and "validationmethods" parameters are effective in the absence of explicit indication as such from that CA.

RFC 8657, §5.1, specifies that these parameters narrow only the issuance by the CA whose name is specified. It does not add any restrictions on issuances from other CAs.

In particular, it provides no additional security above that provided by using the unextended CAA specification alone as concerns matters relating to any other CA.

RFC 8657, §5.3, requires CAs to ensure that regardless of the number of mechanisms they use to accept issuance requests under the same CA domain name (the name written in the issue or issuewild Property), they handle the parameters consistently. §5.8 notes that incorrect parameter configuration may result in the rejection of legitimate issuance requests.

4.5 BR Requirements and the Effective Date of March 15, 2027

Section 4.2.2.1.2 of BR version 2.3.1 requires CAs to process the two parameters. Currently, this is a SHOULD, and from March 15, 2027, it is a MUST.

When processing CAA records, CAs SHOULD process the accounturi and validationmethods parameters as specified in RFC 8657. Effective 2027-03-15, when processing CAA records, CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657.

The page for Ballot SC-098v2 states the effective date of this requirement as follows.

These requirements take effect on March 15, 2027.

This is a requirement for CAs. It does not require domain holders to publish CAA records. Furthermore, it does not indicate that individual CAs will begin processing on March 15, 2027. The date this article was checked is before this effective date.

From March 15, 2027, Section 4.2.2.1.2 of BR also adds the following requirements (the requirements regarding labels for validation methods are covered in Section 5).

CAs that do not identify the Subscriber account by an ACME account URL must specify the format for the accounturi they accept, as defined in Section 4.2 of the CP or CPS (MUST).
In ACME requests, CAs MAY allow the accounturi to point to an organization's primary account (Parent Account). BR explicitly states this as an exception to RFC 8657, Section 3. The conditions are that the CA must maintain an auditable mapping between the Subordinate ACME Account and the Parent Account, must verify that the Parent Account has authorized the Subordinate ACME Account, and must maintain records of this verification.

5. Three Things Called a Validation Method

This section divides the concepts referred to as "validation methods" into three categories. ACM's validation methods, the labels in the ACME registry, and the validation method subsections of the BR can be called by the same name, but they are different things.

What Is Called a Validation Method	Values	Where It Is Defined	Where It Appears
ACM `ValidationMethod`	`DNS`, `EMAIL`, `HTTP`	ACM API Reference and User Guide	The ACM certificate request
ACME validation method labels	`http-01`, `dns-01`, `tls-alpn-01` (the labels Let's Encrypt lists as recognized)	IANA ACME Validation Methods registry (RFC 8555)	The value of `validationmethods` in CAA
BR domain validation methods	BR Section 3.2.2.4 subsections; labels of the form `ca-tbr-7` from 2027-03-15	CA/Browser Forum Baseline Requirements Section 3.2.2.4 and Section 4.2.2.1.2	The CA's validation records and CP/CPS; the value of `validationmethods` in CAA

BR Section 4.2.2.1.2 mandates that, from March 15, 2027, CAs using validation methods not listed in the IANA registry must process labels derived from the BR section numbers.

If the CA supports domain validation methods that are not registered in the IANA ACME Validation Methods registry, the CA MUST interpret and process validationmethods labels formed by concatenating the string ‘ca-tbr-’ with the BR 3.2.2.4 subsection number, e.g. ‘ca-tbr-7’ represents the DNS method described in TLS BR 3.2.2.4.7.

The same section asks CAs, with SHOULD, to accept any of the labels as authorization for issuance when a single validation mechanism can be represented by multiple labels. An example from BR is the use of both http-01 and ca-tbr-19. BR states that the canonical form of a label is lowercase.

No statement was found, in the scope this article searched, on which ACME label such as dns-01, or which BR label, ACM's DNS validation method corresponds to. At ACM's ACME endpoints, domain validation is performed using pre-configured resources, and the ACME client does not initiate the validation challenge. The ACM User Guide states:

ACME clients do not perform live validation challenges.

No statement was found in the ACM documentation on which label within validationmethods corresponds to this pre-validation process (Section 7.3 lists the scope searched). ACM's ACME pathway is addressed in How AWS Certificate Manager Issues Public Certificates. The migration of ACM's validation methods is covered in Moving AWS Certificate Manager Off Email Validation.

6. Splitting by What the Attacker Controls and When

This section outlines when CAA, the two parameters, and CT monitoring are effective, and when they are not, based on what the attacker controls and at what point in time. The information is based on the Google post and RFC 8657.

6.1 Two Sentences in the Google Post

The Google post includes the following two sentences under the heading Publish restrictive CAA records (with ACME account bindings). The condition in the second sentence (restricting issuance by account and validation method) is quoted without being cut.

While CAA can not prevent certificate issuance during an active DNS hijack, it provides a critical safeguard after DNS control is restored, and can prevent some routing-based and HTTP attacks entirely. Because CAs are permitted to cache and reuse completed domain control validation (DCV) checks for subsequent issuance, restoring a restrictive CAA policy, especially one that restricts issuance to specific authorized accounts and validation methods, prevents an attacker from using cached validation state to mint new certificates after a hijack ends.

The first sentence describes three situations. During a DNS hijack, CAA does not prevent issuance. After control of the DNS is restored, it provides a safeguard. It can prevent some attacks targeting routing or HTTP. The second sentence explains the reason for the safeguard after control is restored. Certificate Authorities (CAs) are permitted to reuse completed domain validations for subsequent issuances. Therefore, restoring a restrictive CAA policy prevents attackers from obtaining new certificates through the reuse of validation data.

6.2 Table by Scenario

Attacker Controls	When	CAA `issue`	`accounturi` and `validationmethods`	CT Monitoring	Source
The authoritative DNS, including the CAA records	During the hijack	Does not prevent issuance	Do not prevent issuance	Can show a certificate after it is logged	Google post; RFC 8659 Section 5.4
A route or HTTP responses, but not the authoritative DNS	During the attack	Can prevent some of these attacks	No statement was found in the Google post on which parameter does this	Can show a certificate after it is logged	Google post
Cached domain validation at a CA, after the DNS is restored	After DNS control is restored	Per the Google post, a restrictive CAA policy prevents an attacker from using cached validation state; at a CA that `issue` still names, `issue` alone does not distinguish one account from another (Section 3.4)	The Google post says this holds `especially` when the policy restricts issuance to specific authorized accounts and validation methods	Can show a certificate after it is logged	Google post
The authorized ACME account key	Any time	Does not distinguish this account from other accounts at the named CA	`accounturi` authorizes issuance only for that account, and the CA `MUST` still validate the domain name in the Property (RFC 8657 Section 3); a CAA record does not replace the CA's domain validation (ACM Set up page)	Can show a certificate after it is logged	RFC 8657 Section 3; ACM Set up page
All validation traffic of the named CA, where DNSSEC is not used or the CA does not validate CAA with a trusted DNSSEC-validating resolver	Any time	Does not prevent issuance by the named CA	No additional security (RFC 8657 Section 5.6)	Can show a certificate after it is logged	RFC 8657 Section 5.6
A subdomain whose DNS is delegated to another party	Any time	Not an effective restriction for that subdomain	Not an effective restriction for that subdomain	Can show a certificate after it is logged	RFC 8657 Section 5.7

In every row, the CT monitoring column does not stop issuance. CT monitoring serves as a means to find certificates after they are logged, as described in Section 8.

What CAA and Certificate Transparency Cover Around a DNS Hijack

The diagram shows three points in time in the top row: before, during, and after a hijack. The middle row shows attacks targeting routing or HTTP, while the bottom row shows the issuance steps. This process, as described in ACM documentation, includes domain validation, the CAA check, submission to CT logs, issuance, and monitoring. The CAA check occurs before issuance, and CT monitoring takes place after the certificate is logged. The wording in the top and middle rows keeps the strength of the wording in the Google post.

6.3 The Let's Encrypt Sentence and the Google Sentence

Let's Encrypt's CAA page describes the accounturi as follows:

This can be used to ensure that someone who temporarily hijacks your domain, but doesn’t have access to your ACME Account key, can’t issue malicious certificates.

This statement appears to contradict Google's statement, which says that CAA does not prevent issuance during a hijack. However, in this article's reading, the two statements are based on different assumptions. In Google's scenario, the attacker modified the authoritative DNS records. Anyone who can modify authoritative DNS records can also modify CAA records (RFC 8659 §5.4 lists the potential for suppression or forgery of CAA records). Let's Encrypt's statement refers to the scenario where the CAA record reaches the CA as written by the owner, and the attacker does not possess the ACME account key. Furthermore, Let's Encrypt's statement concerns CAs that process the accounturi (the limitation in Section 4.2). This article does not consider the two statements to be contradictory.

6.4 After DNS Control Is Restored, and the Reuse of Domain Validation

As stated in Google's second sentence, once a domain validation has been completed, Certificate Authorities (CAs) can reuse it for subsequent certificate issuance. The stages of how long this reuse is permitted are covered in TLS Certificate Ecosystem History and Timeline. This article does not repeat those dates.

RFC 8657, Section 5.5, notes that a CA may establish authorization for an account well before issuance, and that the CAA policy may change in the meantime. It then asks CAs, with SHOULD, to reduce this risk.

Possible countermeasures include issuing authorizations with very limited validity periods, such as an hour, or revalidating the CAA policy for a domain at certificate issuance time.

BR 4.2.2.1 sets an upper limit on the time between when a CA processes CAA records and when it issues a certificate.

If the CA issues a certificate after processing a CAA record, it MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.

Therefore, even after the CAA records are restored to a restrictive policy, if the CA checked CAA before that, a certificate could still be issued in the time between that check and the limit specified in the BR. This is this article's reading of the BR requirement.

6.5 The DNSSEC Condition

RFC 8657, §5.6, states that for domains not using DNSSEC, or for Certificate Authorities (CAs) that do not verify CAA records using trusted DNSSEC resolvers, the two parameters do not provide additional protection against attackers who can insert themselves into all validation communications from the CA.

The use of the "accounturi" parameter or the "validationmethods" parameter does not confer additional security against an attacker capable of performing a man-in-the-middle attack against all validation attempts made by a given CA that is authorized by CAA where:

The same §5.6 also states that, even in these cases, the two parameters can still be effective as a means of managing issuance. The exception is where control over the DNS of subdomains is delegated.

On the other hand, the same §5.6 states that where a domain is signed using DNSSEC and the CA makes all DNS resolutions through a trusted DNSSEC-validating resolver, the domain can use this Property to protect itself from an attacker capable of a global man-in-the-middle attack. It then asks, with SHOULD, that a domain secured via DNSSEC do one of the following: use accounturi so that only accounts it controls are authorized, or use only validation methods that rely solely on information obtained via DNSSEC and restrict issuance to them with validationmethods. It requires, with MUST, that a CA supporting either parameter check CAA using a trusted DNSSEC-validating resolver.

The design of DNSSEC is not covered in this article. Amazon Route 53's DNSSEC is discussed in the Amazon Route 53 DNS Architecture Guide on this site.

7. What the ACM and Route 53 Documents Say and Do Not Say

This section details what ACM and Route 53 documentation address regarding CAA, and what this article sought but was unable to find. The verification date is October 17, 2026.

7.1 The CAA Section of the ACM Set Up Page

The CAA section on the "Set Up" page of the ACM User Guide states the following:

When ACM checks: After ACM validates the domain during the certificate request process, it checks for CAA records.
flags: Set to 0.
tag: Use issue or issuewild. The iodef tag is currently ignored.
value: Enclose the CA's domain name in quotes. The page says that if you do not have a CAA record that specifies one of the four Amazon CAs, ACM cannot issue a certificate to your domain or subdomain (the end of this section describes how this article reads that sentence). A semicolon (;) indicates that no CA is permitted to issue certificates.

Regarding when ACM checks, the page states:

After ACM validates your domain during the certificate request process, it checks for the presence of a CAA record to make sure it can issue a certificate for you. Configuring a CAA record is optional.

The domain names of the four CAs are as follows:

amazon.com
amazontrust.com
awstrust.com
amazonaws.com

The ACM FAQ states that if there are no CAA records, Amazon can issue certificates.

If a CAA record is not present, then Amazon can issue a certificate for your domain.

The description of value on the Set up page includes the following sentence:

However, if you do not have a CAA record that specifies one of the following four Amazon CAs, ACM cannot issue a certificate to your domain or subdomain:

Read literally, this sentence means that ACM cannot issue a certificate without a CAA record, which does not match Configuring a CAA record is optional. on the same page or the FAQ sentence above. This article reads it as a sentence about the case where a CAA record is published. This is this article's reading.

7.2 CAA Errors and ACM Renewal

The Certification Authority Authorization (CAA) problems section of the ACM User Guide, regarding issues that arise after domain validation, states the following:

If you receive this error after your ACM certificate request has been successfully validated, you must update your CAA records and request a certificate again.

The ACM page for ACME domain validation lists CAA_ERROR as one possible reason for failure.

A Certification Authority Authorization (CAA) DNS record prevents ACM from issuing for this domain. Ensure your CAA records allow Amazon to issue certificates.

The ACM page for Amazon EventBridge events describes the ACM Certificate Renewal Action Required event, noting the case where CAA records that a customer adds prevent ACM renewal.

For instance, if a customer adds CAA records that prevent ACM from renewing a certificate, ACM publishes this event when automatic renewal fails at 45 days before expiration for private certificates and 30 days before expiration for public certificates.

Strict CAA configurations can potentially block the renewal of your own ACM certificates. This event serves as a notification regarding your ACM certificate.

7.3 What Was Not Found in the ACM Documentation

The following three items were not found in the scope this article searched:

Terms accounturi, validationmethods, and RFC 8657: A full search of the ACM User Guide PDF (version dated September 28, 2026) yielded zero results. Searches of AWS documentation (the aws-knowledge MCP, three times with different terms) also failed to locate these terms in the ACM User Guide, ACM FAQs, AWS re:Post Knowledge Center, and What's New (including information on ACME support in July 2026 and AWS PrivateLink support in October 2026).
The relationship between ACME account URLs and the accounturi term: The ACM API's DescribeAcmeAccount operation returns the ACME account URL as the AccountUrl. No statement was found that says to write this URL in the CAA accounturi.
The correspondence between ACM validation methods and ACME labels: As described in Section 5.

This article does not state whether ACM processes these parameters or not. Instead, it states that no statement was found in the ACM documentation and notes that RFC 8657 §5.2 states that domains MUST NOT assume the restrictions are effective for a CA without explicit indication. The BR MUST from March 15, 2027 is a requirement directed at CAs, not a statement about ACM's implementation.

7.4 The Amazon Trust Services CP/CPS

Section 4.2.2.1 of BR requires CAs to list, in Section 4.2 of their CP or CPS, the Issuer Domain Names that they recognize in CAA issue and issuewild records as permitting them to issue. The version 2.7 (August 19, 2026) of Amazon Trust Services' CP/CPS includes such a list, listing more values than the four on the ACM page. This article does not list those values. The two lists differ in length, but this article does not state that either is incorrect.

7.5 The CAA Section of the Route 53 Developer Guide

The CAA records section in the "Supported DNS record types" section of the Route 53 Developer Guide states the following:

Records should be created with three components: flags tag "value". The value must always be enclosed in quotation marks.
Some Certificate Authorities (CAs) allow or require additional values in value. These additional values should be specified as name-value pairs, separated by semicolons (;).
CAA records and CNAME records cannot share the same name.
It is recommended to consult with the CA to determine the appropriate content for CAA records.

An example of an additional value is as follows:

0 issue "ca.example.net; account=123456"

In this example, account represents an example of a parameter that the CA may define. RFC 8659, Section 4.2, also provides examples of the account parameter that a CA may define. accounturi is a parameter defined in RFC 8657, and is distinct from account. The Route 53 page does not contain the term accounturi. The format on the Route 53 page shows only that name-value pairs can be listed with ;.

7.6 Table by Document

Document	What It Says About CAA	What Was Not Found
ACM User Guide, Set up, (Optional) Configure a CAA record	Four Amazon CA domain names; `flags` `0`; `iodef` is currently ignored; ACM checks CAA after it validates the domain; `issuewild` handling for ACM	`accounturi`, `validationmethods`, RFC 8657
ACM User Guide, CAA problems	The error after successful validation requires updating CAA and requesting again	Same as above
ACM User Guide, ACME domain validation	`CAA_ERROR` as a failure reason	Which `validationmethods` label the pre-configured validation corresponds to
ACM API Reference, `DescribeAcmeAccount`	`AccountUrl` (the URL of the ACME account)	Any instruction to put `AccountUrl` in `accounturi`
ACM User Guide, Amazon EventBridge events	`ACM Certificate Renewal Action Required` when CAA records prevent renewal	Events for certificates that are not in ACM in your AWS account
ACM FAQs	Without a CAA record, Amazon can issue	`accounturi`, `validationmethods`
Route 53 Developer Guide, CAA record type	`flags tag "value"`; name-value pairs separated by `;`; no CAA and CNAME at the same name	`accounturi`
Let's Encrypt, CAA (another CA, for comparison of format)	Recognized `validationmethods` labels; the form of its account URIs	Not applicable

8. Finding Logged Certificates With Certificate Transparency

This section describes methods for finding certificates that have been logged in Certificate Transparency. CAA specifies conditions that CAs must consider before issuing certificates, while Certificate Transparency (CT) is a public log where certificates are recorded. Monitoring CT logs is a way to find certificates that have been logged, without preventing their issuance.

8.1 Monitoring CT Logs

The ACM concepts page states that by monitoring CT logs, you can verify that only certificates you have approved have been issued.

You can monitor the logs to make sure that only certificates you have authorized have been issued for your domain. You can use a service such as Certificate Search to check the logs.

The Google post recommends that domain owners monitor all of their domains' CT logs.

Perform ongoing monitoring of Certificate Transparency for all of your domains: Because every trusted-by-default certificate relied upon by Chrome must be disclosed in public CT logs, monitoring CT logs provides a near real-time alert whenever a certificate is issued for your domains.

The same paragraph also recommends including parked domains and regional ccTLDs in the monitoring scope.

8.2 ACM Public Certificates Are Recorded in CT Logs

The ACM concepts page states that ACM's public certificates are automatically logged in CT logs and that this logging cannot be stopped due to browser policy requirements.

All public certificates issued by ACM are automatically recorded in certificate transparency logs. Per browser policy requirements, you cannot opt out of certificate transparency logging.

The same page also states that Amazon's CA submits the certificate to CT log servers before it issues the certificate.

Before the Amazon CA issues a publicly trusted SSL/TLS certificate for your domain, it submits the certificate to at least three certificate transparency log servers.

ACM's Document history includes an entry dated June 1, 2026, which notes the deprecation of CT logging opt-out. The heading is Certificate transparency logging opt-out deprecated, and the body reads Certificate transparency logging opt-out is no longer available. ACM's history of CT logging is available at AWS History and Timeline regarding AWS Certificate Manager.

8.3 What AWS Notifications Look At

The Amazon EventBridge events listed on the ACM certificate events page include five types of events: ACM Certificate Approaching Expiration, ACM Certificate Expired, ACM Certificate Available, ACM Certificate Renewal Action Required, and ACM Certificate Revoked. The page also lists events from AWS Health. The descriptions indicate that all of these events relate to certificates in ACM in your AWS account. Issuance, renewal, and import can trigger the ACM Certificate Available event. The page states that the ACM Certificate Expired and ACM Certificate Renewal Action Required events are not available for imported certificates. Events for certificates that are not in ACM in your AWS account – for example, a certificate that another CA issued to someone else – are not on the page.

An article on the AWS Public Sector Blog, published on January 29, 2019, describes a response to a U.S. DHS emergency directive in 2019. Under the heading Action Four: Monitor Certificate Transparency Logs, the article states:

Customers using AWS Certificate Manager (ACM) should configure a CloudWatch event for new ACM certificate requests.

The procedures outlined in the article focus on ACM API calls in your account (RequestCertificate, DeleteCertificate, ImportCertificate). Certificates that another CA issued to someone else do not appear in these calls. It is also important to note that this blog post was published in 2019 and does not represent current ACM documentation.

No statement was found of an AWS feature that subscribes to or searches Certificate Transparency logs, in the scope this article searched (which included the full ACM User Guide PDF, the ACM EventBridge events page, and two variations of searches within AWS documentation). In the current ACM User Guide, the sentence that mentions monitoring CT logs is the ACM concepts sentence quoted in Section 8.1. An article from the AWS Security Blog in 2018 also contains a statement that Certificate Transparency lets customers be more confident that an unauthorized certificate has not been issued. That blog post dates from a period when opting out of CT logging was possible.

Means	What It Shows	What It Does Not Show
Monitoring public CT logs (ACM concepts page; Google post)	Certificates logged for your domains, by any CA	It does not prevent issuance
ACM events in Amazon EventBridge	State changes of certificates in ACM in your AWS account (issued by ACM or imported), including renewal blocked by CAA; the Certificate Expired and Certificate Renewal Action Required events are not available for imported certificates	Certificates that are not in ACM in your AWS account, such as one another CA issued to someone else
2019 AWS Public Sector Blog procedure	ACM API calls in your account (`RequestCertificate`, `DeleteCertificate`, `ImportCertificate`)	Certificates that another CA issued to someone else; it is not current ACM documentation

9. Failure Modes

This section lists common errors that arise when interpreting CAA and CT, presenting them alongside the descriptions found in the reference materials this article consulted.

Reading that publishing CAA records prevents certificate issuance even while the authoritative DNS is hijacked: The Google post states that CAA records do not prevent issuance during a DNS hijack. However, anyone able to modify the authoritative DNS can also modify CAA records (Section 6.2).
Reading that CAA records are useless against hijacks: The same Google post indicates that CAA records can provide protection after regaining control of the DNS, and can prevent some attacks targeting routing or HTTP (Section 6.1).
Reading that writing accounturi takes effect at every CA right away: RFC 8657, Section 5.2, states that domains MUST NOT assume the restrictions are effective for a CA without explicit indication. The BR requires CAs, with MUST, to process the parameters starting March 15, 2027 (Sections 4.4 and 4.5).
Reading that setting flags to 128 stops CAs that do not recognize the parameters: RFC 8659 and the BR tie the critical flag to property tags that a CA does not recognize. No statement was found, in the sources this article read, that extends it to parameters (Section 3.5).
Reading that writing the ACM ACME account URL in accounturi makes ACM stop issuance to other accounts: No such statement was found in the ACM documentation (Section 7.3).
Reading that publishing CAA records on domains becomes mandatory from March 15, 2027: The BR requirement is for CAs to process the parameters (Section 4.5).
Reading that EventBridge detects unauthorized certificate issuance by other CAs: ACM's EventBridge events provide notifications about certificates in ACM in your AWS account (Section 8.3).
Writing the account URI of another CA in a Property that names an ACM CA domain: RFC 8657, Section 3, states that this Property is unsatisfiable (Section 4.1).
Overlooking the renewal of your own ACM certificates when tightening CAA: ACM emits an ACM Certificate Renewal Action Required event when CAA records prevent renewal (Section 7.2).
Reading the three validation methods as the same thing: ACM's ValidationMethod, ACME registry labels, and BR's validation method sections are distinct (Section 5).

10. Frequently Asked Questions About CAA and Certificate Transparency

This section compiles common questions related to the content of this article, with answers referencing specific sections of the text.

Q1. If CAA records are published, can certificates still be issued while the DNS is hijacked?

Yes, they can. The Google post states that CAA does not prevent certificate issuance during a DNS hijack. CAA provides a safeguard after control of the DNS is restored, and it can prevent some attacks that target routing or HTTP (Section 6). Even after control is restored, if a CA checked CAA before then, a certificate could still be issued until the time limit in the BR runs out (this article's reading; Section 6.4).

Q2. What happens if you do not write `accounturi`?

Section 3 of RFC 8657 states that Properties without an accounturi match any account. Therefore, any account at the CA named in issue can obtain a certificate as long as it passes domain validation (Section 4.1).

Q3. Does ACM handle `accounturi` and `validationmethods`?

This article does not state whether or not ACM processes these parameters. No statement was found in ACM's documentation. RFC 8657, §5.2, states that domains MUST NOT assume the restrictions are effective for a CA without explicit indication (Section 7.3).

Q4. What changes on March 15, 2027?

BR Section 4.2.2.1.2 will require CAs to process the two parameters using MUST rather than SHOULD. This requirement applies to the CA and not to domain holders. The date this article was checked is before this effective date (Section 4.5).

Q5. Is it possible to prevent ACM public certificates from being recorded in CT?

No, it is not. The page detailing ACM concepts states that ACM public certificates are automatically recorded in the CT logs, and there is no way to stop this recording. Document history lists the deprecation of the opt-out in an entry dated June 1, 2026 (see Section 8.2).

Q6. Can you determine, using AWS features, whether other Certificate Authorities have issued certificates for your domain?

In the scope this article searched, no statement was found of an AWS feature that subscribes to or searches the CT logs themselves. ACM's EventBridge events provide notifications about certificates in ACM in your AWS account. The ACM concepts page says that you can monitor CT logs, citing services like Certificate Search as an example (Section 8).

Q7. Can you write `accounturi` in Route 53?

The Route 53 Developer Guide states that you can define name-value pairs, separated by semicolons, in the value field. However, the term accounturi does not appear on that page. The CA that processes the record, not the DNS service where the record is written, determines whether this parameter takes effect (see Sections 7.5 and 4.4).

Q8. When was the information in this article verified?

The verification was conducted on October 17, 2026. The BR version was 2.3.1, the ACM User Guide PDF was version dated September 28, 2026, and the CP/CPS for Amazon Trust Services was version 2.7 (Section 1.4).

11. Summary

CAA is a condition a CA checks before issuance: It is a necessary condition for issuance, but not a sufficient one. Relying Parties, the parties that receive a certificate, MUST NOT use CAA in certificate validation (RFC 8659 Section 1; Section 3.1).
If nothing is written, the receiver accepts broadly: Without CAA records, any CA can issue a certificate. A Property without an accounturi matches any account (Sections 3.4, 4.1).
The effect depends on what the attacker controls and when: While the attacker controls the authoritative DNS, CAA does not prevent issuance. After control of the DNS is restored, and against some attacks targeting routing or HTTP, it can be effective (Section 6). Even after control is restored, if a CA checked CAA first, a certificate could still be issued until the time limit in the BR runs out (this article's reading; Section 6.4).
The parameters can be expected to work only with CAs that state they process them: RFC 8657, Section 5.2, states that domains MUST NOT assume they are effective with a CA without explicit indication. The BR requires CAs, with MUST, to process them starting March 15, 2027 (Sections 4.4, 4.5).
ACM documentation lists four CA domains and says that iodef is currently ignored: No statement on accounturi and validationmethods was found in the scope this article searched (Section 7.3). When CAA prevents ACM renewal, an EventBridge event is triggered (Section 7).
CT monitoring is a means of finding logged certificates: ACM public certificates are recorded in CT, and these records cannot be stopped. The ACM EventBridge events provide notifications about certificates in ACM in your AWS account (Section 8).

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi