SSL Certificate test failure

12 messages in this thread

list Scot Kreienkamp · Mon, 9 Nov 2015 21:18:16 +0000 ·

Hi there,

I am testing a site in Xymon that is testing OK, but throws an SSL error in the browser.  Wondering why that was, I looked at the certificate for the site... it doesn't match the domain name of the site that's serving it, which causes the browser to display an SSL error.  I was expecting Xymon to do the same.  Apparently Xymon doesn't check to make sure the certificate matches the URL.

Thanks!

Scot Kreienkamp | Senior Systems Engineer | La-Z-Boy Corporate
One La-Z-Boy Drive | Monroe, Michigan 48162  | * XXX-XXX-XXXX | | * 7349151444 | *  user-9678697f1438@xymon.invalid<mailto:%7BE-mail%7D>
www<http://www.la-z-boy.com/>.la-z-boy.com<http://www.la-z-boy.com/>; | facebook.<https://www.facebook.com/lazboy>com<https://www.facebook.com/lazboy>/<https://www.facebook.com/lazboy>lazboy<http://facebook.com/lazboy>; | twitter.com/lazboy<https://twitter.com/lazboy>; | youtube.com/<https://www.youtube.com/user/lazboy>lazboy<https://www.youtube.com/user/lazboy>;

[cid:lzbVertical_hres.jpg]


This message is intended only for the individual or entity to which it is addressed.  It may contain privileged, confidential information which is exempt from disclosure under applicable laws.  If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information.  If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.

Attachments (1)

attachment.jpg image/jpeg · 6.4 KB

list Mark Felder · Mon, 09 Nov 2015 15:24:40 -0600 ·

▸ quoted from Scot Kreienkamp


On Mon, Nov 9, 2015, at 15:18, Scot Kreienkamp wrote:

Hi there,

I am testing a site in Xymon that is testing OK, but throws an SSL error
in the browser.  Wondering why that was, I looked at the certificate for
the site... it doesn't match the domain name of the site that's serving
it, which causes the browser to display an SSL error.  I was expecting
Xymon to do the same.  Apparently Xymon doesn't check to make sure the
certificate matches the URL.

Xymon doesn't check the chain of trust or validate the hostname of the
certificate. It will gladly tell you if it expires, though :)

It would be nice to teach Xymon to validate the certificate more
thoroughly.


-- 
  Mark Felder
  user-db141d317836@xymon.invalid

list Markus Stoll · Tue, 10 Nov 2015 11:24:53 +0100 ·

Hi,

xymon would never be fast enough implementing checks against current ssl vulnerabilities

ssllabs does provide a webservice API for thorough SSL checking which can be accessed from xymon quite easily

Markus

Am 09.11.2015 um 22:24 schrieb Mark Felder <user-db141d317836@xymon.invalid>:

▸ quoted from Scot Kreienkamp

On Mon, Nov 9, 2015, at 15:18, Scot Kreienkamp wrote:

Hi there,

I am testing a site in Xymon that is testing OK, but throws an SSL error
in the browser.  Wondering why that was, I looked at the certificate for
the site... it doesn't match the domain name of the site that's serving
it, which causes the browser to display an SSL error.  I was expecting
Xymon to do the same.  Apparently Xymon doesn't check to make sure the
certificate matches the URL.

Xymon doesn't check the chain of trust or validate the hostname of the
certificate. It will gladly tell you if it expires, though :)

It would be nice to teach Xymon to validate the certificate more
thoroughly.


-- 
 Mark Felder
 user-db141d317836@xymon.invalid

--


Dr. Markus Stoll (Geschäftsführer)
user-137482a60f79@xymon.invalid
GPG: 8F8C 4A15 F3F4 F2A6 9D0E  5FCC 95D7 F6A7 662C 8C83
Peerio: 2Bc2qPRLJo8tgZXzH3sPTXg6HU5JsEthNdjrC8Y2F9kZ7z
miniLock: mUZgLgha4Ymex8cP15qXHjKYpt5g3dVzBo4sUEnqWjNbh

junidas GmbH, Aixheimer Str. 12, 70619 Stuttgart
Tel. +49 (711) 4599799-11, Fax +49 (711) 4599799-10
Geschäftsführer: Dr. Markus Stoll, Matthias Zepf
Amtsgericht Stuttgart, HRB 21939

