Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Network Node Manager i Software10.30

Administer > Configure NNMi to Support Public Key Infrastructure User Authentication > Certificate Validation (CRL and OCSP)

Certificate Validation (CRL and OCSP)

NNMi supports two methods of checking for revoked certificates:

Certificate Revocation List (CRL) - A CRL is a list of revoked certificates that is downloaded from the Certificate Authority (CA).
Online Certificate Status Protocol (OCSP) - OCSP is a protocol for checking revocation of a single certificate interactively using an online service called an OCSP responder.

CRL and OCSP validation are two different ways to achieve the same result: denying access to any user whose certificate is revoked. In a web browser, OCSP is generally considered superior because a browser is usually dealing with many different Certificate Authorities (CAs), and having to download an entire CRL to check one web site is inefficient.

However, for a server that is often dealing with many clients, all with certificates from the same CA, CRL checking can be significantly more efficient because the CRL can be downloaded once per day instead of needing to check OCSP for every connection.

When both OCSP and CRL are enabled,NNMi, by default, queries CRL first. CRL checking is performed first because the CRL usually has a much longer lifetime and, therefore, is more resilient to network outages. OCSP performs frequent requests so, if the network or the OCSP responder is down, users will be unable to log on. NNMi attempts to obtain a valid CRL first to use in continuing operations in the case the network or OCSP responder goes down.

In addition, CRL comparison is much faster than OCSP; that is, matching a certificate against a list that exists on the disk is faster than querying a separate server over the network to validate each certificate. So if a certificate has been signed by a trusted entity, and is not expired, the CRL is queried to see if the certificate has been revoked. If it has been revoked, there is no need to check OCSP. But if the certificate is still valid after checking the CRL, OCSP will also be queried to ensure that the certificate has not been revoked recently (and an updated CRL listing the certificate is not yet available).

When both OCSP and CRL are enabled, NNMi supports the following:

NNMi queries CRL first, followed by OCSP (this is the default behavior).
If the CRL is not available, OCSP is used as a backup.
If OCSP is not available, CRL is used as a backup.

General Configuration for Certificate Validation Protocols

You can configure how NNMi checks for revoked certificates. For example, you can configure the order in which protocols are used, and whether all the protocols are used.

NNMi uses the nms-auth-config.xml file to configure such settings.

Configuring Protocol Order

By default, NNMi performs CRL checking, and then OCSP checking.

To configure the order in which the certificate validation protocols check for revoked certificates, do the following:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux:$NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <revocation> section of the file (find the <revocation> tag), search for the line that begins with the following text:
```
<ordering>
```
Do one of the following:
- To specify that CRL checking is to be used first, followed by OCSP, edit the line to read as follows:
```
<ordering>CRL OCSP</ordering>
```
- To specify that OCSP checking is to be used first, followed by CRL, edit the line to read as follows:
```
<ordering>OCSP CRL</ordering>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Configuring Protocol Requests

You can configure NNMi to do either of the following with regard to protocol requests:

Check all certificate validation protocols for each certificate
Check the protocol list in the preferred order and stop when a valid response is received

To configure protocol requests, do the following:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <revocation> section of the file (find the <revocation> tag), search for the line that begins with the following text:
```
<mode>
```
Do one of the following:
- To have NNMi check all protocols for each certificate, edit the line to read as follows:
```
<mode>CHECK_ALL</mode>
```
- To have NNMi check the protocol list in the preferred order and stop when a valid response is received, edit the line to read as follows:
```
<mode>FIRST_SUCCESS</mode>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Validating Certificates Using CRLs

NNMi uses CRLs to properly deny access to clients using a certificate that is no longer trusted.

Note During authentication, when a certificate's serial number is found in a CRL, NNMi does not accept that certificate and authentication fails.

NNMi checks CRLs by default when using X.509 authentication mode; however, you can specify a CRL by editing the nms-auth-config.xml file, as described in the following sections.

Note NNMi stores the CRL configuration in the following location:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml
Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml

There is also a default version of the configuration file, which can be used for reference purposes to view new available options. The default configuration file is stored in the following location:

Windows: %NnmInstallDir%\newconfig\HPOvNnmAS\nmsas\conf\nms-auth-config.xml
Linux: $NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf/nms-auth-config.xml

Enabling and Disabling CRL Checking

By default, NNMi enables CRL checking.

To configure CRL checking, follow these steps:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<enabled>
```
Do one of the following:
- To enable CRL checking, change the line to read as follows:
```
<enabled>true</enabled>
```
- To disable CRL checking, change the line to read as follows:
```
<enabled>false</enabled>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Changing the CRL Enforcement Mode

By default, NNMi is set to enforce CRLs.

To change the product’s enforcement of CRLs, follow these steps:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<mode>
```
Change the line to read as one of the following:
```
<mode><value></mode>
```
where <value> is one of the following:
- ENFORCE: Enforce CRLs where specified in the certificates
- ATTEMPT: Check CRLs but allow access if the CRL is not available
- REQUIRE: Require and enforce CRLs in certificates
Note In REQUIRE mode, authentication will fail if there is no CRL specified or available for a user's certificate.
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Changing How Often a CRL Should be Refreshed

To configure how often NNMi refreshes the CRL, follow these steps:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<refreshPeriod>
```
Change the line to read as follows:
```
<refreshPeriod><value></refreshPeriod>
```
where <value> is the integer number of hours or days (the smallest value is 1h).

For example, enter 24h for 24 hours; enter 2d for 2 days.
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Changing the Maximum Idle Time for a CRL

You can configure how long NNMi keeps a CRL after the CRL has been idle (has not been used or accessed).

