Hi,
If I remember correctly: If the http test is red because Xymon cannot
connect to the server on port 443, then Xymon will never retrieve the SSL
certificate (no connection = no SSL data). This will cause the sslcert
status to be purple, because it cannot be updated.
Med venlig hilsen / Best regards
*Henrik Juul Størner*
Senior IT Arkitekt - IT-sikkerhed
*Fra:* Josh Luthman <user-4c45a83f15cb@xymon.invalid>
*Sendt:* 20. marts 2025 21:56
*Til:* Jaime Kikpole <user-fb200a07d7dc@xymon.invalid>
*Cc:* Xymon mailinglist <xymon@xymon.com>; Jeremy Laidman <
user-0608abae5e7c@xymon.invalid>
*Emne:* [Xymon] Re: SSL stuck on purple
OBS: Denne e-mail er *ikke* fra en Danske Spil-afsender! Brug kun
links eller vedhæftede filer, hvis du mener, de er OK.
Why is the http test red?
On Thu, Mar 20, 2025 at 4:46 PM Jaime Kikpole <
user-fb200a07d7dc@xymon.invalid> wrote:
From hosts.cfg, with redactions between < and >:
<IP address> <hostname>.ichabodcrane.org # route:10.5.0.1 https://
<hostname>.ichabodcrane.org noconn
The ghosts report shows no clients.
The hostname definitely resolves (tested on the VM with the xymon
server) to the IP address. The purple alert is in a column labeled
"sslcert" and the red is in "http". The data in the page with the details
about sslcert shows the correct dates and a green alert. The data in the
page with the http details shows the message "SSL error" after the
https://.... URL. When viewing that URL, it redirects path on the
same server. This hasn't given me trouble over the last several years and
the only thing that changed on the monitored system is that its IP address
changed at the VM hosting service.
*Jaime Kikpole*
*Director of Technology*
*Ichabod Crane Central School District*
(XXX) XXX-XXXX, x5425
On Thu, Mar 20, 2025 at 4:33 PM Josh Luthman <
user-4c45a83f15cb@xymon.invalid> wrote:
The IP in the first column is used in the event the name can't be
resolved (or # testip is appended).
The purple test means there is no report for the test (for half an
hour I think?) In this case you're testing from the Xymon Server so it is
responsible for doing the test.
Are you certain the name of the host matches? Are there any ghosts?
Are you looking at the "sslcert" column? What does your hosts.cfg
line look like - does it have an https url?
On Thu, Mar 20, 2025 at 3:38 PM Jaime Kikpole via Xymon <
xymon@xymon.com> wrote:
Thanks for the ideas. That gave me more to try and I made some
progress, but not much.
I discovered that hosts.cfg still had the old IP address. I updated
that, but there was no change. I restarted the xymon server process and
there was no change. I did a "xymon 127.0.0.1 drop <IP address>" and there
was no change. Would you suggest a "xymon 127.0.0.1 drop <FQDN> http" or
something like that?
I see what I would expect when using "curl https://<FQDN>"; and the
logs only show one interesting line within 2025, so I suspect that it
all comes down to that one hosts.cfg line with the old IP address.
When I used "grep <server> * | grep 2025 | less", I see the following
line and then everything else was from notifications.log about emailing my
department's outages notification email address.
history.log:2025-03-18 14:54:12.042214 Will not update
/usr/local/www/xymon/data/hist/server,fqdn,redacted.sslcert - color
unchanged (purple)
What do you think? Should I just deal with the loss of historical
data and drop the host by FQDN?
*Jaime Kikpole*
*Director of Technology*
*Ichabod Crane Central School District*
(XXX) XXX-XXXX, x5425
On Wed, Mar 19, 2025 at 7:49 PM Jeremy Laidman <user-0608abae5e7c@xymon.invalid>
wrote:
Hi Jaime <Hi%20Jaime%0d%0dOn%20Thu,%20>
<Hi%20Jaime%0d%0dOn%20Thu,%20>
<Hi%20Jaime%0d%0dOn%20Thu,%20>
<Hi%20Jaime%0d%0dOn%20Thu,%20>
On Thu, <Hi%20Jaime%0d%0dOn%20Thu,%20>20 Mar 2025 at 02:11, Jaime
Kikpole via Xymon <xymon@xymon.com> wrote:
I have a Xymon install that was monitoring (among other things) an
HTTPS site. That site moved to a new IP and while I did update the public
DNS records it was a few days (or maybe two weeks?) before I remembered to
update the internal DNS records. By then, Xymon was reporting red for
HTTPS and purple for SSL.
I've corrected the DNS records and the VM running Xymon is resolving
it correctly, but now it is still showing the same red and purple alerts.
Every now and then, they'll switch to green for a little while and then
back to red and purple. I'm not sure why.
Xymon's web interface shows that the certificate is valid for more
than 2 months. So that isn't it. I've restarted the Xymon server process
and even the whole OS, but this issue remains.
Any ideas on what I could check?
First, review the content of the https status page. There may be
non-obvious clues here. There's a difference between "connection refused"
and "connection timed out" and this can lead you in different directions to
identify the cause. For example, if you have a content check configured
("cont=..." in hosts.cfg), which is failing due to new content on the new
webserver, this will be explained on the status page.
Second, I would check that your Xymon server can actually connect to
the new IP address on port 443. I usually use "telnet <IP> <port>" and see
if it connects, gets a connection refused, or a timeout, but netcat/ncat/nc
works too. For an HTTPS website (as distinct from HTTP) I sometimes use an
openssl command to see if the TLS/SSL interaction works, which tells me
that there's no issue on the webserver itself, something like "openssl
s_client -connect <IP>:<port> </dev/null". Even simpler, run curl or wget
to fetch a webpage, but if you have a proxy set anywhere, this may give you
an invalid result.
Thirdly, I would check the xymonnet.log file for any indications of
problems, which might suggest a cause. Having xymonnet in debug mode might
help (adding "--debug" into the CMD line of the [xymonnet] block in
tasks.cfg). Alternatively, you could run xymonnet directly yourself, and
look at the output. Something like this: xymoncmd xymonnet --no-update
--debug <hostname>
Good luck with finding the problem.
Cheers
Jeremy