[Xymon] Http Status Column and Https

[Richard Jones]

Okay so using a site I know was returning everything correctly in the
previous installation, the http task reports the following:

red https://something.co.uk/ - Bad Request
HTTP/1.1 400 Bad Request
Server: cloudflare-nginx
Date: Wed, 08 Nov 2017 10:01:34 GMT
Content-Type: text/html
Content-Length: 275
Connection: close
CF-RAY: -
Seconds: 0.002278000

Looking at the access logs I can see Xymon hitting the server(s), that
looks somethign like this

something.co.uk:443 1.2.3.4 - - [08/Nov/2017:06:40:05 +0000] "GET /
HTTP/1.0" 400 0 "-" "-"

If I perform a curl to the URL https://something.co.uk I get back what I'm
expecting, if I perform the curl as something.co.uk:443 I receive the 400
error with the message... The plain HTTP request was sent to HTTPS port.
This is expected I believe, note that the affected site are all set up to
redirect from 80 to 443 and there are no issues with the sites that I have
noticed.

Running xymonnet in the console doesn't really return much...

echo 5.4.3.2 something.co.uk # https://something.co.uk |
(HOSTSCFG=/dev/stdin /usr/local/xymon/server/bin/xymonnet --debug
--no-update --noping --dns=ip )

Returns:

5.4.3.2 something.co.uk

Any ideas?







On 7 November 2017 at 21:27, Jeremy Laidman <jlaidman at rebel-it.com.au>
wrote:

> Rich
>
> All of the SSL checks are enabled by default, so yes, probably related.
> However check the command-line parameters for xymonnet (in tasks.cfg) to
> ensure you don't have "--no-ssl" or something like that. I suspect the
> "400" response code indicates a problem that is also preventing Xymon from
> processing the certificate.
>
> Check the web servers' logs to see if they are reporting a fault from the
> Xymon probe, which might give clues to the cause of the problem.
>
> Can you provide the exact message that Xymon shows? It may indicate which
> part of the code is reporting the error, and hence the problem that's
> triggering it. And what version of Xymon did you upgrade to?
>
> It might be worth running xymonnet with the "--debug" option, to see if it
> shows more detail in the xymonnet.log file. You can do some reasonably
> painless diagnostics by running xymonnet from the command-line, like so:
>
> echo "1.2.3.4 someurl.com # https://someurl.com COMMENT:somecomment" | (
> HOSTSCFG=/dev/stdin /usr/lib/xymon/server/bin/xymonnet --debug
> --no-update --noping --dns=ip )
>
> This will show you everything xymonnet is doing, but it will only test as
> per the details in the "echo" command, and it will report its result to you
> rather than updating the status in Xymon.
>
> Note that, even though --dns=ip is set here, xymonnet still performs a DNS
> lookup against the hostname part of the URL to determine where to connect.
> The debug output will show this. You can force it to connect to a different
> IP address by using a URL such as https://someurl.com=1.2.3.99.
>
> J
>
> On 8 November 2017 at 04:16, Richard Jones <rich at corporationpop.co.uk>
> wrote:
>
>> Hi all,
>>
>> Have finally got around to upgrading our Xymon installation, mostly all
>> good (still some plugins and extensions to add in), however I'm seeing a
>> strange issue where the http test is returning a HTTP/1.1 400 Bad Request
>> for all sites using https. This used to work in our previous (admittedly
>> VERY out-of date) instance. Any ideas?
>>
>> Hosts.cfg looks something like this for the affected rows:
>>
>> 1.2.3.4   someurl.com  # https://someurl.com COMMENT:somecomment
>>
>> While I'm at it, I can't recall how to get the ssl certificate test to
>> work and show the expiry dates, is this related?
>>
>> Cheers, Rich
>>
>> _______________________________________________
>> Xymon mailing list
>> Xymon at xymon.com
>> http://lists.xymon.com/mailman/listinfo/xymon
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20171108/e56dc31c/attachment.html>