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/.
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:
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.
The CAA Validator can be run during the data phase only.
EJBCA allows the administrator to configure the following when setting up a CAA Validator:
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.
|Optional field for specifying an IP address as DNS Resolver (such as 18.104.22.168 or 22.214.171.124). If left blank, Google's Public DNS will be used.|
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.
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 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:
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.
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.
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.
The following lists available Domain Blacklist Validator fields:
|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:
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".
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 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"