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.
Validation can also be performed manually using the perform custom validation on a sample of certificates. For more information, see EJBCA Validation/Conformance Tool.
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.
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.|
|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.
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.
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.
The following validator types currently exist in EJBCA. For details, click the link in the Name column below.
|Key Validators||This class of validator is intended to be run on the submitted public key, so is run during the data phase|
|Post Processing Validators||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||Field validators evaluate the soundness of the fields in the submitted CSR, and are run during the data or approvals phases.|
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:
|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)