To change the maximum idle time for a CRL, follow these steps:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<maxIdleTime>
```
Change the line to read as follows:
```
<maxIdleTime><value></maxIdleTime>
```
where <value> is the integer number of hours or days (the smallest value is 1h).

For example, enter 24h for 24 hours; enter 2d for 2 days.
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

CRL Expiration Warnings

When CRL checking is enabled, if a CRL expires, users might be locked out of the NNMi console. To help avoid unwanted lockouts, NNMi provides health warning messages to alert administrators that a CRL has either expired or will be expiring soon.

The expired CRL warning (Major severity) occurs when one or more CRLs have expired.

The expiring CRL warning (Minor severity) occurs when one or more CRLs has less than 1/6th of its valid period remaining. For example, if a CRL is valid for 24 hours, NNMi displays a warning if the CRL expires in fewer than four hours.

Configure the refresh period such that CRLs are always kept fresh. A properly configured refresh period ensures that, if the CRL server is unavailable for a time, there is a sufficient valid period remaining for the downloaded CRLs. In this way, NNMi can continue normal operation until the CRL server is available. In this example, a refresh period of eight hours might be appropriate.

Changing the Location for a CRL

By default, NNMi downloads CRLs from the HTTP location embedded in the certificate. If this location is not accessible to the NNMi management server, the administrator can obtain the required CRLs some other way and configure NNMi to load those CRLs from the local file system.

Note Only CRLs signed by the certificate issuer are considered when evaluating the certificate.

To configure NNMi to load CRLs from the local file system, do the following:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the following text block:
Insert a line after the --> tag, and enter the following, based on your operating system:

Windows: <location>file:///C:/CRLS/<crlname>.crl</location>

Linux: <location>file:///var/opt/OV/shared/nnm/certificates/<crlname>.crl </location>
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Validating Certificates Using Online Certificate Status Protocol (OCSP)

NNMi supports Online Certificate Status Protocol (OCSP) to check for revoked certificates interactively.

PKI user authentication uses OCSP to verify the revocation status of a certificate by querying an OCSP responder. An OCSP responder provides immediate and accurate revocation information on specific certificates as follows:

An OCSP client submits a certificate status request to an OCSP responder.
The OCSP client suspends acceptance of the certificate in question until the OCSP responder provides a digitally signed response.
The OCSP responder indicates the status of the certificate by returning one of the following values:
- Good (pass; user is granted access)
- Revoked (fail; user is denied access)
- Unknown (fail; user is denied access)

Because the OCSP responder is queried for every certificate, whereas the CRL is downloaded periodically (for example, once per day), OCSP responses might be more up-to-date than corresponding CRLs.

Note NNMi stores the OCSP configuration in the following location:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml
Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml

A default version of the configuration file can be used for reference purposes to view new available options. The default configuration file is stored in the following location:

Windows: %NnmInstallDir%\newconfig\HPOvNnmAS\nmsas\conf\nms-auth-config.xml
Linux: $NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf/nms-auth-config.xml

Enabling and Disabling OCSP Checking

To configure OCSP checking, follow these steps:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <ocsp> section of the file (find the <ocsp> tag), search for the line that begins with the following text:
```
<enabled>
```
Do one of the following:
- To enable OCSP checking, change the line to read as follows:
```
<enabled>true</enabled>
```
- To disable OCSP checking, change the line to read as follows:
```
<enabled>false</enabled>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Changing the OCSP Enforcement Mode

By default, NNMi is set to enforce OCSP.

To change the product’s enforcement of OCSP, follow these steps:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <ocsp> section of the file (find the <ocsp> tag), search for the line that begins with the following text:
```
<mode>
```
Change the line to read as one of the following:
```
<mode><value></mode>
```
where <value> is one of the following:
- ENFORCE: Enforce OCSP where specified in the certificates
- ATTEMPT: Check OCSP but allow access if OCSP is not available
- REQUIRE: Require and enforce OCSP in certificates
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Enabling Nonce

For added security (to avoid replay attacks), an OCSP requester can add a nonce to the certificate validation request. A nonce is a random number, attached to each request, that alters the encryption. When the nonce feature is enabled, the OCSP responder computes an appropriate response using the nonce value.

Note Using a nonce puts more load on the OCSP responder because it cannot precalculate or cache responses. Some OCSP responders may not accept requests with a nonce.

Note The nonce feature is disabled by default.

To enable the OCSP nonce feature, follow these steps:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <ocsp> section of the file (find the <ocsp> tag), search for the line that begins with the following text:
```
<nonce>
```
Do one of the following:
- To enable the nonce feature, change the line to read as follows:
```
<nonce>true</nonce>
```
- To disable the nonce feature (and use a general request), change the line to read as follows:
```
<nonce>false</nonce>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Specifying the URL of the OCSP Responder

Optionally, you can specify the URL of the OCSP responder as follows:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <ocsp> section of the file (find the <ocsp> tag), search for the line that begins with the following text:
```
<responder>
```
Edit the line to read as follows:
```
<responder><URL></responder>
```
where <URL> is the URL associated with the OCSP responder.
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Note The OCSP URL must use the HTTP protocol.

If there is no OCSP URL specified in the nms-auth-config.xml file, NNMi attempts to obtain an OCSP responder from the certificate itself.
If there is no OCSP responder specified in the certificate, NNMi uses the <mode> setting to determine what action to take:
- If the mode is ENFORCE or ATTEMPT, NNMi passes the OCSP validation step for this certificate.
- If the mode is REQUIRE, NNMi rejects the certificate.

Send Help Center feedback