CAA Records: Creation, Automation, and Lifecycle Management


When a domain owner needs their application to accept HTTP connections over TLS, they need an SSL/TLS certificate. Any Certificate Authority (CA) that is publicly accepted by the browser’s root certificate program can theoretically issue a valid SSL/TLS certificate after properly validating the domain and its owner. If you wish to whitelist only certain CAs, the Certificate Authority Authorization (CAA) process allows domain owners to select an exclusive list of CAs permitted to issue SSL/TLS certificates for their domains. When anyone requests certificates from CAs outside this permitted list, the request is immediately rejected by the CA and the respective domain owner is notified of the occurrence.

As of September 8th 2017, the CA/Browser forum has made it mandatory for CAs to check these CAA records within a DNS resource record when issuing SSL/TLS certificates. However, domain owners can still choose not to have a CAA record. In the absence of a CAA record, a CA is not restricted from issuing a valid certificate for that domain, which makes way for mis-issuances and rogue certificates.

Without a CAA record, domain owners can still make use of the Certificate Transparency (CT) program to identify mis-issued certificates for their domain. The Certificate Transparency program maintains a log of all SSL/TLS certificates ever issued, opening it up to the scrutiny of domain owners, certificate authorities and domain users. This was precisely how the Google Chrome team was able to identify the mis-issuance of over 30,000 certificates by Symantec, for which the CA responsible lost its place in the trusted Certificate Authority Program. But with certificate mis-issuances and rogue certificates on the rise, a CAA record proves to be immensely valuable to any enterprise by supplementing the CT program. Mostly because, it’s time-consuming to discover a breach of digital trust externally but extremely easy to just restrict certificate requests to trusted CAs and get notified immediately on unauthorized requests.

Apart from just preventing CAs from issuing certificates for unauthorized domains, a CAA record can also set and enforce policies for the entire domain or for specific hostnames, when needed. Your subdomains inherit these records by default, therefore a CAA record set on will also automatically apply to your (unless overridden by a separate CAA record for your subdomain). Thus, the CAA records for your subdomain will take precedence over your main domain. CAA records can also control the issuance of single-name and wildcard certificates (or both) with the help of different fields in their resource records.

Now, let’s look at how we can create a CAA record for your domain.

How to Create and Manage CAA Records?

A CAA record, as specified in RFC 6844 by the Internet Engineering Task Force (IETF), is made up of the
following elements:

HostName CAA ″ (″ – property)

Flag– This is an unsigned integer between 0 and 255. Currently, values “0” (non-critical) and “128” (critical) represent the issuer’s critical flag. When set to “128”, the CA must completely understand the property tag (given below) to proceed with certificate issuance or continue processing other CAA records. If the flag is set to “0” or “non-critical”, the CA can continue processing other CAA records regardless of whether a CA understands a record. The remaining flags are reserved for future use.

Property Tag – This is a property identifier. RFC 6844 defines the use of three tags – issue, issuewild and iodef. The issue tag helps the domain owner choose the CA permitted to issue certificates for their domain. For permitting multiple CAs, multiple CAA records with different issue tags must be created.

Eg. CAA 0 issue “” CAA 128 issue “”

Here “” and “” are the CAs that are authorized by the owner under “Value”.
The issuewild tag specifies that a CA is permitted to issue wildcard certificates for the owner’s domain.

Eg. CAA 0 issuewild “”

If you wish to forbid all CAs from issuing wildcard certificates for your domain, you can use the

Eg. CAA 128 issuewild “;”

The Iodef tag is used to report unauthorized certificate requests to the respective domain owners.

Eg. CAA 0 iodef “mailto:[email protected]

Therefore, when there are multiple CAA records for a domain, the CA processes each record hierarchically and will only stop processing in two scenarios:

1. The CA could successfully process the record and perform an action (issue or not issue)
2. When the “Flag” is set to “128” and a CA could not process that record (due to human error)

This is where the major challenge lies.


Gartner estimates that over 70% to 99% of data breaches today are caused by internal misconfigurations. This is largely due to the amount of manual work involved in setting up and managing certain systems, like a PKI infrastructure. Creating and managing a CAA record for your application is relatively easy when it comes to handling just a couple domains. But, when the number of public domains and sub-domains run into the thousands, creating and managing CAA records for all these domains becomes painful and cumbersome, especially when multiple DNS systems are involved. This becomes even more challenging when CAs start using additional “Flag” values. Any error in a CAA hierarchy or syntax with a critical flag set can cause important properties to be completely ignored or overridden. This then leads to authorized CAs ignoring valid certificate requests or even worse, certificate mis-issuances, ending in an extremely expensive mistake to first identify, then remediate.

