The Content Analysis System (CAS) must be configured to use DoW-approved online certificate status protocol (OCSP) responders or certificate revocation lists (CRLs) to validate certificates used for PKI-based authentication.

Once issued by a DoW certificate authority (CA), public key infrastructure (PKI) certificates are typically valid for three years or shorter within the DoW. However, there are many reasons a certificate may become invalid before the prescribed expiration date. For example, an employee may leave or be terminated and still possess the smartcard on which the PKI certificates were stored. Another example is that a smartcard containing PKI certificates may become lost or stolen. A more serious issue could be that the CA or server which issued the PKI certificates has become compromised, thereby jeopardizing every certificate keypair that was issued by the CA. These examples of revocation use cases and many more can be researched further using internet cybersecurity resources.

PKI user certificates presented as part of the identification and authentication criteria (e.g., DoW PKI as multifactor authentication [MFA]) must be checked for validity by network devices. For example, valid PKI certificates are digitally signed by a trusted DoW CA. Additionally, valid PKI certificates are not expired, and valid certificates have not been revoked by a DoW CA.

Network devices can verify the validity of PKI certificates by checking with an authoritative CA. One method of checking the status of PKI certificates is to query databases referred to as CRLs. These are lists which are published, updated, and maintained by authoritative DoW CAs. For example, once certificates are expired or revoked, issuing CAs place the certificates on a CRL. Organizations can download these lists periodically (i.e., daily or weekly) and store them locally on the devices themselves or even onto another nearby local enclave resource. Storing them locally ensures revocation status can be checked even if internet connectivity is severed at the enclave’s point of presence (PoP). However, CRLs can be rather large in storage size and further, the use of CRLs can be rather taxing on some computing resources.

Another method of validating certificate status is to use the OCSP. Using OCSP, a requestor (i.e., the network device which the user is trying to authenticate to) sends a request to an authoritative CA challenging the validity of a certificate that has been presented for identification and authentication. The CA receives the request and sends a digitally signed response indicating the status of the user’s certificate as valid, revoked, or unknown. Network devices should only allow access for responses that indicate the certificates presented by the user were considered valid by an approved DoW CA. OCSP is the preferred method because it is fast, provides the most current status, and is lightweight.

Verify the system is configured to check certificate revocation with the following steps:

1. Log on to the SSH CLI with an administrative account. 2. Enter "enable" and provide the password. 3. Enter "show running-config authentication". 4. Review the output for the setting: "certificate-auth use-revocation true".

If "certificate-auth use-revocation" is not set to "true", this is a finding.

Configure the system to check certificate revocation with the following steps:

1. Log on to the SSH CLI with an administrative account. 2. Enter "enable", and then enter the password. 3. Enter "configure terminal". 4. Enter "authentication certificate-auth use-revocation true". 5. Enter "exit" and then "exit" again to leave configuration mode.