SecureBlackbox 2020 iOS Edition

Questions / Feedback?

TLSRevocationCheck (property)

Specifies the kind(s) of revocation check to perform.

Syntax

@property (nonatomic,readwrite,assign,getter=TLSRevocationCheck,setter=setTLSRevocationCheck:) int TLSRevocationCheck;
- (int)TLSRevocationCheck;
- (void)setTLSRevocationCheck:(int)newTLSRevocationCheck;

/* Possible Values */
CRC_NONE(0),
CRC_AUTO(1),
CRC_ALL_CRL(2),
CRC_ALL_OCSP(3),
CRC_ALL_CRLAND_OCSP(4),
CRC_ANY_CRL(5),
CRC_ANY_OCSP(6),
CRC_ANY_CRLOR_OCSP(7),
CRC_ANY_OCSPOR_CRL(8)
public var TLSRevocationCheck: KmipserverTLSRevocationChecks {
  get {...}
set {...} }
public enum KmipserverTLSRevocationChecks : Int32 { case crcNone = 0 case crcAuto = 1 case crcAllCRL = 2 case crcAllOCSP = 3 case crcAllCRLAndOCSP = 4 case crcAnyCRL = 5 case crcAnyOCSP = 6 case crcAnyCRLOrOCSP = 7 case crcAnyOCSPOrCRL = 8 }

Default Value

1

Remarks

Specifies the kind(s) of revocation check to perform.

Revocation checking is necessary to ensure the integrity of the chain and obtain up-to-date certificate validity and trustworthiness information.

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.

Copyright (c) 2022 /n software inc. - All rights reserved.
SecureBlackbox 2020 iOS Edition - Version 20.0 [Build 8166]