Specifies the kind(s) of revocation check to perform.
property RevocationCheck: TsbxRevocationCheckKinds read get_RevocationCheck write set_RevocationCheck;
TsbxRevocationCheckKinds = ( crcNone, crcAuto, crcAllCRL, crcAllOCSP, crcAllCRLAndOCSP, crcAnyCRL, crcAnyOCSP, crcAnyCRLOrOCSP, crcAnyOCSPOrCRL );
Revocation checking is necessary to ensure the integrity of the chain and obtain up-to-date certificate validity and trustworthiness information.
Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) responses serve the same purpose of ensuring that the certificate had not been revoked by the Certificate Authority (CA) at the time of use. Depending on your circumstances and security policy requirements, you may want to use either one or both of the revocation information source types.
|crcNone (0)||No revocation checking|
|crcAuto (1)||Automatic mode selection. Currently this maps to crcAnyOCSPOrCRL, but it may change in the future.|
|crcAllCRL (2)||Check all provided CRL endpoints for all chain certificates.|
|crcAllOCSP (3)||Check all provided OCSP endpoints for all chain certificates.|
|crcAllCRLAndOCSP (4)||Check all CRL and OCSP endpoints for all chain certificates.|
|crcAnyCRL (5)||At least one CRL check for every certificate in the chain must succeed.|
|crcAnyOCSP (6)||At least one OCSP check for every certificate in the chain must succeed.|
|crcAnyCRLOrOCSP (7)||At least one CRL or OCSP check for every certificate in the chain must succeed. CRL endpoints are checked first.|
|crcAnyOCSPOrCRL (8)||At least one CRL or OCSP check for every certificate in the chain must succeed. OCSP endpoints are checked first.|
This setting controls the way the revocation checks are performed. Typically certificates come with two types of revocation information sources: CRL (certificate revocation lists) and OCSP responders. CRLs are static objects periodically published by the CA at some online location. OCSP responders are active online services maintained by the CA that can provide up-to-date information on certificate statuses in near real time.
There are some conceptual differences between the two. CRLs are normally larger in size. Their use involves some latency because there is normally some delay between the time when a certificate was revoked and the time the subsequent CRL mentioning that is published. The benefits of CRL is that the same object can provide statuses for all certificates issued by a particular CA, and that the whole technology is much simpler than OCSP (and thus is supported by more CAs).
This setting lets you adjust the validation course by including or excluding certain types of revocation sources from the validation process. The crcAnyOCSPOrCRL setting (give preference to faster OCSP route and only demand one source to succeed) is a good choice for most of typical validation environments. The 'crcAll*' modes are much stricter, and may be used in scenarios where bulletproof validity information is essential.