CAA makes it mandatory to verify SSL issued

Certification Authourity Authourization
CAA – Certification Authority Authorization

As on September 8th 2017, it is now mandatory for the Certifying Authorities to verify the CAA record before issuing the SSL Certificate as directed by Certification Authority Authorization. The sole purpose is to tackle the menace of Fraudulent SSL Certificate generation. CAA standard has been defined in RFC6844

What is CAA?

Certification Authority Authorization(CAA) is an Industry Standard, which allows the Domain Owners to specify which Certifying Authorities (CA) is allowed to issue certificates for their domains. The intention of this is to allow the CAs to avoid mis-issuing of certificates and is an added checking/verification process in their Certificate Issuing Procedures.

Before any certificate is issued, the CA would verify the CAA record to check for its own existence in it and would block any request in case they are not listed.

How to use CAA?

The Domain owner has to publish Certification Authority Authorization(CAA) records the Domain’s DNS specifying the

  1. List of CAs authorized to issue SSL certificates for that domain.
  2. Policies for the entire domain or for specific hosts
  3. Single-Name Certificates, Wildcard Certificates or both can also be mentioned.

Why use CAA?

There have been numerous instances in the past wherein, Certifying Authorities were hacked and fraudulent certificates were issued. Furthermore, in our previous blog-posts too we had raised concerns about the lack of verification and decentralized structure of the CAs which allowed any CA to blatantly issue SSL Certificates on behalf of any domain. Due to this issue, it was of utmost importance to provide a control and verification method of the domain owners to provide and share information with the CAs so that CAs themselves are aware whether or not they are allowed to issue the certificate or not.

It is now the prerogative of the Domain Owners to provide CAA information in case they are using Certificate and it would be the responsibility of the CAs to validate each and every request.

List of DNS Servers Implementing CAA

Although, Certification Authority Authorization(CAA) is fairly new Standard hence, there are very few DNS Servers which provide support for the addition of CAA records.

BIND Yes Prior to version 9.9.6 use RFC 3597 syntax
Knot DNS ≥2.2.0
ldns ≥1.6.17
NSD Yes Prior to version 4.0.1 use RFC 3597 syntax
OpenDNSSEC Yes With ldns ≥1.6.17
PowerDNS ≥4.0.0 Versions 4.0.3 and below are buggy when DNSSEC is enabled.
Simple DNS Plus ≥6.0
tinydns Yes Use generic record syntax
Windows Server 2016 Yes Use RFC 3597 syntax

Domain Owners may check with their respective Domain Registration Service Providers whether they provide addition of CAA records in their DNS Configuration Panel.

In order to create CAA Record, domain owners may visit

How to Verify CAA?

The two of the most popular tools used for looking up DNS records are “dig” and “nslookup”, and both these tools use the “type257” as the query parameter for the CAA.

$ dig type257

;; ANSWER SECTION: 86399 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D 86399 IN TYPE257 \# 15 00056973737565706B692E676F6F67

c:\> nslookup
> set q=type257
Non-authoritative answer: rdata_257 = \# 19 0005697373756573796D616E7465632E636F6D rdata_257 = \# 15 00056973737565706B692E676F6F67

However, these tools are yet to implement CAA record lookup, hence with these tools, you may summarize that there exists a CAA record.

One may visit our domain tools section to lookup for CAA records


;; ANSWER SECTION:	86399	IN CAA 0 issue ""

A complicated CAA Record by

;; ANSWER SECTION:	3599	IN CAA 0 issue ""	3599	IN CAA 0 issuewild ";"	3599	IN CAA 0 iodef ""	3599	IN CAA 0 iodef ""

Threat Attack Scenarios

With the implementation of CAA the footprint of the attack surface reduces and shifts towards the addition of CAA records by the Domain Owners

  1. Non-Compliance of adding CAA Records in the DNS by Domain Owners
  2. Compromised DNS Panel of the Domain Owner

Fraudulent Digital Certificates – A different Perspective

Fake Google SSL Certificates – Courtesy NIC

This entry was posted in eScan 11, eScan 14, MailScan, Security and tagged , , , , , . Bookmark the permalink.