Notification Configuration

Path outages prevent the generation of excess notifications by identifying network paths where failures may cause multiple nodes to appear offline.

Configuring a path outage lets you suppress notifications for nodes that appear to be down due to a failure in the network path between the nodes and Horizon. For example, if a WAN link fails, all nodes at the remote site served by the WAN link will appear to be down. Because you get a notification that the router on the far end of the WAN link is not responding, you don’t need notifications for all devices that sit behind that router.

See Use Path Outages to Suppress Notifications for information on enabling this feature. Path outage checking is disabled by default.

You can configure a path outage for an individual node by setting a parent on the node in a requisition or by doing the following:

The JavaMail notification strategies check two independent things about a mail server’s TLS certificate: whether the certificate chain is trusted, and whether the certificate covers the host name that Horizon connects to. A certificate can pass one check and fail the other, and the two are controlled by separate properties. Both are raw mail. properties, set in javamail-configuration.properties alongside the org.opennms.core.utils. settings.

A trusted certificate issued for a name other than the configured mail host fails with No subject alternative names matching …​, or No name matching …​ found. This tends to come up where the mail host is configured by IP address while its certificate lists only DNS names. Setting mail.smtp.ssl.checkserveridentity=false skips the check.

Setting mail.smtp.ssl.trust, including to , does not suppress this check. A self-signed certificate that worked with mail.smtp.ssl.trust= alone may also need mail.smtp.ssl.checkserveridentity=false.

A certificate that is not trusted at all fails earlier and differently, with PKIX path building failed. That is a trust problem rather than an identity one, and mail.smtp.ssl.checkserveridentity has no bearing on it; either add the issuing certificate to the JVM truststore or name the host in mail.smtp.ssl.trust.

Both checks exist to detect a connection that has been intercepted or misdirected, so where the certificate itself can be corrected that is usually the better option. Enabling mail.debug=true logs the SMTP dialogue, which is the most direct way to see which check is failing.