list Japheth Cleaver · Tue, 10 Nov 2015 06:19:10 -0800 ·

▸ quoted from Markus Stoll

On Tue, November 10, 2015 2:24 am, Markus Stoll, junidas GmbH wrote:

Hi,

xymon would never be fast enough implementing checks against current ssl
vulnerabilities

ssllabs does provide a webservice API for thorough SSL checking which can
be accessed from xymon quite easily

Agreed. xymonnet isn't doing a deep examination of the response, and isn't
testing against a matrix of possibilities. A few simple things might be
able to be added as a simple "httpcipher=" sort of thing, but our 'http'
syntax is already rather scarily overloaded and I'm not sure it's quite
the best solution there.

▸ quoted from Markus Stoll

Am 09.11.2015 um 22:24 schrieb Mark Felder <user-db141d317836@xymon.invalid>:
On Mon, Nov 9, 2015, at 15:18, Scot Kreienkamp wrote:

Hi there,

I am testing a site in Xymon that is testing OK, but throws an SSL
error
in the browser.  Wondering why that was, I looked at the certificate
for
the site... it doesn't match the domain name of the site that's serving
it, which causes the browser to display an SSL error.  I was expecting
Xymon to do the same.  Apparently Xymon doesn't check to make sure the
certificate matches the URL.

Xymon doesn't check the chain of trust or validate the hostname of the
certificate. It will gladly tell you if it expires, though :)

It would be nice to teach Xymon to validate the certificate more
thoroughly.

I thought this had sounded familiar, and it turns out I had written a
small test for this back in the day.

I cleaned up a little of the bit-rot and updated the script at
https://wiki.xymonton.org/doku.php/monitors:sslname.sh

This should do an okay job at CN validation to solve the original problem,
and handles wildcards as well (although it's a bit too eager and will
accept wildcards for further subdomains, which is invalid). It should be
rewritten to perform just a single, mass 'xymondboard' query before it's
used at large sites or on heavily loaded xymond servers, however.

HTH,
-jc

list Mark Felder · Tue, 10 Nov 2015 08:27:49 -0600 ·

▸ quoted from Markus Stoll


On Tue, Nov 10, 2015, at 04:24, Markus Stoll, junidas GmbH wrote:

Hi,

xymon would never be fast enough implementing checks against current ssl
vulnerabilities

ssllabs does provide a webservice API for thorough SSL checking which can
be accessed from xymon quite easily

I don't think anybody asked for this functionality. We're simply asking
Xymon to be able to differentiate between a certificate with a valid
chain of trust and one that is broken or self-signed.


-- 
  Mark Felder
  user-db141d317836@xymon.invalid

list Scot Kreienkamp · Tue, 10 Nov 2015 14:42:16 +0000 ·

I don’t need it to do vulnerability scanning.  I just want to know the basics like if the SSL cert doesn’t match the URL that is serving it up.

Curl already has to have a lot of that built in as it balks at the cert mismatch, maybe it can be leveraged somehow.


Scot Kreienkamp  | Senior Systems Engineer | La-Z-Boy Corporate
One La-Z-Boy Drive | Monroe, Michigan 48162 |  Office: XXX-XXX-XXXX |  |  Mobile: XXXXXXXXXX | Email: user-9678697f1438@xymon.invalid

-----Original Message-----
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Mark
Felder
Sent: Tuesday, November 10, 2015 9:28 AM
To: Markus Stoll, junidas GmbH <user-137482a60f79@xymon.invalid>
Cc: xymon at xymon.com
Subject: Re: [Xymon] SSL Certificate test failure

▸ quoted from Markus Stoll



On Tue, Nov 10, 2015, at 04:24, Markus Stoll, junidas GmbH wrote:

Hi,

xymon would never be fast enough implementing checks against current
ssl
vulnerabilities

ssllabs does provide a webservice API for thorough SSL checking which can
be accessed from xymon quite easily

I don't think anybody asked for this functionality. We're simply asking
Xymon to be able to differentiate between a certificate with a valid
chain of trust and one that is broken or self-signed.


--
  Mark Felder
  user-db141d317836@xymon.invalid

This message is intended only for the individual or entity to which it is addressed.  It may contain privileged, confidential information which is exempt from disclosure under applicable laws.  If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information.  If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.

