Validators Overview

Validators are applied to CA's to validate the issuance of certificates, based on key strength, origin, or 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.

Issuance Phases

Different validators are run at different phases of the issuance process. If multiple validators are configured for different phases, they are executed fully in order of the phase specification, failing one phase will stop the rest of the phases from being executed.

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 before issuance, causing an 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 for the authorityKeyId, which is for the hardcoded dummy key (and the signature is different of course). In order to use the same signature algorithm as the CA issued certificate, the dummy key is of the same key algorithm as the CAs signing key; for RSA a 2048 bit key, for ECDSA secp256r1, DSA 1024 bit, or Ed25519 and Ed448.
CT pre-certificate (X509CA only)	The validator is run on the tbsCertificate (Certificate Transparency pre-certificate, RFC6962) before the final certificate is signed and prior to the CT pre-certificate being submitted to any CT logs. For CT pre-certificate validation to be performed, Certificate Transparency submission must be enabled for the certificate profile, otherwise, a CT pre-certificate is not created, and hence not validated.
Certificate	The validator is run on the final signed certificate, but prior to it being issued, stored, or published. Validation failure may cause a roll-back of the certificate creation process (if ghe validator is configured to abort), in practice meaning that no certificate was issued. If Certificate Transparency submission is enabled however the certificate may have been submitted to CT logs, resulting in an inconsistent state with a CT pre-certificate being logged but no final certificate issued. If you use CT, it's recommended to perform certificate validation in the pre-sign and CT pre-certificate phases.

Validator Types

The following validator types currently exist in EJBCA. For details, click the link in the Name column below.

Name	Implementations	Description
Key Validators	RSA Key Validator ECC Key Validator Public Key Block List 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 Block List Validator Domain Allow List 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 scripts are enabled and the script is not on the allow list, it is treated as a not applicable event by the external command validator. This has no effect for Certificate Field Validators (Domain Block List and CAA Validators)