Certificate Field Validators

Certificate field validators are run on specific fields on the CSR, such as the dnsName SAN field.

Google Safe Browsing Validator

The Google Safe Browsing Validator performs a lookup of the domains in the certificate against the Google Safe Browsing Lookup API v4. The Google Safe Browsing API is listing websites used for distribution of malware and phishing.

The Google Safe Browsing API should only be used for non-commerical purposes.

Before the validator can perform lookups against the API, you need to create an API key using the Google Developer Console, see https://console.developers.google.com/.

images/download/attachments/85926043/Google_Safe_Browsing_Validator.png

CAA Validator

ENTERPRISE This is an EJBCA Enterprise feature.

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

Issuance Phase

The CAA Validator can be run during the data phase only.

Fields

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 "ca.org" in the above example. If required, you can specify multiple issuers by separating them with a semicolon. For example, specifying "ca1.org;ca2.org;ca3.org" will match a CAA record with either ca1.org, ca2.org or ca3.org.

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

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

Domain Blacklist Validator

Domain Blacklist Validators allows DNSNAME attributes in Subject Alternative Name to be checked before issuance.

The intended use case is to require confirmation during the approval process for certain high-value domains (provided that approvals are enabled), but Domain Blacklist Validators can also be used for blocking known fraud sites, for example.

You can configure multiple validators with different settings. The following example shows a validator configured to allow validation while warning the administrator during the approval process.

images/download/attachments/85926043/domain_blacklist_validator.png

Issuance Phase

The Domain Blacklist Validator can be run during the data or approval phase. If configured to run during the approval phase, and validation fails, a confirmation message will be shown in the RA Web for the approving administrators.

If the validator has been set to run during the approval phase and no approval requirements exist for the CA or Certificate Profile, then it will have no effect.

Fields

The following lists available Domain Blacklist Validator fields:

Field Name

Description

Normalizations to apply

The normalization to be performed against the domains before comparing against the blacklist. Only one normalization is currently available:

ASCII Lookalikes: This normalizes character or character sequences that look similar. IDN/Punicode characters of domains are not changed. The following characters and character sequences are normalized:

From

To

From

To

From

To

From

To

From

To

From

To

From

To

ci

a

cl

d

vv

w

6

b

9

g

I (i)

l (L)

2

z

fi

a

rn

m

0 (zero)

o

q

g

1 (one)

l (L)

5

s

u

v

Checks to perform

The checks control how domains are compared against the entries in the blacklist. At least one must be selected.

Base domain: All base domains will be compared against the blacklist. If issuing a certificate for "a.b.example.com", then "a.b.example.com", "b.example.com", "example.com", and "com" will be checked against the blacklist.

Domain component: All domain components will be checked, individually. So for "a.b.example.com", the blacklist will be searched for "a", "b", "example", and "com".

Exact match: Domains that match exactly will be matched. Note that this check is included with "Base domain". For "a.b.example.com", it will only search the blacklist for "a.b.example.com".

Existing blacklist

Shows information about the currently active blacklist and only displays once a blacklist has been uploaded.

Number of entries: Number of blacklisted domains. The effective number of blacklisted domains may be greater due to normalization and the checks performed.

Upload date: Time when the blacklist was uploaded. Shown in UTC timezone.

SHA-256: Hash of the entire file, as uploaded (i.e. including comments and whitespace).

Upload new blacklist

Click Browse to upload a blacklist. Any existing blacklist will be replaced when a new one is uploaded.

For information on syntax, see Blacklist File Syntax. Depending on your configuration, there may be a file size limit. With a limit of 1 MB, you will be able to put around 50 000 domains in your blacklist. To work around this limit, you can split the blacklist and use several validators.

Blacklist File Syntax

Blacklist text files contain one blacklisted domain per line:

  • IDN domains must be Punycode encoded

  • Empty lines are ignored

  • Leading and trailing whitespace is ignored

  • Text after a # is considered a comment and is ignored.

  • Comments may contain ASCII or UTF-8 text, but the file may not contain a byte order mark (BOM). If in doubt, save the file in plain ASCII format.

The following shows an example of a blacklist text file:

sample_blacklist.txt
# Sample blacklist file. Created 2019-03-01
 
bank # If domain component blocking is enabled, then this will block "bank.com", "bank.example.com" but NOT "memorybank.com"
 
example.com # With base domain blocking one can block a domain including subdomains.
net # ...or entire TLDs (Top Level Domains)
 
evil.example.edu # It is possible to block a specific subdomain only
xn--rvare-jua.example.com # This is an IDN domain "rövare.example.com"