[Xymon] Intermediate cert monitoring

Ralph Mitchell ralphmitchell at gmail.com
Sat Feb 28 20:06:21 CET 2015


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 <jlaidman at rebel-it.com.au>
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" <jlaidman at rebel-it.com.au>
> 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" <ralphmitchell at gmail.com>
>> 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:
>> >>>
>> >>> _______________________________________________
>> >>> Xymon mailing list
>> >>> Xymon at xymon.com
>> >>> http://lists.xymon.com/mailman/listinfo/xymon
>> >>>
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: Eli <eliap09 at yahoo.com>
>> >>> To: Mark Felder <feld at feld.me>
>> >>> 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 <feld at feld.me> 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...
>> >>> _______________________________________________
>> >>> Xymon mailing list
>> >>> Xymon at xymon.com
>> >>> http://lists.xymon.com/mailman/listinfo/xymon
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> Xymon mailing list
>> >> Xymon at xymon.com
>> >> http://lists.xymon.com/mailman/listinfo/xymon
>> >>
>>
>
> _______________________________________________
> 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/20150228/e0bbf68c/attachment.html>


More information about the Xymon mailing list