list Mark Felder · Tue, 10 Nov 2015 08:43:29 -0600 ·

▸ quoted from Japheth Cleaver


On Tue, Nov 10, 2015, at 08:19, J.C. Cleaver wrote:

On Tue, November 10, 2015 2:24 am, Markus Stoll, junidas GmbH wrote:

Hi,

xymon would never be fast enough implementing checks against current ssl
vulnerabilities

ssllabs does provide a webservice API for thorough SSL checking which can
be accessed from xymon quite easily

Agreed. xymonnet isn't doing a deep examination of the response, and
isn't
testing against a matrix of possibilities. A few simple things might be
able to be added as a simple "httpcipher=" sort of thing, but our 'http'
syntax is already rather scarily overloaded and I'm not sure it's quite
the best solution there.

Am 09.11.2015 um 22:24 schrieb Mark Felder <user-db141d317836@xymon.invalid>:
On Mon, Nov 9, 2015, at 15:18, Scot Kreienkamp wrote:

Hi there,

I am testing a site in Xymon that is testing OK, but throws an SSL
error
in the browser.  Wondering why that was, I looked at the certificate
for
the site... it doesn't match the domain name of the site that's serving
it, which causes the browser to display an SSL error.  I was expecting
Xymon to do the same.  Apparently Xymon doesn't check to make sure the
certificate matches the URL.

Xymon doesn't check the chain of trust or validate the hostname of the
certificate. It will gladly tell you if it expires, though :)

It would be nice to teach Xymon to validate the certificate more
thoroughly.

I thought this had sounded familiar, and it turns out I had written a
small test for this back in the day.

I cleaned up a little of the bit-rot and updated the script at
https://wiki.xymonton.org/doku.php/monitors:sslname.sh

This should do an okay job at CN validation to solve the original
problem,
and handles wildcards as well (although it's a bit too eager and will
accept wildcards for further subdomains, which is invalid). It should be
rewritten to perform just a single, mass 'xymondboard' query before it's
used at large sites or on heavily loaded xymond servers, however.

HTH,
-jc

You can just yank a couple subroutines out of testssl.sh and you'll be
in better shape. It will cover certificates that are unreadable,
revoked, chain incomplete, self signed, expired, not yet valid, etc.

https://github.com/drwetter/testssl.sh

-- 
  Mark Felder
  user-db141d317836@xymon.invalid

list Werner Maier · Tue, 10 Nov 2015 15:52:46 +0100 ·

▸ quoted from Scot Kreienkamp

xymon would never be fast enough implementing checks against current ssl
vulnerabilities

ssllabs does provide a webservice API for thorough SSL checking which can
be accessed from xymon quite easily

I don't think anybody asked for this functionality. We're simply asking
Xymon to be able to differentiate between a certificate with a valid
chain of trust and one that is broken or self-signed.

in general, if you are using SSL w/ official certificates, it will
not sufficient just to check if the chain would be ok and if the cert
is still valid (it's a start, but it won't be enough - at least soon).

Browsers are starting to deprecate some SSL-features, and they are talking
about to drop SHA1 signatures soon.

so you need to check at least:
- does the certificate contain the name
  * CN / single name certificates
  * SAN / multidomain name certficiates (SNI)
- is the cert still valid
- is the chain of trust ok
- which size is server key
- which signature algorithm is used
- [...]

I don't want to see this IN the xymonnet script, as the needs will change
faster than you want to upgrade your running xymon server.

Therefore I would recommend to do this via an external script and use
testssl.sh <https://github.com/drwetter/testssl.sh/>;

The benefit would be to be able to check not only a valid trust chain
but also more things that need to be checked if you work with SSL.

for example:
- all mentioned things above plus:
- supported ciphers
- offered encryption grades
- testing against known vulnerabilities

so one could check exactly what is needed - there are big differences in
production requirements vs. private webhosts.

regards,

Werner Maier
--
Dipl.-Ing. Univ. Werner Maier
http://www.maiers.de/

list John Thurston · Tue, 10 Nov 2015 08:25:48 -0900 ·

On 11/10/2015 5:19 AM, J.C. Cleaver wrote:
- snip -

▸ quoted from Mark Felder

