Configure Data Input - OCSP Response List Pre-generation

Validation Authority periodically pre-generates lists of OCSP responses for all registered certificate issuers. These lists are loaded by Validation Responders and used to service both OCSP and SCVP requests. If your environment does not make use of Validation Responders, disable OCSP response list pre-generation to avoid the processing overhead of creating response lists.

This section describes the steps to configure how pre-generated OCSP response lists are created. These lists are consumed by standalone Validation Responders.

On the Configuration page, click configure OCSP Response List Pre-generation.
Select the Enabled option to create pre-generated response lists. By default, this option is not selected.
If a CRL should be registered for a certificate issuer before Validation Authority will create an OCSP response list, select the Require CRL option. By default, this option is not selected.
To avoid generating response lists when CA certificates are expired or not yet valid, select the Skip Expired Issuers option.
To change the location of the output directory, enter the new location in the Output directory field.

The output directory is the location where OCSP response lists are stored.

When a list of OCSP responses is generated by Validation Authority, it is placed in this directory with a file name based on the nickname of the issuer. If this directory path is not absolute, it will be in a directory from the base of the Validation Authority installation. The default location is in a directory from the base of the Validation Authority installation is server/proofs/.

This default location is part of the Tomcat web server web path. The lists that are placed in this directory will be available over HTTP from Validation Authority.
To change the default value of the file suffix (.prf) used in response list file names, enter the new suffix in the Response list file suffix field.

The Response list file suffix field specifies the suffix that is used to identify a file as containing a pre-generated OCSP response list.

When an OCSP response file is generated and placed into the Output Directory, it will have a name that is constructed based on the nickname of the issuer with this suffix concatenated. The default is -ocsp.prf. For example, if the issuer's nickname is aaa-security-ca, and this suffix is .prf, the file will be named aaa-security-ca-oscp.prf.

Note: If you change the default response list file suffix, you also need to configure the sources.bml file of any Validation Responder that obtains responses from a response list output directory to accept files with the new suffix. Refer to the Validation Responder Administration Guide for more details. HID Global recommends that you do not modify this setting.
Depending on your OS, enter your Post-execution command. This is a command that executes immediately after each OCSP response list is generated. Typically, copy the newly generated list to a new location for retrieval by a Validation Responder.

For example, on a Validation Authority running on a Linux OS, run the command as follows:
Copy
```
/usr/local/scripts/securecopy {} /mnt/server/proofs/listname
```
Where {} will be automatically replaced by the newly generated response list’s path.

On a Validation Authority running on a Windows OS, run the command as follows:
Copy
```
xcopy.exe /Y {} f:\PATH
```
Where {} will be automatically replaced by the newly generated response list’s path, and /Y indicates that the script should overwrite older files without prompting.
Enter the Maximum post-execution time that specifies (in seconds) the maximum amount of time (in seconds) that a post-execution command/script is allowed to execute before being forced to terminate by Validation Authority. The default is 5 minutes.
Enter the Minimum response duration that specifies the minimum amount of time for which OCSP responses created by Validation Authority are valid.

If the CRL that the Validation Authority creates responses from expires, this value will enable the Validation Authority to continue creating non-expired responses. Setting this value to 0 means that the Validation Authority cannot create non-expired responses after the expiration of the CRL used to create responses. The default value is 86400 seconds which indicates that OCSP response list is generated within a minimum validity period of one day.
Enter the CRL Expiration Buffer that defines the length of time, in seconds, that a response is accepted as valid beyond the CRL’s nextUpdate time. OCSP responses are valid until a nextUpdate time that indicates when that response should be rejected in favor of a newer response. When set to a value greater than 0, the CRL Expiration Buffer property defines the length of time, in seconds, that a response is accepted as valid beyond the CRL’s nextUpdate time. This can be useful in preventing problems when Validation Authority is unable to obtain an updated CRL (for example, due to a network problem). A value of 0 means that the CRL’s validity period is used. The default value is 0.
From the Responder ID drop-down list, select the option to specify whether OCSP responses identify the responder certificate by key or by name.

