.png){kind=logo}
Validators Overview
Validators are applied to Certificate Authorities (CAs) to validate the issuance of certificates, based on attributes such as key strength, origin, or other values inherent to the certificate issued.
To apply a validation to the certificate issuance process, select the appropriate Validator on the Edit CA page (EJBCA menu ❯ CA Functions ❯ Certification Authorities > Edit CA). Validators are executed during designated phases of the certificate issuance process, and their scope can be restricted to specific certificate profiles.
Note that a validator is executed every time a new certificate is issued if the validator is been selected on the Edit CA page and the certificate profile of the certificate being issued is enabled on the Edit Validator page.
If a validation fails, the certificate issuance process is canceled.
Validators are configured on the EJBCA Validators page (EJBCA menu > CA Functions > Validators).
Issuance Phases
Different validators are run at different phases of the issuance process. When multiple validators are configured for different phases, they execute sequentially. A failure in any phase halts subsequent phases.
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 | 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 CA's 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). |
CT pre-certificate | 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 the 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 exist in EJBCA. For more information, click the name of the validator type in the following table.
Name | Implementations | Description |
|---|---|---|
| Key validators are intended to be run on the submitted public key and are executed during the Data phase. | |
| Post processing validators are intended to validate the processed certificate before or after signing. These validators can be run during the Pre-sign certificate, CT pre-certificate, or Certificate phases. | |
| Field validators evaluate the soundness of the fields in the submitted CSR and are run during the Data or Approval 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 (for example, 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. The setting has no effect for Certificate Field Validators. |
For more information on validator types and specific implementations, see the following sections.