Agreed. xymonnet isn't doing a deep examination of the response, and isn't
testing against a matrix of possibilities. A few simple things might be
able to be added as a simple "httpcipher=" sort of thing, but our 'http'
syntax is already rather scarily overloaded and I'm not sure it's quite
the best solution there.

I agree. Certificate verification and validation is a complex subject 
and shouldn't be crammed into the HTTP tests. It ought to be handled in 
an ext script which meets your business needs.
-- 
    Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska

list Henrik Størner · Tue, 10 Nov 2015 22:10:57 +0100 ·

Hi,

Den 10-11-2015 kl. 15:27 skrev Mark Felder:

▸ quoted from Werner Maier

[...] We're simply asking
Xymon to be able to differentiate between a certificate with a valid
chain of trust and one that is broken or self-signed.

You are correct that Xymon only checks the expiry-date of the certificate. This is - more or less - by design, since that is the most common problem with certificates: Your site works fine on Monday, and on Tuesday everything is down because the certificate has expired.

If your certificate is broken in the sense that the Common Name (ie the website name for which the certificate was issued) does not match your site, then *all* users will see that - so you figure it out pretty fast, usually before going live.

And name checking is not as simple as it seems. Lots of devices have self-signed certificates with meaningless names - tons of networking gear, application server admin consoles, intermediate proxy devices and so on. All of them can use self-signed certificates, or certificates issued by your own (company) CA. Xymon cannot validate them, because technically they are not trusted - you just want the TLS encryption to work, so you must live with the certificate.


Regards,
Henrik

list Josh Luthman · Tue, 10 Nov 2015 16:14:49 -0500 ·

I'd say if someone changed something and didn't check a particular name,
that having Xymon check a matching name would be very beneficial.

In simple terms, check https://foo.bar.com - if that would work on the
average user's browser, than be green.  If not, change the status.


Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

▸ quoted from Henrik Størner


On Tue, Nov 10, 2015 at 4:10 PM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> wrote:

Hi,

Den 10-11-2015 kl. 15:27 skrev Mark Felder:

[...] We're simply asking
Xymon to be able to differentiate between a certificate with a valid
chain of trust and one that is broken or self-signed.

You are correct that Xymon only checks the expiry-date of the certificate.
This is - more or less - by design, since that is the most common problem
with certificates: Your site works fine on Monday, and on Tuesday
everything is down because the certificate has expired.

If your certificate is broken in the sense that the Common Name (ie the
website name for which the certificate was issued) does not match your
site, then *all* users will see that - so you figure it out pretty fast,
usually before going live.

And name checking is not as simple as it seems. Lots of devices have
self-signed certificates with meaningless names - tons of networking gear,
application server admin consoles, intermediate proxy devices and so on.
All of them can use self-signed certificates, or certificates issued by
your own (company) CA. Xymon cannot validate them, because technically they
are not trusted - you just want the TLS encryption to work, so you must
live with the certificate.


Regards,
Henrik

list Glauber Ribeiro · Wed, 11 Nov 2015 20:23:02 +0000 ·

Yes. I view xymon's sslcert test as an expiration alert.

I've been tinkering with implementing a more thorough test via https://www.ssllabs.com/ssltest/ , but haven't done it yet. It should be doable, using their public APIs. Probably not the kind of thing you need to run for every server, but it would be nice to run it once a day, maybe, for important internet-facing servers.

g

▸ quoted from Mark Felder


-----Original Message-----
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Mark Felder
Sent: Monday, November 09, 2015 15:25
To: xymon at xymon.com
Subject: Re: [Xymon] SSL Certificate test failure


On Mon, Nov 9, 2015, at 15:18, Scot Kreienkamp wrote:

Hi there,

I am testing a site in Xymon that is testing OK, but throws an SSL error
in the browser.  Wondering why that was, I looked at the certificate for
the site... it doesn't match the domain name of the site that's serving
it, which causes the browser to display an SSL error.  I was expecting
Xymon to do the same.  Apparently Xymon doesn't check to make sure the
certificate matches the URL.

Xymon doesn't check the chain of trust or validate the hostname of the
certificate. It will gladly tell you if it expires, though :)

It would be nice to teach Xymon to validate the certificate more
thoroughly.


-- 
  Mark Felder
  user-db141d317836@xymon.invalid

SSL Certificate test failure 🔗 link

SSL Certificate test failure