...
In addition to the common attributes, the StaticPKIX Trust Engine can have the following
Name | Type | Default | Description |
|---|---|---|---|
| integer | 1 | Length of CA chain to permit. |
certificate | local pathname | Optional path to a file with one or more CA certificate to trust. | |
checkRevocation | "off", "entityOnly", "fullChain" | "off" | Controls the behavior of CRL checking by the trust engine. If omitted or set to "off", no CRLs are used at all. The other options require that at least one CRL be available and will fail the check otherwise. The "fullChain" option requires that a CRL be available for all untrusted certificates in the validation path, otherwise only a CRL for the end entity certificate is required. |
Elements
The PKIX Trust Engine can only have the child elements
In addition to the child elements, the StaticPKIX Trust Engine can have the following
Name | Cardinality | Description | |
|---|---|---|---|
<CredentialResolver> | 0 or 1 | A credential resolver plugin to use to load the CA certificate(s) to trust | |
Validating Signatures
This engine is predicated on the assumption that the actual signing key isn't known ahead of time. Therefore, the signature MUST carry keying material (in the form of X.509 certificates) inside an accompanying <ds:KeyInfo> element inside the signature/message.
...
Finally, note that any inclusion of CRLs requires that great care be taken to ensure all CRLs included are valid. A single expired CRL in the validation process will lead to rejection of all certificates, even those from a different CA hierarchy.
Examples
| Code Block | ||
|---|---|---|
| ||
<TrustEngine type="PKIX"/> |