May 23, 2017 at 13:40Forum of Certification Authorities and Browser Developers Approves DNS CAA
- Transfer
Experts from Qualis, a cloud-based provider that provides a wide range of Internet security services, talk about an urgent topic recently approved as mandatory additional means of enhancing the validity of security certificates (SSL / TSL).
The CAA (Certification Authority Authorization), defined in RFC 6844 in 2013, was proposed to strengthen the PKI ecosystem (Public Key Infrastructure) with a new means of controlling which certification authority can issue a certificate for a given domain. .
Despite the fact that CAA was introduced more than 4 years ago, it is still little known today, and at the moment only 100 or maybe about 200 sites use it. However, significant changes are coming, because the forum of certification authorities and browser developers (CA / Browser forum) has approved CAA as mandatory - as part of a standard set of basic conditions for issuing a security certificate. The new rule will come into effect in September 2017.
The ability to issue a security certificate by any certification authority (CA) for any domain has been repeatedly indicated as the weakest point in the PKI ecosystem. Despite the fact that certification authorities should operate without violating certain general rules, there is still no technical means of monitoring what they are doing. From here a certain weak link arises in the system, and in the presence of hundreds of CA - such links, respectively, hundreds.
CAA creates a mechanism that allows domain owners to create at the level of DNS records white lists of centers to which they are allowed to issue certificates for their domain. To do this, a new DNS resource record, CAA (type 257), is introduced. The domain owner restricts the issuance of certificates by explicitly specifying the certificate authority address in this entry.
For example, like this:
And it's all. Before issuing a certificate for any domain, the CA checks its CAA DNS resource record and issues the certificate only if it finds its address there. In addition to the “issue” directive from the above example, there is also the “issuewild” directive, which restricts the issuance of extended wildcard certificates, and the “iodef” directive, which contains the URL that the CA can refer to if something goes wrong - in the sense certification policies or technical issues. (128 is the control byte with the high bit set, indicating that this directive is critical and should be executed unconditionally).
From a certain point of view, CAA performs almost the same function as HPKP (HTTP Public Key Pinning), but in a slightly different way. First, CAA prevents the issuance of a certificate, while HPKP performs client-side validation at runtime, identifying already issued certificates as valid or not valid.
Secondly, HPKP is for browsers, and CAA is for certification authorities. HPKP, which provides a list of keys, is a means of technical control, while the CAA exercises more administrative control. Yes, it is expected that if the CAA record is inconsistent, the certification authority stops issuing the certificate, but the certification authority may switch to manual mode and decide on the issue if the request is still considered genuine. And yes, this is again a difficulty - there are a lot of certification centers, and the main problem for them is to withstand certain “social” pressure factors and nevertheless follow certain formal rules in case of discrepancy between CAA records.
But to say that CAA is useless or intersects with HPKP is not worth it. There are certain advantages, in particular, compared to HPKP, CAA has fewer opportunities for abuse and violation of property rights in the online space.
HPKP, if malfunctioning, can completely ruin your web business, and CAA will only be slightly annoying if something goes wrong.
And besides, “attaching public keys to confirm ownership of a web resource” scares potential HPKP users with its complexity and cumbersomeness compared to the simplicity of a CAA DNS record.
You can check the availability of a CAA record using any online service that analyzes the composition of DNS records for public domains.
The CAA (Certification Authority Authorization), defined in RFC 6844 in 2013, was proposed to strengthen the PKI ecosystem (Public Key Infrastructure) with a new means of controlling which certification authority can issue a certificate for a given domain. .
Despite the fact that CAA was introduced more than 4 years ago, it is still little known today, and at the moment only 100 or maybe about 200 sites use it. However, significant changes are coming, because the forum of certification authorities and browser developers (CA / Browser forum) has approved CAA as mandatory - as part of a standard set of basic conditions for issuing a security certificate. The new rule will come into effect in September 2017.
The ability to issue a security certificate by any certification authority (CA) for any domain has been repeatedly indicated as the weakest point in the PKI ecosystem. Despite the fact that certification authorities should operate without violating certain general rules, there is still no technical means of monitoring what they are doing. From here a certain weak link arises in the system, and in the presence of hundreds of CA - such links, respectively, hundreds.
CAA creates a mechanism that allows domain owners to create at the level of DNS records white lists of centers to which they are allowed to issue certificates for their domain. To do this, a new DNS resource record, CAA (type 257), is introduced. The domain owner restricts the issuance of certificates by explicitly specifying the certificate authority address in this entry.
For example, like this:
example.org. CAA 128 issue "letsencrypt.org"
And it's all. Before issuing a certificate for any domain, the CA checks its CAA DNS resource record and issues the certificate only if it finds its address there. In addition to the “issue” directive from the above example, there is also the “issuewild” directive, which restricts the issuance of extended wildcard certificates, and the “iodef” directive, which contains the URL that the CA can refer to if something goes wrong - in the sense certification policies or technical issues. (128 is the control byte with the high bit set, indicating that this directive is critical and should be executed unconditionally).
From a certain point of view, CAA performs almost the same function as HPKP (HTTP Public Key Pinning), but in a slightly different way. First, CAA prevents the issuance of a certificate, while HPKP performs client-side validation at runtime, identifying already issued certificates as valid or not valid.
Secondly, HPKP is for browsers, and CAA is for certification authorities. HPKP, which provides a list of keys, is a means of technical control, while the CAA exercises more administrative control. Yes, it is expected that if the CAA record is inconsistent, the certification authority stops issuing the certificate, but the certification authority may switch to manual mode and decide on the issue if the request is still considered genuine. And yes, this is again a difficulty - there are a lot of certification centers, and the main problem for them is to withstand certain “social” pressure factors and nevertheless follow certain formal rules in case of discrepancy between CAA records.
But to say that CAA is useless or intersects with HPKP is not worth it. There are certain advantages, in particular, compared to HPKP, CAA has fewer opportunities for abuse and violation of property rights in the online space.
HPKP, if malfunctioning, can completely ruin your web business, and CAA will only be slightly annoying if something goes wrong.
And besides, “attaching public keys to confirm ownership of a web resource” scares potential HPKP users with its complexity and cumbersomeness compared to the simplicity of a CAA DNS record.
You can check the availability of a CAA record using any online service that analyzes the composition of DNS records for public domains.