Certification Authority Authorization – CAA Records

A: YES! …and no. We support a TYPE257 record today. So by converting your CAA record to RFC 3597 syntax, you can implement “CAA” records right now. So the bottom line is YES!

Background on CAA

In February 2017 the CA/Browser Forum voted to mandate Certification Authority Authorization (CAA) support and to enforce use of this validation method starting in September 2017. CAA lets the owner of a domain name authorize designated and specific Certification Authorities (CAs) to issue SSL certificates for their domain name. Even though CAA was specified in RFC 6844 back in 2013 by the IETF, it never really took off until early 2017 when it was voted on, as is typical with so many proposed DNS changes, improvements, record types etc.

Because many DNS record types are proposed and then never adopted, we at Total Uptime simply keep an eye on things, and if they are adopted we proceed to implement them. Generally there is more than enough time to roll out new changes, but with CAA everything started rolling very quickly, and with good reason.

Issuing SSL Certificates is often considered the weakest link in the PKI ecosystem since any CA can issue a certificate for any domain. CAA attempts to prevent that, and as such, organizations wishing to purchase SSL certificates will need to have this record in place come September when Certificate Authorities are required to start looking for them.

As mentioned above, we don’t support the exact CAA record just yet, but we do support the TYPE257 record which will work precisely the same way. So if you want to implement something now so you’re ready for the deadline, you can!

How to create your CAA / TYPE257 record

The easiest way to create a new record is to use this incredibly handy CAA Record Generator by SSLMate. Their tool truly takes the complexity out of it, especially when you need to convert it to RFC 3597 syntax. Simply enter your domain name (optional), choose the certificates and the code will be generated below.

Here’s an example I generated for Comodo Non-Wildcard only:

You’ll see that two records are generated. Issue “comodoca.com” which allows Comodo to issue non-wildcard certs, and issuewild “;” which indicates that all other Cas are not authorized to issue certificates.

To implement this in our UI, create a new TYPE257 record and add the first one as follows:

You’ll notice that only a few pieces of data are required from the syntax generated by the SSLMate tool.

The Host is most likely the @ symbol, if your CA is going to look at the root or apex of your domain. If they are looking at a sub domain, such as “secure.example.com” then you may need to enter “secure here instead”

The bytes is taken from the generated syntax which is directly following the \#

The Value is the long hexadecimal string to the far right.

If you compare what we’ve entered in the screen capture above to what was generated by the SSLMate tool, you’ll figure it out pretty quickly. And for our example above, after clicking Submit to save the record, we would create another one.

That’s about all there is too it!

For advanced DNS administrators, the tool named-rrchecker from BIND 9.11 can be used to convert a CAA-record into the RFC 3597 format useable for older DNS server:

$ echo “IN CAA 128 issue ‘letsencrypt.org’” | named-rrchecker -u

Which returns:

CLASS1 TYPE257 \# 24 80056973737565276C657473656…

Testing the results

Confirming whether the record was added successfully is pretty easy. After waiting a couple of minutes for the change to propagate our network, you can simply perform a dig against the CAA or TYPE257 record. Here is an example:

Search our Knowledge Base

About Total Uptime Technologies

Total Uptime Technologies, LLC is a privately held provider of Cloud solutions designed to help organizations achieve high availability in a demanding online world. Our multi-datacenter, multi-country Cloud platform easily delivers on our uptime promise because it has been engineered from the ground up to be fast, flexible and resilient.

While other organizations were busy renaming their legacy solutions as “Cloud” and dressing them up to take advantage of the latest hype, Total Uptime Technologies was engineering a true Cloud Platform that was multi-datacenter at its core. In our mind, Cloud meant resilient, and resilient meant that we had to design an application that could span infrastructure at different datacenters in different geographies – continents apart. Only then would we be content with calling it “Cloud”.