Posts by drloss

This forum was archived to /woltlab and is now in read-only mode.

    The host listed there is "av-monitor02.mssp.local". I have restarted icinga2, and now when I run the Kickstart Wizard import on port 5665 I receive the message:

    I was unable to re-establish a connection to the Endpoint "av-monitor02.mssp.local" (av-monitor02.mssp.local:5665). When reconnecting to the configured Endpoint ( I get an error: CURL ERROR: Connection timed out after 3000 milliseconds Please re-check your Icinga 2 endpoint configuration (KickstartHelper.php:370)

    The messages for ports 80 and 443 remain the same, as expected. Under the Activity Log, I get the message:

    Unable to detect your deployment endpoint. I was looking for the first endpoint configured with an assigned API user in the "master" zone.

    The remainder of the error follows:

    1. #0 /usr/share/icingaweb2/modules/director/library/Director/Db.php(163): Icinga\Module\Director\Db->getDeploymentEndpointName()
    2. #1 /usr/share/icingaweb2/modules/director/library/Director/Web/Controller/ActionController.php(366): Icinga\Module\Director\Db->getDeploymentEndpoint()
    3. #2 /usr/share/icingaweb2/modules/director/application/controllers/ConfigController.php(133): Icinga\Module\Director\Web\Controller\ActionController->api()
    4. #3 /usr/share/icingaweb2/library/vendor/Zend/Controller/Action.php(507): Icinga\Module\Director\Controllers\ConfigController->activitiesAction()
    5. #4 /usr/share/php/Icinga/Web/Controller/Dispatcher.php(76): Zend_Controller_Action->dispatch('activitiesActio...')
    6. #5 /usr/share/icingaweb2/library/vendor/Zend/Controller/Front.php(937): Icinga\Web\Controller\Dispatcher->dispatch(Object(Icinga\Web\Request), Object(Icinga\Web\Response))
    7. #6 /usr/share/php/Icinga/Application/Web.php(389): Zend_Controller_Front->dispatch(Object(Icinga\Web\Request), Object(Icinga\Web\Response))
    8. #7 /usr/share/php/Icinga/Application/webrouter.php(109): Icinga\Application\Web->dispatch()
    9. #8 /usr/share/icingaweb2/public/index.php(4): require_once('/usr/share/php/...')
    10. #9 {main}

    I'm having a problem similar to what philt had. Using the Kickstart Wizard, when I leave the port at 5665 I get the message:

    CURL ERROR: Failed to connect to av-monitor02.mssp.local port 5665: Connection refused (RestApiClient.php:177)

    If I change the port to 80, I get:

    CURL ERROR: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (RestApiClient.php:177)

    and if I change the port to 443, I get:

    Parsing JSON result failed: Syntax error (RestApiResponse.php:88)

    This suggests to me that the module is installed correctly and that CURL is running as I'd expect it to. I'm not sure why the connection is refused on port 5665, as I've manually configured some hosts to monitor and am seeing them in icingaweb2 as expected, which seems to indicate that the API is running properly. I have a global-director zone setup as required. Suggestions, anyone?

    OK, I've redone my api.conf file using the apache2/nginx syntax, and the Windows clients are now connecting with the tls_protocolmin and cipher_list lines enabled. The values are:

    tls_protocolmin = "TLSv1.2"

    cipher_list = "ALL:!LOW:!MEDIUM:!NULL:!eNULL:!aNULL:!RC4:!SHA1:HIGH"

    Nessus is still reporting the same vulnerabilities, many of which
    look to me like they directly contradict what's set here. Since the
    Linux clients aren't showing similar vulnerabilities on Nessus, I'm
    inclined to believe that the vulnerabilities are coming from some other
    place in Windows than the Icinga2 configuration. I'm not a big Windows
    guy so I don't know just where to look there, but anyway I don't think
    it's likely something we can remedy through these settings.

    if you have alook in the code, the default value only uses high cyphers, either it is not working correctly, or nessus is reporting wrong things.

    Are there any other values that are acceptable for cipher_list than those in the default list? Nessus could certainly get things wrong, but we have to satisfy the auditors that what it reports is in fact incorrect.

    Oh, I should mention that when I don't set cipher_list (or comment the line out) the clients attach as expected. It's only when I try my attempted variant values that things fall apart. However, "icinga2 daemon -C" doesn't report any problems with my variant "cipher_list" values, which is why I thought I had a shot at it working.

    I hope this will be a bit more helpful. Here are my api.conf file (given a .txt extension so it would upload properly), and the results of "sslscan --no-failings localhost:5665" for four different conditions: the api.conf file as you see it with both the tls_protocolmin and cipher_list lines commented out, with one or the other of those lines activated, and with both of the lines activated. I notice that when the cipher_list line is active having the tls_protocolmin line active or inactive makes no difference in the result of the sslscan command.

    As before, any ideas on what I'm doing wrong here would be greatly appreciated.

    Hello all,

    We're fairly new to Icinga2 (we've used Nagios in the past, though). I've set up a server on a Debian v.8 VM, and moved some clients from our existing Nagios system to it (one Linux, five Windows). Our regular Nessus vulnerability scans are indicating that all the Windows systems have numerous SSL vulnerabilities (the Linux client is only showing two having to do with self-signed certs, which we don't care about): SSL Weak Cipher Suites Supported, SSL Version 2 and 3 Protocol Detection, SSL Medium Strength Cipher Suites Supported, SSL 64-bit Block Size Cipher Suites Supported (SWEET32), SSL Certificate Signed Using Weak Hashing Algorithm, SSL RC4 Cipher Suites Supported (Bar Mitzvah), and SSL Certificate Chain Contains RSA Keys Less Than 2048 bits.

    In reading through the documentation I figured I could address all this by editing the api.conf file in the servers /etc/icinga2/features-available/ directory. It's current setting is:

    When I uncomment the tls_protocolmin line, sslscan gives me a long list of failed ciphers , but also these lines:

    Prefered Server Cipher(s):

    TLSv1 256 bits AES256-SHA

    The certificate shows:

    SSL Certificate:

    Version: 2


    Signature Algorithm: sha256WithRSAEncryption


    RSA Public Key: (4096 bit)

    When I uncomment the cipher_list line, I get a long list of failed or rejected ciphers (although the failed ciphers include others beyond just the ones in the list) but no Prefered Server Cipher(s).

    When I uncomment both, all ciphers fail with no Prefered Server Cipher(s):

    When I try to run the Icinga2SetupAgent on the Windows clients with either line uncommented, I get the response:

    critical/cli: Invalid ticket.

    critical/cli: Failed to request certificate from Icinga 2 master.

    I'm not sure if this is a problem with the Windows client or with the server settings. I could really use some guidance and pointing in the right direction. Thanks!