Link Search Menu Expand Document

CRL OCSP Monitor - Test Case Configuration


Start the Management console by double clicking the desktop icon: img

Or by starting the Krestfield CRL OCSP Monitor Console from the programs list

The following screen will be shown:

img

The first step will be to create a new test case:


Click img to add a new Test Case

img

Enter a name for the test case and select whether this test case is to monitor a CRL Distribution Point or an OCSP URL.

Click OK. Note: The name must be unique to ensure each test case is distinguishable from any others.

The new test case will appear in the left hand pane:

img

The settings tab will now be available to populate. For CRL test cases this tab is called CRL Settings and for OCSP testcases, it is called OCSP Settings

On this settings tab enter either the CRL URI or OCSP URL

The CRL end point will be either a file, http URL or ldap address and must take the following form:

  • http://

  • ldap://

  • file://

Note that for a local ldap address (such as in a Microsoft domain environment) the ldap address will start ldap:/// (i.e. three leading slashes) to indicate this is hosted on a local domain controller. Similarly, to reference a local file, the file location will start file:/// - again three leading slashes to indicate this is a local file

Examples of a valid CRL URIs are:

http://pki.myorg.com/crl/myca.crl

file:///d:/crl/myorg.crl

file://\\crlserver\crl\ca1.crl

ldap:///CN=Org%20CA%201,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=MyOrg,Dc=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

E.g.

img


The OCSP URL will take the form:

  • http(s)://

An examples of a valid OCSP URL is:

http://pki.myorg.com/ocsp

E.g.

img


If the machine where the monitor is running can only access these end points via a proxy (for example, if you are monitoring external public facing end points from within a corporate network), click Use Proxy (you will need to enter the proxy server details later – see below)

By default the Http Request method is POST. If the OCSP server being targeted does not support the posting of OCSP requests, select GET



CRL Test Case Settings


CRL Settings Tab

The following tests can be performed for a CRL test case:

img


CRL must have a lifetime of

A CRL has an expiry data associated with it (defined by the Next Update field). A CRL whose Next Update time is after the current time is deemed expired, and clients will reject the CRL (and revocation checking will fail)

To test that the CRL lifetime is of a certain period, check the CRL must have a lifetime of check box and set the options of More Than/Less Than and the time period required

Test cases can be used to ensure that a CRL is being generated in good time (before they are due to expire) but also that CRLs are adhering to any policy (e.g. to verify that a maximum CRL lifetime is not being exceeded)

It is recommended to set this option to ensure that CRLs do not expire unexpectedly. Generally, a new CRL should be generated and published well before the previous CRL expires (such that their lifetimes overlap) in order to provide ample time to deal with any CRL generation issues


CRL must be downloaded within

If you wish to also check the CRL is downloaded within a certain time, check the CRL must be downloaded within check box and specify the number of milliseconds. If it takes longer than this period for the CRL to be downloaded the test case will fail

This test is useful to verify the availability of the CRL, network latency and responsiveness of the hosting server


CRL size must be

To be informed when a CRL exceeds a maximum size, or to ensure it is the minimum expected size, check the CRL size must be check box and set the More Than or Less Than option and size in Kilobytes. The test will fail if the CRL file size is not within these limits


Verify CRL Signature

CRLs are usually signed by the Certificate Authority that issued them. This signature can be verified by checking the Verify CRL Signature check box

This option also requires that the issuing certificate (i.e. the CA certificate) is specified. Click Choose… to navigate to the CA certificate

This test will confirm that the CRL was indeed signed by the correct issuer CA and will highlight if a CRL is incorrectly signed, or the signature is somehow corrupt, or an attempt has being made to sign the CRL with a different CA certificate


Certificate to Check

If a certificate is specified here, its status will then be checked against the CRL. This option can be used to confirm that a revoked certificate is included in the CRL (or that a known valid certificate is not)

To enable this check the Check Specific Certificate Status check box and click Choose… to navigate to the required certificate file



OCSP Test Case Settings


OCSP Settings Tab

For an OCSP Test Case, a certificate (whose status is to be checked against the server), must be specified. This can be any certificate that would have been issued from the CA associated with the OCSP server being monitored

img

Click imgand navigate to the chosen certificate file. Click OK

If the issuer of the certificate is not recognised (this can happen if the issuer certificate is not configured in the local windows store) you will be prompted to specify the intermediate as well:

img

Navigate to the correct issuer certificate file and click OK

Next, choose if you wish a NONCE (Number Once) to be sent in the request

img

If this is configured, the CRL OCSP Monitor will send a random number in the request and verify that the same number is present in the response. This forces the OCSP Server to generate a fresh response (and not return a cached version)

Next select the tests that you want to be carried out

