Welcome to docs.opsview.com

Opsview 4.6.3 introduced the capability of a more secure method of communication between the Opsview Agent and its Unix clients. Previous versions were limited to using relatively weak ADH based ciphers, but now it's possible to use SSL certificates, which offer not only a stronger encryption method, but also authentication, so both the client and server know that they are indeed talking to each other, and not a man-in-the-middle.

Whatever method of communication you choose, both the Opsview Agent server and clients (check_nrpe) must be told to use the same method: ciphers directly, or SSL certificates. The Opsview Agent server configuration is in /usr/local/nagios/etc/nrpe.cfg (on Windows in C:/Program Files/Opsview Agent/opsview.ini), and the clients are configured by command line parameters.

Note that send2slaves does not copy nrpe.cfg to slaves. You'll have to add any new configuration parameters in it to the slaves manually.

Host Attributes

We have added default parameters to every service check that comes with Opsview. If you check their definitions, you'll see two new host attributes — NRPE_CIPHERS and NRPE_CERTIFICATES — discussed below. Note that you'll have to add these attributes yourself if you're upgrading from an older version of Opsview.


In nrpe.cfg, ciphers (on Windows in opsview.ini it is allowed_ciphers) indicates the cipher list to use. Because there is no authentication involved in using a cipher directly like this, only ADH ciphers can be used here. The list follows the standard OpenSSL convention of colon separated names, where the program attempts to use each cipher starting from the left, and falls back to the next one if unsuccessful. Similarly, the -y parameter to check_nrpe lists ciphers that the client should attempt to use, which, of course, must contain at least one of the ciphers that the server is using.

Each check_nrpe based service check is configured to accept the NRPE_CIPHERS host attribute. Make sure the value of this attribute is the same or contains at least one of the ciphers configured in nrpe.cfg.

SSL Certificates

In nrpe.cfg, cert_file, privatekey, and cacert_file (opsview.ini uses certificate, certificate_key and ca) are file paths to a certificate PEM file, private key PEM file, and CA certificate PEM file. These parameters correspond to the -C, -k, -r parameters of the check_nrpe plugin.

The generation and use of the actual certificates is the user's responsibility, but because it can be a daunting task to create certificates for those who don't already know how, we'll try to explain a basic procedure below, with working examples that can be copy-and-pasted to produce a working system.

SSL Certificate Example

Both the NRPE daemon and each monitored host need a certificate. The generation of a certificate involves a private key, which must be kept secret. The certificates must be signed by a Certificate Authority (CA), such as Verisign or Comodo, but we shall make our own CA instead. The CA can be created on any server, but any keys we make must be signed by it, before they are copied to the host they'll be used on.

Certificate Authority

This guide is for Debian and Ubuntu systems

Create a CA:

cd /usr/local/etc
mkdir -p demoCA/{newcerts,private}
touch demoCA/index.txt
echo 01 > demoCA/serial
/usr/lib/ssl/misc/CA.pl -newcert

The exact location of CA.pl may differ, depending where OpenSSL installed it. You'll be prompted for a passphrase and details of the new CA certificate.

mv newcert.pem demoCA/cacert.pem
mv newkey.pem demoCA/private/cakey.pem

You now have your Certificate Authority.

Host Certificates

To create a new certificate that is to be signed by the CA, a Certificate Signing Request (CSR) must be created:

/usr/lib/ssl/misc/CA.pl -newreq

This creates a newreq.pem file, which is the CSR itself. Now to have the CA sign the request:

/usr/lib/ssl/misc/CA.pl -sign

Be aware that the Common Name (CN) of the certificate must match the Primary Hostname/IP of the host you'll be installing the certificate on, as it appears in Opsview. It is not possible to use wildcards in the CN for check_nrpe. Remember to remove the passphrase.

You can delete the newreq.pem file, since it is no longer needed. You should be left with newcert.pem and newkey.pem, your certificate and private key files, respectively. You'll want to remove the passphrase from the private key, unless you want the Opsview Agent or check_nrpe to hang every time it starts, waiting for you to enter it:

openssl rsa -in newkey.pem -out newkey.pem

Generate a certificate-key pair like this for each host that you'll be monitoring or running the Opsview Agent on, and move them into a safe place on the host, for example, /usr/local/etc/certs/. Copy also the cacert.pem file from the CA.

On hosts that will be running the Opsview Agent, that is, hosts that will be monitored, edit nrpe.cfg, uncomment and change the cert_file, privatekey, and cacert_file options to point to their respective files in /usr/local/etc/certs/. Comment out the ciphers option, and restart the agent:

rc.opsview-agent restart

On hosts that will be doing the monitoring, ie. the master or slave hosts, each check_nrpe based service check is configured to accept the NRPE_CERTIFICATES attribute. The values for this attribute refer to the certificate files on the master/slave, and not the host being monitored, as is the case usually with host attributes. The first value, Arg1, is the path to the certificate on the master/slave. In our example, this would be /usr/local/etc/certs/newcert.pem. Arg2 is the path to the private key: /usr/local/etc/certs/newkey.pem. Arg3 is the CA certificate: /usr/local/etc/certs/cacert.pem.