Certificate Field Validators

It is also possible to validate issuance based on other certificate values before it comes to issuance, using the Certificate Authority Authorization (CAA) Validator.

Validator Types

CAA Validator

The Certificate Authority Authorization (CAA) validator is based on RFC 6844, erratum 5065 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 values in the subjectAltName extension, the CA must perform a lookup check to the DNS(s) of all specified names and check that the CAA records allow issuance for the given issuer.

The result of all CAA lookups are written to the server logs on INFO level.

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.

EJBCA allows the administrator to configure the following when setting up a CAA Validator:

Field Name

Description

Issuer

This value should match up to the value field in the CAA record of the DNS, thus "ca.org" in the above example.

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.

Lookup DNAMEs

Select to lookup 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.

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 'example.com' for the issuer ca.com which was rejected by the CA due to the issuer not having a CAA record on the domain's DNS.

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.

  • 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 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.

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.