The ACME CAA extension becomes mandatory

Jun 26, 2026 | Petra Salašová

Starting in March 2027, all certificate authorities will be required to support the ACME CAA extension. What does this mean for TLS/SSL certificate issuance, and how does the extended CAA record work in practice?

How did making the CAA record extension mandatory happen?

Chrome has long been an advocate of automation, and its support is a central theme of the so-called Root Program, in which Google began requiring ACME CAA support from authorities in February 2026 - precisely to support ACME automation. Then in May 2026, the CA/Browser Forum in ballot SC-098v2 voted to extend support for the new CAA record among certificate authorities and as of March 2027, requires all authorities to fully support ACME CAA.

Why was there a need for the change?

The existing web PKI system is sufficient for regular use cases, i.e., for securing websites that do not face serious threats. However, major websites need to be better secured during the certificate issuance process. Although the web PKI ecosystem has been improved over decades and is based on sophisticated rules and checks, it fundamentally encounters two problems that simplify the entire process but come at the cost of reduced security requirements:

• Missing applicant authentication: Anyone in the world can apply for a certificate for any domain. If they pass the domain verification process, the authority will issue the certificate to the applicant without authorization from the domain owner.
• Vulnerable verification process: When applying for a certificate, certification authorities typically verify domain ownership via unsecured DNS or regular HTTP traffic. Anyone who can interfere with the verification process can disrupt and spoof the domain verification.

What does the ACME CAA record look like?

The aforementioned weaknesses of web PKI can be addressed using the Certification Authority Authorization (CAA) standard, which is designed to enable domain owners to publish their certificate issuance policies.

The basic version of the CAA standard has been mandatory since September 2017. However, this traditional CAA record in DNS only allows specifying which certificate authority (e.g., DigiCert) may issue a certificate for the given domain. The new mandatory ACME extension goes much further and allows adding very detailed conditions to the record. In practice, the new, extended record may look like this:

example.com. CAA 0 issue "digicert.org;
accounturi=https://acme-v02.api.
digicert.org/acme/acct/1726001367;
validationmethods=dns-01"

On the left is the domain name for which we want to have certificate issuance under control. On the right, we have three variables:

• The first is the name of the CA that is allowed to issue certificates for the given domain.
• The second variable is the "accounturi" instruction, which limits certificate issuance to the named ACME account only. Since ACME always uses encryption and strong cryptographic authentication, the "accounturi" part ensures that only authorized users can request certificates for this domain name. You can define the exact ID or URL of your ACME account with DigiCert. No one else - even if they control part of your network - can generate a certificate under your name because the authority will only accept requests from the encrypted and cryptographically verified account of the owner.
• The third instruction "validationmethods" restricts certificate issuance to using only one DNS-based validation method. Active DNSSEC (extension mandatory from March 2026) ensures that the entire verification process is conducted exclusively in a cryptographically secure manner.

The above record thus states: Only DigiCert may issue the certificate for ACME account no. 1726001367 and exclusively through DNS-based verification.

What does this innovation mean for you?

The new extension will have to be observed by all authorities on the market starting next year. After that, it will be up to you whether and when you configure this advanced security measure in DNS.

Source: