213.115.30.162 (talk) No edit summary |
TheDragonFire (talk | contribs) Major rewrite. Tag: 2017 wikitext editor |
||
| Line 1: | Line 1: | ||
{{Use American English|date=January 2018}} |
|||
'''DNS Certification Authority Authorization''' ('''CAA''') uses the [[Internet]]'s [[Domain Name System]] (DNS) to allow the holder of a domain to specify which [[certificate authorities]] (CAs) are allowed to issue certificates for that domain. This is not intended to support additional cross-checking at the client end of [[Transport Layer Security]] (TLS) connections (rather, [[DNS-based Authentication of Named Entities]] – DANE – is intended to be used for that purpose), but as a check for CAs to carry out as part of their issuance procedures. CAA records are intended to allow CAs to avoid mis-issuing certificates in some circumstances, while DANE records are intended to allow relying applications (TLS clients) to avoid relying on mis-issued certificates in some circumstances.<ref name=rfc6844>{{cite web|url=https://tools.ietf.org/html/rfc6844|title=RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record|publisher=Internet Engineering Task Force|author=P. Hallam-Baker and R. Stradling|date=January 2013}}</ref> |
|||
{{Use mdy dates|date=January 2018}} |
|||
'''DNS Certification Authority Authorization''' ('''CAA''') is an [[Internet security]] mechanism which uses [[resource record]]s in the [[Domain Name System]] (DNS) to allow [[domain name]] holders to specify which [[certificate authorities]] are authorized to issue [[Public key certificate|certificates]] for that domain, and which types of certificates they are able to issue.<ref name="rfc6844">{{Cite IETF|title=DNS Certification Authority Authorization (CAA) Resource Record|rfc=6844|last1=Hallam-Baker|first1=Phillip|authorlink1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|date=January 2013|publisher=[[Internet Engineering Task Force|IETF]]|doi=10.17487/RFC6844|issn=2070-1721}}</ref> In September 2017, the [[CA/Browser Forum]] will made it mandatory for publicly trusted [[certificate authorities]] to check a domain's CAA records before issuing a certificate.<ref name="cab2017">{{Cite web|url=https://cabforum.org/pipermail/public/2017-March/009988.html|title=Results on Ballot 187 - Make CAA Checking Mandatory|last=Hall|first=Kirk|date=March 8, 2017|publisher=[[CA/Browser Forum]]|access-date=January 7, 2018}}</ref> CAA is specified by {{IETF RFC|6844}} which defines a new "CAA" [[Domain Name System|DNS]] [[resource record]] type containing [[name-value pair]]s of the [[certificate authorities]] and whether they are able to issue [[wildcard certificate]]s or only specific-[[subdomain]] certificates.<ref name="rfc6844" /> Unlike [[DNS-based Authentication of Named Entities]] (DANE), it is a purely administrative control, and does not prevent a malicious [[certificate authority]] from issuing fraudulent certificates. Third parties monitoring [[certificate authority]] behaviour might check newly issued certificates against the domain's CAA records, but must be aware that a domain's CAA records may have changed between the time the certificate was issued and the time the third-party makes checks them. |
|||
== Record structure == |
|||
DNS Certification Authority Authorization is specified by RFC 6844. It defines a new "CAA" DNS resource record type for name-value pairs that can carry a wide range of information to be used as part of the CA authorization process. It may also be possible for certificate evaluators to use CAA records to detect possible mis-issued certificates. However, the certificate evaluator should consider that the CAA records may have changed between the time the certificate was issued and the time the certificate is observed by the evaluator.<ref name=rfc6844 /> |
|||
== Structure of CAA resource record == |
|||
Each CAA resource record contains a flags byte and a property. The flags byte contains flags which can influence the interpretation of the record. The property consists of a "tag" which allows selection between several kinds of CAA record, and a "value" string whose meaning depends on the choice of tag. |
Each CAA resource record contains a flags byte and a property. The flags byte contains flags which can influence the interpretation of the record. The property consists of a "tag" which allows selection between several kinds of CAA record, and a "value" string whose meaning depends on the choice of tag. |
||
| Line 15: | Line 15: | ||
; iodef : This property specifies a method for CAs to report to the domain holder when a certificate is issued. Not all CAs support this tag, so there is no guarantee that all certificate issuances will be reported. |
; iodef : This property specifies a method for CAs to report to the domain holder when a certificate is issued. Not all CAs support this tag, so there is no guarantee that all certificate issuances will be reported. |
||
== |
== Support == |
||
{{As of| |
{{As of|2018}}, CAA records are supported by [[BIND]] (since version 9.10.1B),<ref>{{Cite web|url=https://www.isc.org/blogs/certificate-authority-authorization-records/|title=Certificate Authority Authorization Records|last=Risk|first=Vicky|website=[[Internet Systems Consortium]]|date=August 29, 2014|language=en|access-date=January 7, 2018}}</ref> [[Knot DNS]] (since version 2.2.0),<ref name="sslmate">{{Cite web|url=https://sslmate.com/caa/support|title=Who Supports CAA Records?|website=SSLMate|language=en|access-date=January 7, 2018}}</ref><ref>{{Cite web|url=https://lists.nic.cz/pipermail/knot-dns-users/2016-April/000853.html|title=Knot DNS 2.2.0 release|last=Včelak|first=Jan|date=April 26, 2016|access-date=January 7, 2018}}</ref> ldns (since version 1.6.17),<ref name="sslmate" /> [[NSD]] (as of version 4.0.1)<ref name="sslmate" /><ref>{{Cite web|section-url=https://www.nlnetlabs.nl/projects/nsd/index.html#releases|section=Releases|title=Name Server Daemon (NSD)|date=January 27, 2014|website=NLnet Labs|access-date=January 7, 2018}}</ref>, OpenDNSSEC,<ref name="sslmate" /> PowerDNS (since version 4.0.0),<ref name="sslmate" /> Simple DNS Plus (since version 6.0),<ref name="sslmate" /> tinydns<ref name="sslmate" /> and Windows Server 2016.<ref name="sslmate" /> Many hosted DNS providers also support CAA records, including [[Amazon Route 53]],<ref>{{Cite web|url=https://aws.amazon.com/about-aws/whats-new/2017/08/amazon-route-53-now-supports-caa-records/|title=Amazon Route 53 now supports CAA records|date=August 21, 2017|website=[[Amazon Web Services]]|language=en|access-date=January 7, 2018}}</ref> [[Cloudflare]], [[DNS Made Easy]] and [[Google Cloud DNS]].<ref name="sslmate" /> |
||
== Mandatory checking == |
== Mandatory checking == |
||
Initially the implementation of CAA was voluntary. However, in March 2017 the [[CA/Browser Forum]] voted in favor of making CAA checking mandatory for all certificate authorities.<ref name="cab2017" /> All publicly trusted certificate authorities have until September 2017 to implement CAA checking. |
|||
== Examples == |
== Examples == |
||
| Line 62: | Line 62: | ||
== References == |
== References == |
||
{{ |
{{Reflist}} |
||
== See also == |
== See also == |
||
Revision as of 13:46, 7 January 2018
DNS Certification Authority Authorization (CAA) is an Internet security mechanism which uses resource records in the Domain Name System (DNS) to allow domain name holders to specify which certificate authorities are authorized to issue certificates for that domain, and which types of certificates they are able to issue.[1] In September 2017, the CA/Browser Forum will made it mandatory for publicly trusted certificate authorities to check a domain's CAA records before issuing a certificate.[2] CAA is specified by RFC 6844 which defines a new "CAA" DNS resource record type containing name-value pairs of the certificate authorities and whether they are able to issue wildcard certificates or only specific-subdomain certificates.[1] Unlike DNS-based Authentication of Named Entities (DANE), it is a purely administrative control, and does not prevent a malicious certificate authority from issuing fraudulent certificates. Third parties monitoring certificate authority behaviour might check newly issued certificates against the domain's CAA records, but must be aware that a domain's CAA records may have changed between the time the certificate was issued and the time the third-party makes checks them.
Record structure
Each CAA resource record contains a flags byte and a property. The flags byte contains flags which can influence the interpretation of the record. The property consists of a "tag" which allows selection between several kinds of CAA record, and a "value" string whose meaning depends on the choice of tag.
Currently one flag is defined: the issuer critical flag is represented by the most significant bit of the flag's byte. If the issuer-critical flag's value is 1 (that is, a flags byte equal to 128), this indicates that a CA which does not understand or does not implement the property tag in this record should refuse to issue a certificate for the domain.[1] This is similar to the way critical extensions in X.509 certificates work.
Besides the flag, three property tags are defined:
- issue
- This property authorizes the holder of the domain specified in the "value" field to issue certificates for the domain for which the property is published.
- issuewild
- This property acts like issue but allows wildcard certificates.
- iodef
- This property specifies a method for CAs to report to the domain holder when a certificate is issued. Not all CAs support this tag, so there is no guarantee that all certificate issuances will be reported.
Support
As of 2018[update], CAA records are supported by BIND (since version 9.10.1B),[3] Knot DNS (since version 2.2.0),[4][5] ldns (since version 1.6.17),[4] NSD (as of version 4.0.1)[4][6], OpenDNSSEC,[4] PowerDNS (since version 4.0.0),[4] Simple DNS Plus (since version 6.0),[4] tinydns[4] and Windows Server 2016.[4] Many hosted DNS providers also support CAA records, including Amazon Route 53,[7] Cloudflare, DNS Made Easy and Google Cloud DNS.[4]
Mandatory checking
Initially the implementation of CAA was voluntary. However, in March 2017 the CA/Browser Forum voted in favor of making CAA checking mandatory for all certificate authorities.[2] All publicly trusted certificate authorities have until September 2017 to implement CAA checking.
Examples
In the following examples, assume that we want to control certificate issuance for the domain example.com.
To signify that only the CA Let's Encrypt can issue certificates to the domain, as well as all of its subdomains, one may use the CAA record
example.com. IN CAA 0 issue "letsencrypt.org"
To disallow issuance for a specific subdomain, nocerts.example.com, one would allow issuance only to the empty issuer list,
nocerts.example.com. IN CAA 0 issue ";"
In this case, in a request to issue a certificate to nocerts.example.com, the relevant CA will stop its search for CAA records at the subdomain. To signify that the CA may report certificate issues or policy violations by email to caa@example.com, or through RID messages to caa.example.com, the iodef property may be applied as follows:
nocerts.example.com. IN CAA 0 issue ";" nocerts.example.com. IN CAA 0 iodef "mailto:caa@example.com" nocerts.example.com. IN CAA 0 iodef "https://caa.example.com"
If, in the original example, we would like to allow issuance to specific domains, but disallow issuance of any wildcard certificates, the issuewild property may be applied:
example.com. IN CAA 0 issue "letsencrypt.org" example.com. IN CAA 0 issuewild ";"
The critical flag is intended for usage when future inclusions of new properties may impact issuance. If, for example, a future version of CAA would include the tag "future", then the record set
example.com. IN CAA 0 issue "letsencrypt.org" example.com. IN CAA 128 future "Some value"
would result in no issuance, if the CA does not know how to parse the record, for instance if it has not yet updated its parsing engine to the new version.
References
- ^ a b c Hallam-Baker, Phillip; Stradling, Rob (January 2013). DNS Certification Authority Authorization (CAA) Resource Record. IETF. doi:10.17487/RFC6844. ISSN 2070-1721. RFC 6844.
- ^ a b Hall, Kirk (March 8, 2017). "Results on Ballot 187 - Make CAA Checking Mandatory". CA/Browser Forum. Retrieved January 7, 2018.
- ^ Risk, Vicky (August 29, 2014). "Certificate Authority Authorization Records". Internet Systems Consortium. Retrieved January 7, 2018.
- ^ a b c d e f g h i "Who Supports CAA Records?". SSLMate. Retrieved January 7, 2018.
- ^ Včelak, Jan (April 26, 2016). "Knot DNS 2.2.0 release". Retrieved January 7, 2018.
- ^ "Name Server Daemon (NSD)". NLnet Labs. January 27, 2014. Retrieved January 7, 2018.
{{cite web}}:|section=ignored (help); Missing or empty|url=(help) - ^ "Amazon Route 53 now supports CAA records". Amazon Web Services. August 21, 2017. Retrieved January 7, 2018.