You can specify the format of the responder ID that is contained in OCSP responses. The responder ID enables relying parties locate the responder certificate in the OCSP response. If you select by key, the responder ID will be represented by the hash of the public signature key of Validation Authority. If you select by name, the responder ID will be the distinguished name in the signing certificate of Validation Authority. HID Global recommends against selecting the by name option, unless your relying party software is unable to process responder IDs that use the key hash.
Enter the Certificates per Response that specifies the number of certificates which status will be represented in each OCSP response. To change the number of certificates represented in each OCSP response, enter the new number in the Certificates per Response field.

This property determines the number of certificates for which status information is included in each generated response. When this value is set higher, the server CPU time is reduced (since fewer signatures are generated) and bandwidth to Validation Responders is also reduced, but the responses will be larger for Relying Parties. The default is 20.
Enter the Signing threads parameter that is used to reduce the amount of time required to sign the individual OCSP responses in an OCSP response list. The best value for your environment depends on the server on which Validation Authority is running and the HSM that you are using. A value such as 8 is typically a good starting point.
Enter the Maximum delta time that specifies the period, in seconds, after generating a full OCSP response list during which Validation Authority will generate a delta response list.

A delta response list is a file that only contains information about credential updates or additions that were made since the last time Validation Authority generated a full response list (for more information, refer to the Advanced Configuration). Two parameters control delta response list generation. A value of 0 means that Validation Authority does not generate delta response lists.
Enter the Delta response list file suffix that specifies the file suffix to add to a delta response list. By default, Validation Responders only accept files that have the .prf and .prfd extensions. If you change the suffix, make sure that you also configure the Validation Responders to request files using the non-default suffix.
From the Status returned for unrecognized serial numbers drop-down list, select one of the following:
- REVOKED - As defined in RFC 6960.
- GOOD - For backward compatibility with RFC 2560.
- UNKNOWN - Validation Authority can return UNKNOWN, if desired.
- UNAUTHORIZED - To be excluded from the proof list.
A proof list contains revocation status data for all the serial numbers that are recognized and for some of the unrecognized serial numbers. Any OCSP requests for unrecognized certificates will receive an UNAUTHORIZED response code.

Perform the following steps to configure Validation Authority to control which unrecognized serial numbers are to be included in the proof list. This configuration prevents the size of the proof list from getting too large. For example, if CA issues certificates of random serial numbers, then a proof list gets very large if all the unrecognized serial numbers are included.
Select Skip serial numbers in gaps. If selected, Validation Authority will not include some of the unrecognized serial number which is in a big gap between two adjacent recognized serial numbers. If this option is selected, then any certificates that fall in the gap formulated from the range of parameters configured in the following steps will be excluded from the proof list.

This property specifies whether OCSP responses inferred as valid should be limited to serial numbers close to known serial numbers.
For the Unrecognized serial numbers to be included in the proof list fields, configure the range of OCSP responses to generate before and after a known serial number.

This parameter determines the unrecognized serial numbers to include before and after a recognized serial number. If the gap between two adjacent recognized serial numbers is greater than the number of serial numbers to be included after a known serial number value (by default, 1000) , then any unrecognized certs that are in the "recognized cert number 1 + 1000" and "recognized cert number 2 - number of serial numbers to be included before a known serial number value", will not be included in the proof list and the OCSP response for those serial numbers will be the status set in " Status returned for unrecognized serial numbers:". If a gap between 2 adjacent recognized serial numbers is bigger than the range, the gap is considered to be big.

The default range is set at 100/1000.
Select Manage Empty CRLs to enable this feature. If selected, the status for unrecognized serial numbers will not be overridden from a user choice value to "UNAUTHORIZED".

By default, this feature is not selected.
Configure the Maximum proof list entries to be included in a proof list.

The default value is 500000.

