Adam Thorn,

Thank you! The SNI tag worked (the command line returned a lot of stuff, nothing of value - looked the same with a working and non-working webserver.

Tim Williams, That is good to know. I will look for the new ps client.

Thank you all

David

From: David Hickenbottom Sent: Wednesday, July 31, 2019 8:12 AM To: xymon at xymon.com Subject: RE: I need help troubleshooting a xymon issue

The second problem below caused purple alerts. Changing the order fixed it and have not seen purple alerts since.

From: David Hickenbottom Sent: Wednesday, July 31, 2019 8:01 AM To: xymon at xymon.com<mailto:xymon at xymon.com> Subject: I need help troubleshooting a xymon issue

Hi,

First of all Thank You! This is a fantastic product. I have two problems. The first is with regards to SSL monitoring. I have a group of 20 or so webservers. Half monitor the SSL certificate correctly, the others act like they do not see one. [cid:image001.png at 01D547B6.EA494CF0]

It looks good from every way I can look at it, but Xymon is not happy! Is there a way for me to see what is going on?

This second problem, although not a big issue, some of our servers report back an extremely large client file - the active connections list is so long the complete file does not get ingested. I have tried changing the max lines parameter, but that had not made any difference. On some of them I changed to order of the report so the data that is typically after the ports section is ingested and the ports data is dropped off. Losing part of the ports data does not appear to cause a problem and I cannot tell by the current monitors I am even missing data. (it would be interesting to see how many connections - listening, established and waiting - are reported).

Best regards, David Hickenbottom

You did not specify what OS and client this pertains to. On the assumption it is Windows using the powershell client, the second issue was fixed after about version 2.28 by a client-local keyword of PORTS:listenonly which limits the ports information to only the listening ports; all of the 'established' info is discarded. This cuts the size of the data file down a lot.

We are also dealing with the first issue of invalid SSL connections on the HTTP tests for some servers. My observation of the underlying ciphers on the affected servers is that they were recently security-tightened to only include "forward-secrecy" ciphers, and I think that the Xymon server can't handshake using only those. Successful handshakes are using ECDHE-RSA-AES256-GCM-SHA384, while failing have ECDHE_RSA_WITH_AES_256_CBC_SHA384 (only the CBC variant).

Tim Williams VCU Computing Center

On Wed, Jul 31, 2019 at 11:22 AM Adam Thorn <alt36 at cam.ac.uk> wrote:

On 31/07/2019 13:00, David Hickenbottom wrote:

...

Hi,

First of all Thank You! This is a fantastic product. I have two problems. The first is with regards to SSL monitoring. I have a group of 20 or so webservers. Half monitor the SSL certificate correctly, the others act like they do not see one.

It looks good from every way I can look at it, but Xymon is not happy! Is there a way for me to see what is going on? Bit of a guess here: do you need to use SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) for the hosts where the test fails? Assuming this is the built in sslcert test performed by xymonnet, you can run it yourself with e.g.

/usr/lib/xymon/server/bin/xymonnet pr26.imbills.com --noping --no-update

where --no-update will print the test output to stdout rather than reporting to your xymon server. (NB that'll run all the xymonnet tests, not just sslcert) If you need SNI, you can add --sni=on to that command as a test, and/or add "sni" to the relevant line in hosts.cfg.

You can also add --debug to the above xymonnet command, which might or might not give you information about the failure.

Adam

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon