Validators are applied to CA's to validate the issuance of certificates, based on key strength, origin or on other values inherent to the certificate issued. To apply a validation to the certificate issuance process, select the appropriate Validator in the Edit CA screen, causing it to be called at the appropriate phase of the certificate issuance process. Additionally, validators can be restricted to only run for certain certificate profiles.

Note that a validator is executed every time a new certificate is issued if the validator has been selected in the Edit CA screen and the certificate profile of the certificate being issued is enabled in the Edit Validator screen.

Failing validation results in the issuance process being canceled.

To explore Validators, select the Validators menu option under the CA Functions header.

Validation can also be performed manually using the Validation/Conformance Check Tool to perform custom validation on a sample of certificates. For more information, see EJBCA Validation/Conformance Tool.

Issuance Phases

Different validators are run at different phases of the issuance process, these are:

Phase	Description
Approval	Validation is performed when an approval request is created (and hence only for actions that require administrator approval). A confirmation checkbox is shown in the RA web when approving the request. If the validator has been set to run during the approval phase and no approval requirements exist for that CA, then it will have no effect.
Data	Validation is performed on the collated data prior to the tbsCertificate being assembled.
Issuance	Validation is performed during the approval phase just prior to issuance, causing a approval prompt to be added to issuance.
Pre-sign certificate (X509CA only)	The validator is run on a certificate signed with a hardcoded dummy key, before any CT pre-certificate or final certificate has been produced. Used to validate certificate contents before the CAs private key is used. This is useful since signing a CT pre-certificate counts as issuance, and revocation is in principle needed even if the CT pre-certificate has not been submitted to logs. Using a pre-sign certificate allows validation before any requirements are put on a CT pre-certificate or final certificates. The pre-sign certificate has the same contents as the final certificate except the authorityKeyId, which is for the hardcoded dummy key (and the signature is different of course).
CT pre-certificate (X509CA only)	The validator is run on the tbsCertificate (Certificate Transparency pre-certificate, RFC6962) prior to the final certificate being signed and prior to the CT pre-certificate being submitted to any CT logs.
Certificate	The validator is run on the final signed certificate, but prior to it being issued, stored or published.

Validator Types

The following validator types currently exist in EJBCA. To read further about them, click on the link in the Name column in the table below.

Name	Implementations	Description
Key Validators	RSA Key Validator ECC Key Validator Public Key Blacklist Validator	This class of validator is intended to be run on the submitted public key, so is run during the data phase
Post Processing Validators	External Command Certificate Validator	Post processing validators are intended to validate the processed certificate before or after signing, so can be run during the pre-sign certificate, CT pre-certificate or certificate phases.
Certificate Field Validators	CAA Validator Domain Blacklist Validator	Field validators evaluate the soundness of the fields in the submitted CSR, and are run during the data or approvals phases.

Audit Logging

All validation results are both audit logged and also logged in the server logs with more detail (log level can be configured).

Common Validator Settings

To control the behavior during certificate issuance, the following base restrictions can be applied per validator:

Setting	Description
Description	A general description of the Validator, not used for any validation purposes.
Apply for Certificate Profiles	Validate keys for these certificate profiles only. If nothing is selected in this list, no validation will be performed.
Apply for all Certificate Profiles	Validate keys for all certificate profiles, the list above will be ignored.
If Validation failed	Define behavior if key validation fails (e.g. abort issuance, log error message to trigger monitoring systems, etc.). All failed issuance also adds a record in the security audit log.
If Validator was not applicable	Define behavior if the input is not applicable for the selected validator (for example, abort issuance, log error message to trigger monitoring systems, etc.). This handles the case when for example a CSR with ECC keys is passed to an RSA key validator. Also for the external command validator, if script whitelisting is enabled and the script is not whitelisted, it is treated as a not applicable event by the external command validator. This has no effect for Certificate Field Validators (Domain Blacklist and CAA Validators)