.png){kind=logo}
CAA Validator
ENTERPRISE
The Certificate Authority Authorization (CAA) validator is based on RFC 6844, erratum 5065, RFC 9495 and the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates. These specify that for complying CAs issuing certificates containing DNSName fields (for TLS validation) and rfc822Name fields (for S/MIME validation) values in the subjectAltName extension, the CA must perform a lookup check to the DNS CAA records of all specified names and check that the CAA records allow issuance for the given issuer.
The result of all CAA lookups is written to the server logs on INFO level.
TLS Validation
A typical CAA record has the following format:
example.com. 243 IN CAA 0 issue "ca.org"This record says that the issuer known as ca.org is permitted to issue certificates (including wildcards) for all domains and subdomains to the domain example.com. In the EJBCA case, this means that according to CAA, an end entity that includes the field DNSNAME=example.com in the subjectAltName (SAN) extension must pass a CAA Validator check before having a certificate issued to it.
S/MIME Validation
CA/B Forum specifies the criteria for allowing or rejecting a SMIME certificate request based on a performed CAA check defined in the S/MIME Base Requirements document.
A typical S/MIME CAA Record has the following format:
example.com. 243 IN CAA 0 issuemail "ca.org"This allows the issuer known as ca.org to issue certificates that include email fields with the domain (user@example.com).
To comply with the S/MIME base requirements, the domain part of the rfc822name attributes will be validated against these records.
For example, a certificate request with a "Subject Alternative Name" like rfc822name=john.doe@example.com , can be issued for ca.org, since there is a record allowing this.
For the complete set of examples, check Section 5 - RFC 9495.
To enable this type of validation, in addition to creating the CAA validator, the certificate profile field Extended Key Usage option Email protection must be selected within the certificate profile.
When using a CAA validator, you must select either Email Protection or Server Authentication in the certificate profile, but not both.
Configuration
Issuance Phase
Different validators are run at different phases of the issuance process. The CAA Validator can only be run during the data phase. For descriptions of the different issuance phases, see Validators Overview.
Fields
The following displays the CAA Validator settings.
EJBCA allows the administrator to configure the following when setting up a CAA Validator:
Field Name | Description |
|---|---|
Issuers | This value should match the value field in the CAA record of the DNS, thus " |
DNS Resolver | Optional field for specifying an IP address as DNS Resolver (such as 8.8.8.8 or 8.8.4.4). If left blank, Google's Public DNS will be used. Port can be appended to the end of the IP address. If left blank, then the default port 53 will be used. |
Lookup DNAMEs | Select to look up and follow any DNAME records found during CAA processing. To comply with RFC 6844, it is recommended to keep this option enabled. |
Validate DNSSEC | Select to validate DNSSEC to be validated. If enabled, and your DNS is signed with DNSSEC and your DNS presents a faulty set of records (suggesting a possible MitM attack), CAA validation will fail. It is strongly recommended to enable DNSSEC checks to ensure the authenticity of DNS responses. |
Trust Anchor | Trust anchors are configured to allow obtaining secure answers from the root zone of the DNS using DNSSEC. By default, IANA root anchor is used. This value may be modified but should remain unchanged unless the record is signed by another trust anchor. |
Fail on lookup error | The default behavior is to permit issuance if a lookup error is encountered more than once and EJBCA can establish that the domain is not signed with DNSSEC. To always prohibit issuance when a lookup error is encountered, enable this option. To have this option enabled may be a compliance requirement if you are contacting your own DNS resolver for CAA lookups. |
DNS Protocol | Select one DNS Protocol either UDP or TCP. If left blank, then the default protocol should be UDP (Recommended). |
Ignore Top Level Domains | CAA records are seldom put on TLD level, and looking up CAA records for the TLD can waste milliseconds. With this setting, you can specify a newline-separated list of top-level domains for which no CAA lookups will be performed. For example: CAA lookups will still be performed on subdomains, e.g. |
Ignore Domain Names | Domain names to exclude from CAA validation. Wildcards are supported. For example: |
Ignore Critical Property Tags | Critical tags to ignore during CAA lookup. This allows for CAA lookup to continue even if critical tags unknown to EJBCA are encountered. For example: contactemail Use with caution! By default, unknown critical tags result in issuance prohibited. Ignoring critical tags does not conform with RFC6844. |
Use IODEF E-mail | Select to enable sending e-mails to any mailto-links registered on the DNS as CAA IODEF records. Doing so enables the following additional settings: From The From field in the resulting e-mail. Subject The Subject line in the resulting e-mail. Additional Information: Any additional information required, in addition to the following default message which will be appended at the end: A faulty Certificate Request was made for the domain ' Use IODEF WEB Enables sending IODEF incident reports to any http/s-links registered on the DNS as CAA IODEF records. |
Note the following regarding CAA validation:
CAA validation will pass if the DNS lacks CAA records entirely.
CAA validation will pass if the DNS has only TLS records (issue, issuewild, etc) for a S/MIME validation.
CAA validation will pass if the DNS has only S/MIME records (issuemail) for a TLS validation.
EJBCA uses IPv4 to perform lookups of CAA records.
EJBCA currently does not validate parameters in CAA records, but such records will still be evaluated correctly. Parameter handling is planned in future versions.
The CAA Validator requires TCP and UDP port 53 to be open in the firewall.
Current iodef implementation does not support TLS protocol to send iodef reports over a secure connection. This will be added per request by customers or in future releases.
Another limitation is that the implementation does not support callback, only immediate responses with code 200 OK are supported. For more information, refer to RFC-6546.
The attributes in the produced incident report are the minimum required ones. Optionals are ignored for now but could be added if requested.
EJBCA currently does not support the CAA Contact property as defined in section 1.6.1 of the Baseline Requirements.
CAA Validator Logging
The CAA validator logs both success and failure. Since success can be considered a security event, to be shown as evidence, this is logged in the security audit log. Failures are not security events per se and logged to the standard server log at info level.
Example failure:
15:49:07,017 INFO [org.cesecore.keys.validation.KeyValidatorSessionBean] (default task-24) VALIDATOR_VALIDATION_FAILED;FAILURE;VALIDATOR;CORE;msg=CAA Validator 'CAA Validator' failed issuance of certificates
to issuer primekey.com, with messages:
[Not allowed to issue certificate for dnsName *.allow.klaan.nu. Result type was: Issuance of wildcard certificates for this domain is prohibited. Parameters: {} Message:
, Allowed to issue certificate for dnsName *.klaan.nu. Result type was: May issue, no CAA results for domain. Parameters: {} Message:
, Not allowed to issue certificate for dnsName allow.klaan.nu. Result type was: Rejected due to issuer not having a CAA record at domain's DNS, or issuance being prohibited. Parameters: {} Message: ]. Example success:
15:50:58,930 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-8) 2017-09-20 15:50:58+02:00;VALIDATOR_VALIDATION_SUCCESS;SUCCESS;VALIDATOR;CORE;ejbca;1865017768;;caaklaan1;msg=CAA Validator 'CAA Validator'
has permitted issuance of certificates to issuer primekey.com, with messages:
[Allowed to issue certificate for dnsName *.klaan.nu. Result type was: May issue, no CAA results for domain. Parameters: {} Message:
, Allowed to issue certificate for dnsName a.allow.klaan.nu. Result type was: May issue. Parameters: {} Message: primekey.com
, Allowed to issue certificate for dnsName b.allow.klaan.nu. Result type was: May issue. Parameters: {} Message: primekey.com]. The debug logging DNS lookup result available can amount to large volumes and is therefore set at a debug level disabled by default. To enable a separate DNS lookup log, you can send the DEBUG log for the class CaaDnsLookup to a separate log, similar to the OCSP Transaction and Audit logging. For more information, see Logging.
Related Content
For more general information about validators and common validator settings, see the Validators Overview.