If the Skip serial numbers in gaps option is not selected, and the number of total serial numbers to be included exceeds this value, then the value of the Skip serial numbers in gaps parameter will be overwritten to be selected to reduce the size of the proof list. If the Skip serial numbers in gaps option is not selected (that is, to include all unrecognized serial numbers in the proof list), and the number of total serial numbers to be included exceeds the Maximum proof list entries values, then the Skipgap credentials setting will be ignored, the unrecognized serial numbers to include in the proof list will be determined by the range set in the Unrecognized serial numbers to be included in the proof list field.

Email Notification when proof list entries cross a threshold value:

Prerequisites: Email logging must be configured. For configuration, refer to Configure Email Logging.

The operator will get an email notification whenever the proof list entries in the proof file reaches 90% of the configured Maximum proof list entries value.

For example, Maximum proof list entries = 500000. An email notification will be sent and a log entry will be created if the actual proof list entries in the proof file become equal to or greater than 450000 (i.e., 500000*0.9), i.e., when the value reaches 90% of the maximum proof list entries.

The notification recipient will receive an email with message "Entries in Proof List have reached 90 percent of the MaxProofListEntries value. The value of Status for Unrecognized certs will be overridden from a user choice value to UNAUTHORIZED if this value reaches MaxProofListEntries. Consider adjusting properties, maxProofListEntries, inferPrecedingSerials, and inferSucceedingSerials".
Enter a positive integer value in the Issuer Certificate Expiry duration field to enable this feature, the entered value specifies the number of days prior to the certificate expiry, from which the nextUpdate field’s format will change in the OCSP response. The default value is 0 which indicates the feature is disabled. Based on the entered expiry duration, if the issuer certificate is close to the expiry date then the nextUpdate field in the OCSP response will change to this format 9999<Month><Day><Hours><Minutes><Seconds>.

For example, if the entered value is 20, and the expiry date is 30th December 2020, the value in the nextUpdate field of OCSP response will be 99991230235959Z (Time will change according to the zone) from 11th December 2020 onwards.

Where:

9999 – Year

12 – Month

30 – Date of Expiry

23 – Hours

59 – Minutes

59 - Seconds
Enter a positive integer value (1 to 99) in the Retention Period field to enable the Archive Cutoff feature. By default, the value is 0 and the feature is disabled. If this feature is enabled, archive cutoff date will be included in the OCSP response. The certificate's "archive cutoff" date will be derived by subtracting this retention interval value from the producedAt time in the OCSP response.

For example, if the entered value is 7, and the producedAt time is 2013-11-13, then the archive cutoff value is 2006-11-13, which means that certificate expired before 2006-11-13 is not reliable.
Select the Issuer’s notBefore to enable the archive cutoff feature. If this feature is enabled, Retention Period field will become null and the issuer's valid from date will be used as archive cutoff date in the OCSP response.
Select the Include Issuer's SKI to enable this feature. If this feature is enabled, Issuer's SKI will be included in each proof file name irrespective of issuer holds single certificate or multiple certificates.

If the Include Issuer's SKI is disabled, each issuer's SKI will be included automatically in each proof file name where issuer holds more than one certificate.
Note:
- To take effect of these changes in the proof file name, OCSP proof list generator job should be executed after enabling or disabling the include issuer’s SKI feature.
- Make sure the OCSP proof list generator job is not running while enabling or disabling the Include Issuer’s SKI feature.
- If VR is configured with proof file name, then it has to be reconfigured based on the updated proof file name.
- If VR is configured with directory option, then there is no need to change any configuration as system will automatically pull all the data from specified directory.
Example of issuer holds only one certificate:

Example of issuer holds more than one certificate:

For example,

Consider VATESTCA and VATROOTCA are having issuer’s single certificate, whereas VATSUBCA contains issuer’s multiple certificates.

If the Issuer’s SKI include is disabled:

If the Issuer’s SKI include is enabled:
Click Update Configuration to save your changes.

Alternatively, click Revert Changes to cancel your changes.