Drifting off-topic just a little here - the client should be able to
validate at least the top-level CA cert via a 3rd-party source. I.e. NOT
solely from the cert chain handed out by the server. In RHEL 5, 6 & 7 that
source is the CA cert bundle under /etc/pki/tls/certs. If you can validate
the chain all the way back to one of those certs, you should be able to
trust the server.
At work I have a couple of RPMs that drop our internal CA certs and all the
current DoD certs into /etc/pki/tls/certs, then rebuild the hash links.
I'm not adding to the original ca-bundle. That allows me to do this:
curl --capath /etc/pki/tls/certs .......
https://internal.server.mine/xxx
and get a validated connection. Drifting back on-topic again, it isn't
hard to fake Xymon's http report from a shell script using a command-line
similar to the above. I'm doing it in a couple of cases where Xymon
doesn't correctly handle going out via a proxy. Curl will tell you if it
validates the cert chain, but ONLY for the server running the script. I
don't think there's any way to tell if some client elsewhere has the proper
intermediate certs installed, other than by running the script there too.
Ralph Mitchell
On Sat, Feb 28, 2015 at 6:43 AM, Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
wrote:
Yep. From the openssl s_client man page:
" The s_client utility is a test tool and is designed to continue the
handshake after any certificate verification errors. As a result it will
accept any certificate chain (trusted or not) sent by the peer. None test
applications should not do this as it makes them vulnerable to a MITM
attack. This behaviour can be changed by with the -verify_return_error
option: any verify errors are then returned aborting the handshake."
Xymonnet probably operates in the same mode. It has to do so if it has no
trusted certificate store.
J
On 28/02/2015 10:37 PM, "Jeremy Laidman" <user-71895fb2e44c@xymon.invalid>
wrote:
I'm no expert but I think this has to do with a "certificate chain". In
theory, the TLS server only needs to give it's own certificate to the TLS
client, or it can optionally send other (intermediate) certificates in the
chain, to save the client having to go find them. In practice, the client
isn't able to locate the intermediate certificates and so the server
generally provides all certificates in the chain as a "certificate bundle".
Configuring a web server with only the server's land certificate works
just fine if there are no intermediate certificates, such as when the
server certificate was issued by a root CA because the client already has
the for CA in its trusted certificate store.. But if it was issued by an
intermediate CA then the intermediate certificate will not be in the store.
The web server should be configured with all certificates in the chain,
but sometimes it's not. In such cases it may be possible for libssl (and
hence Xymon) to obtain the intermediate certificates and validate them, but
not a browser.
Actually, I suspect that libssl doesn't validate a trust chain anyway,
because unlike a browser, libssl probably has no certificate store. So
libssl only checks the reasonableness of a certificate and it's expiry date.
J
On 28/02/2015 2:24 PM, "Ralph Mitchell" <user-00a5e44c48c0@xymon.invalid>
wrote:
Having the Xymon server validate the intermediate certificates won't
help if they're missing off the server that owns the certificate. The
Xymon server would have the certs installed and always get a match.
Where are the intermediate certs missing? Does the web server even
start properly if it can't validate its own cert?
Ralph Mitchell
On Thu, Feb 26, 2015 at 1:51 PM, Eli via Xymon <xymon at xymon.com>
wrote:
---------- Forwarded message ----------
From: Eli <user-eeb3a3c6c848@xymon.invalid>
To: Mark Felder <user-db141d317836@xymon.invalid>
Cc: xymon at xymon.com
Date: Thu, 26 Feb 2015 11:50:43 -0700
Subject: Re: [Xymon] Intermediate cert monitoring
The issue was missing or not installed. As you know newer browsers
doesn't have problem but the older one show cert error when the
intermediate cert missing. We have bunch of cert so some time engineers
forget to install the intermediate cert and caused issue.
Mark Felder <user-db141d317836@xymon.invalid> wrote:
What was the exact problem with the intermediate certificate? What
should be monitored? Maybe we can come up with a way to add additional
monitoring parameters to Xymon's SSL monitoring if we know exactly
what
should be monitored.
My first guess is expiration, but I'm not sure if you can sign a cert
if
it expires after your intermediate is due to expire. The only other
thought is if the chain was incomplete...