img

Expected Result

This is the response you expect to be received from the OCSP server when returning the status of the certificate specified in the previous step

You can choose from the following options:

  • SUCCESS – GOOD: The certificate is known and has not been revoked

  • SUCCESS – REVOKED: The certificate is known but has been revoked

  • SUCCESS – UNKNOWN: The certificate is not known

  • ERROR - TRY LATER: The OCSP server is busy or some other issue is preventing it from responding at this time

  • ERROR - SIGNATURE REQUIRED: There is a requirement for the request to have been signed and it has not been. Note: the current version does not support OCSP request signing however, this is planned for future releases

  • ERROR - UNAUTHORIZED: The requestor is not authorised to obtain a response from this server. This can happen if the request is signed by an untrusted or unknown certificate

The following can be configured but are unlikely to be returned in any environment other than development:

  • ERROR - INTERNAL ERROR: The OCSP server has experienced an internal error

  • ERROR - MALFORMED REQUEST: The OCSP request was not formatted correctly or is corrupt

As long as the responder returns the response specified, the test case will pass

E.g. If in the previous step you specified a revoked certificate you would set the status to SUCCESS – REVOKED and as long as the OCSP returned this response, the test case will succeed


Responses must be received within

If you wish to also check the responses are returned within a certain time, check the Response must be received within check box and specify the number of milliseconds. If it takes longer than this period for the response to be returned the test case will fail

This test is useful to test the network latency and responsiveness of the hosting server


Response must have a lifetime of

To check that the OCSP response has a certain lifetime (that is the period from the current time to the next update time) then check the Response must have a lifetime of check box and specify the time. This may be used to confirm that responses are being produced with short lifetimes (e.g. five minutes), or are producing responses with the expected next update values


Fail if signer certificate expiring in less than

OCSP Responses are signed. If the certificate used to sign the response has expired, the response will be rejected by the client (and revocation checking will fail)

In order to check the lifetime of the signing certificate, check the Fail if signer certificate expiring in less than check box and specify the number of days

For example, if you set this to 30 days and the signer certificate is expiring in 29 days, the test case will fail and an alert can be sent indicating that a renewal should take place

If the OCSP signing certificate is auto-renewed (as can be configured with the Microsoft OCSP Responder) set this time to the renewal period as configured on the certificate template, to ensure the auto-renewal is operating correctly

Note that if the responder does not return any response the test case will fail anyway


Test Frequency Tab

This is the frequency that the test case will run. The range is from 1 second to a number of days

Usually a number of minutes (e.g. 5 minutes) is sufficient for monitoring OCSP servers. CRLs may not require as regular monitoring but these intervals are dependant on the purpose of the test case

img

If you do not wish the tests to run at weekends check the Not at Weekends button


Test Failure Actions Tab

This section defines what to do should a test case fail

img


The options are:


  • Send an Email

If you wish certain individuals/teams to be emailed should the test case fail, check the Send an Email checkbox

The Email Settings must also be set for this to operate. See the section below on Email Server Settings for details on how to configure this

You can then specify the recipients by clicking the Recipients button. The following dialog will appear:

img

Use the Add and Remove buttons to add or remove email addresses to the available list of recipients. Note: the list of available email addresses is global, in that other test cases will also see the same list of email addresses

Click OK to save the email addresses

Normal behaviour is that an email will be sent when a test case initially fails and not for subsequent failures. However, if you wish an email to be sent at every test failure, check the Send for Every Failure check box


  • Run an Application/Script

To execute an application or script when a test case fails, check this option. Click the App Settings… button and browse to the application or script. Add any script parameters as required and click OK

img

For example, if you wish to run a powershell script you would set Path to application/script as:

powershell.exe

and for application parameters, set the script name and additional parameters. e.g.

c:\scripts\alert.ps1 %TESTCASE% %URL% %ERROR%


In this example, these parameters could be accessed in alert.ps1 as follows:

$testCaseName = $args[0]

$testCaseUrl = $args[1]

$testCaseError = $args[2]

This allows for advanced reporting and alerting capabilities such as raising tickets in ServiceNow

Note: The account running the CRL OCSP Monitor service must have permissions to execute the application/script chosen. If this is tied to specific users/groups you may wish to run the service under a specific account or an account in the same group. See Running the Service under a different account below


  • Log to Windows Event Log

To log an event to the Windows Event Log, check this option. This is useful for alerting systems that may already be able to monitor the Event Log

Choose Event Settings… to set the Event ID and message that will appear in the log entry

img

Note that the failure reason will automatically be included in the event log entry


Once all settings have been configured click the Apply button to save


Results Tab

Results from the last 24 hours are displayed in this tab

See Viewing Logs for more information