Test Scenarios
Each Test Scenario can have one or more Test Cases associated with it that perform either positive or negative checks. Each Test Scenario can have its own trust anchors defined for detailed trust checking.
When a Test Scenario fails, a customisable failure report is sent to a defined list of operations staff. Each Test Scenario can have different staff identified.
When a scenario completes a summary report can be optionally sent to selected operational staff showing the minimum, average and maximum response delay statistics observed as well as a summary of the successful and failed tests observed during the period. At the end of day a summary report for all scenarios can optionally be sent to defined operational staff which details the main statistics for all scenarios.
The main screen shown is:
This lists all the defined Test Scenarios, their start time and stop time, the interval between tests and the status. These can be sorted in either Ascending or Descending order according to the criteria: Scenario ID, Scenario Name, Created At and Status.
A new test scenario is created by selecting the New button. The following configuration screen is shown:
The configuration items are as follows:
| Item | Description |
| Status |
A Test Scenario can be marked Active or Inactive. Inactive test scenarios are not processed this is useful when a particular Test Scenario is to be used on an occasional basis. |
| Scenario ID |
A System-defined unique identifier for this Test Scenario. |
| Scenario Name |
An operator-defined unique name that should be chosen to make it easy to understand what this Test Scenario does. |
| Scenario Description |
Use this field to describe the purpose of this Test Scenario and any other useful details to keep other operators informed. |
| OCSP Responder Address |
Configure the address of target OCSP responder to be monitored. The URL address can be checked using the Test button. |
| Response Timeout |
This value defines how many seconds OCSP Monitor waits for a response before assuming that there is a communication issue. The default value is 0 seconds and this means there is no timeout. 10 seconds is recommended when monitoring OCSP responders. |
| OCSP Freshness Threshold |
OCSP Monitor can optionally check the freshness of an OCSP response by comparing the difference between the "thisUpdate" time and "ProducedAt" time, with this value for this scenario. For example if you wish to check that an OCSP response is always issued within 3 hours of a CRL update then set this value to 3 x 60 = 180. The default value for OCSP Freshness Threshold is 0 minutes which tells the system not to perform a freshness check. |
| Response Clock tolerance |
When verifying OCSP responses, OCSP Monitor compares the time within the OCSP response with its local clock to ensure they are valid responses. Problems can occur if the OCSP client system time is behind the OCSP Server system time and so a tolerance value is useful. A value of 30 seconds is a recommended minimum. The default value is 0 seconds which tells the system not to use clock tolerance |
| OCSP Responder Requires Authentication |
Basic, Digest and NTLM aunthentication schemes are supported.
|
| Start Time | The time at which this Test Scenario runs. |
| Stop Time |
The time at which this Test Scenario stops. |
| Run Scenario after every |
Specifies how often in minutes this Test Scenario runs between the start and stop times. |
| Send Summary Report at Scenario Stop Time |
If enabled OCSP Monitor generates a Summary Report at the Test Scenario stop time. |
| Do not run scenario at week-ends |
If enabled OCSP Monitor does not run the scenario at week-ends. Currently week-ends are defined as Saturday and Sunday. |
| Include scenario result in Daily Summary Report |
If enabled the results of this Test Scenario are included in the daily summary report. |
| Trust Anchors |
Use this setting to identify the Trust Anchors to use when verifying OCSP responses. When OCSP Monitor receives an OCSP response it will attempt to verify it by building a certificate chain from the OCSP responder’s certificate to a Root CA certificate in the Trust Anchor list. If a chain can be built then the OCSP responder is authenticated and trusted. If not the OCSP response is not trusted. If the OCSP responder only sends its own certificate (and not the chain of certificates) then add intermediate CAs here to allow certificate path building. |
| Automatically trust any new Trust Authorities added to Trust Manager |
If this option is selected, any new trust authorities are automatically added to the 'Selected Trust Anchor' list. This avoids the need to have to manually assign new Trust Anchors to the profile. The use of this option should be carefully considered because it allows automatic change to existing Test Scenarios. |
| Test Cases |
Use this setting to define the Test Case(s) to be included within this Test Scenario. |
| Report Recipients |
This setting defines the system operators to whom scenario and warning reports are sent. |
The Test Scenarios can be searched using these options:
Enter the search criteria based on the Status, Test Scenario ID, Test Scenario Name.
If more than one search parameters is provided, these are combined using the AND operator and the results are presented accordingly.
The "_" character is used as a wildcard character
See also