So, how can one eliminate the risk of such an expensive human error?

Through automation.

CAA Automation with AppViewX CERT+

With minimal training, anyone can create and manage a CAA record through our intuitive, user-friendly, self-service forms, regardless of their level of knowledge on the syntax and various DNS systems. Our tight integrations with multiple DNS systems such as Infoblox, BIND, VitalQIP, etc., help abstract the underlying configuration requirement for each DNS and make it easily consumable for our end-users. Since CAA records are very critical for proper issuance of certificates, you can also choose to integrate your business processes (like a change management system) into the workflow seamlessly.

Additionally, the AppViewX platform helps users manage and automate the entire lifecycle of their internal and external PKI. Our Certificate Lifecycle Automation Solution provides extensive visibility into the certificate and encryption key infrastructure which helps protect your enterprise from threats to the business. Application, network and security engineers can self-service certificate requests and initiate automation workflows that deliver compliance and true business agility.

Certificate Discovery

Though a CAA can prevent certificate mis-issuances, there is still a strong chance that your infrastructure is already littered with unknown and unmanaged certificates due to poor control over the procurement process. The presence of these rogue certificates can often lead to unplanned application outages and can serve as easy targets for cybercriminals.

AppViewX CERT+ enables on-demand discovery of certificates from servers, clients, firewalls and ADC devices through a variety of modes, such as IPs, subnets, URLs and managed device (ADC) logins. The discovered certificates are then automatically converted into an inventory with the required information attached. You can schedule these discoveries at your convenience or choose a midnight sync option to keep your inventory updated each day. To minimize human access to critical private keys, you can choose between a FIPS-compliant, AES 256 encrypted key-store or an industry-standard HSM to store them. Properly documenting every certificate is the first step to preventing expensive certificate-related issues, and our auto-discovery helps you do just that.

Role-Based Access Control

Certificate issuance is just one step in a comprehensive certificate lifecycle management. And, a CAA’s scope ends post this step. Given certificates and their keys are critical to maintaining the sanctity of an enterprise’s digital trust, any access to them – whether it be human or device – must be regulated and audited post-issuance.

With AppViewX CERT+, you can define your own roles or inherit ones from your AD, LDAP, and RADIUS systems. These roles can then be assigned to your teams to delegate role-based access to your certificates and also granularly limit the operations that each role can perform on a particular certificate or device. All changes to a certificate and device are audited by the platform, and any critical event can be automatically reported back to the respective teams.

Internal Policy Enforcement

A CAA record predominantly focuses on external policy enforcement, i.e. restricting an unauthorized user from outside your enterprise from getting a valid certificate. And, in some circumstances, you may want that same level of control inside your enterprise. Technically, a CAA record can serve the same purpose for an internal audience, too. But, is that the most efficient route to take? Without the right CSR parameters, a lot of time is consumed in vetting a certificate request only for it to be rejected by the CA. With AppViewX CERT+, you can enforce policies internally to make sure that valid certificates are issued to you every single time. Similar to CAA, you can group your certificates based on domains and sub-domains and have separate policies governing their compliance. Apart from just restricting CAs and certificate types, these policies can also enforce cryptographic algorithms to ensure you have the right PKI for your business needs.

Certificate Compliance

Post CAA implementation, it is still not 100% guaranteed that your certificate infrastructure is free from non-compliant certificates. There are possibilities where a single mistake in a CAA record can introduce new, non-compliant certificates into the system, let alone the possibilities of older certificates. With AppViewX’s continuous compliance validation, every single certificate in the infrastructure is validated against internal policies that you set, in real-time. Our actionable dashboards evaluate the current state of your X.509 certificate infrastructure against authorized CAs, trusted end-points and others to help you take immediate action on non-compliant certificates, without leaving the screen. You can also send a compliance report to the necessary stakeholders periodically or choose to view these reports on your SIEM dashboards such as Splunk.


Certificate Authority Authorization (CAA) has merits since they solve an increasingly, pressing problem in the certificate industry currently – mis-issuance. And as with any new technology, there’s a learning curve to this. This is where things can go wrong. When done manually, a single mistake in syntax or hierarchy can quickly push the CA to ignore or override your critical CAA records to wrongly reject or mis-issue a certificate. To overcome these issues, it is highly recommended you invest in a certificate lifecycle automation solution that not only automates your CAA record creation in a user-friendly way but also takes care of other certificate-related issues proactively. For more information on our Certificate Lifecycle Automation solution, please visit


  • CAA
  • Certificate authority
  • Certificate Automation
  • Certificate Lifecycle Automation