SSL cert testing to match common name with host/URL?
I've been adding testing of https URLs into our system and noticed that while the expiration date checking is nice, Xymon doesn't seem to be checking testing the common name at all for validity (in the manner that a browser might).
I've been examining contest.c and bbtest-net.c/h looking for the best way of exposing this data back up to the status determination near line ~1800 of bbtest-net.c, but can't seem to properly add things to the testitem struct to get things passed properly.
E.g.: contest.c:649: item->certcommonname = strdup(X509_NAME_get_text_by_NID(X509_get_subject_name(peercert), NID_commonName, NULL, 0));
Has anyone tried to solve this problem before? Or, perchance, have a patch?
Regards,
Japheth Cleaver jcleaver at soe.sony.com
On Tue, Jun 15, 2010 at 2:55 PM, Cleaver, Japheth <jcleaver at soe.sony.com>wrote:
I've been adding testing of https URLs into our system and noticed that while the expiration date checking is nice, Xymon doesn't seem to be checking testing the common name at all for validity (in the manner that a browser might).
I've been examining contest.c and bbtest-net.c/h looking for the best way of exposing this data back up to the status determination near line ~1800 of bbtest-net.c, but can't seem to properly add things to the testitem struct to get things passed properly.
E.g.: contest.c:649: item->certcommonname = strdup(X509_NAME_get_text_by_NID(X509_get_subject_name(peercert), NID_commonName, NULL, 0));
Has anyone tried to solve this problem before? Or, perchance, have a patch?
I don't recall anyone else mentioning this as a problem. A fairly easy workaround would be to roll your own check. For example, this:
curl -v https://mail.google.comreturns:
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google Inc;CN=mail.google.com * start date: 2009-12-18 00:00:00 GMT * expire date: 2011-12-18 23:59:59 GMT * common name: mail.google.com (matched) * issuer: C=ZA; O=Thawte Consulting (Pty) Ltd.; CN=Thawte SGC CA * SSL certificate verify ok. > GET / HTTP/1.1
among other things. It wouldn't be too hard to grep out "common name" from that and go from there. If there's anything hinky about the cert, curl will return an error. If you use the "-k" option, it'll ignore the error and give you the page along with info about what was wrong.
Ralph Mitchell
-----Original Message----- From: Ralph Mitchell [mailto:ralphmitchell at gmail.com] Sent: Tuesday, June 15, 2010 4:03 PM To: hobbit at hswn.dk Subject: Re: [hobbit] SSL cert testing to match common name with host/URL?
I don't recall anyone else mentioning this as a problem. A fairly easy workaround would be to roll your own check. For example, this:
curl -v https://mail.google.comreturns:
* Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=mail.google.com * start date: 2009-12-18 00:00:00 GMT * expire date: 2011-12-18 23:59:59 GMT * common name: mail.google.com (matched) * issuer: C=ZA; O=Thawte Consulting (Pty) Ltd.; CN=Thawte SGC CA * SSL certificate verify ok. > GET / HTTP/1.1among other things. It wouldn't be too hard to grep out "common name" from that and go from there. If there's anything hinky about the cert, curl will return an error. If you use the "-k" option, it'll ignore the error and give you the page along with info about what was wrong.
Ralph Mitchell
Yeah, I was resigned to setting up a new test in the short-term, at least.
Still, I think merits being a configurable option for the built-in SSL check. I think a lot more people would be interested in the matching of the common name than, say, encryption bit level, since most user clients will throw a warning if there's a mismatch. =/
Regards,
JC
On Tuesday, 15 June 2010 19:55:24 Cleaver, Japheth wrote:
I've been adding testing of https URLs into our system and noticed that while the expiration date checking is nice, Xymon doesn't seem to be checking testing the common name at all for validity (in the manner that a browser might).
But, surely this isn't something you need to monitor? I mean, if you update a cert, you'll check it yourself (also to ensure that your client software has the relevant CA cert etc. etc.).
Regards, Buchan
On Wed, Jun 16, 2010 at 4:05 AM, Buchan Milne <bgmilne at staff.telkomsa.net>wrote:
On Tuesday, 15 June 2010 19:55:24 Cleaver, Japheth wrote:
I've been adding testing of https URLs into our system and noticed that while the expiration date checking is nice, Xymon doesn't seem to be checking testing the common name at all for validity (in the manner that a browser might).
But, surely this isn't something you need to monitor? I mean, if you update a cert, you'll check it yourself (also to ensure that your client software has the relevant CA cert etc. etc.).
I was once asked to set up cert monitoring to check the expiry date every hour. The reason given was "in case we restore the server and bring back an old cert"... The company estimated they'd lose $50k per hour if they couldn't take bookings.
Ralph Mitchell
-----Original Message----- From: Buchan Milne [mailto:bgmilne at staff.telkomsa.net] Sent: Wednesday, June 16, 2010 1:05 AM To: hobbit at hswn.dk Cc: Cleaver, Japheth Subject: Re: [hobbit] SSL cert testing to match common name with host/URL?
On Tuesday, 15 June 2010 19:55:24 Cleaver, Japheth wrote:
I've been adding testing of https URLs into our system and noticed that while the expiration date checking is nice, Xymon doesn't seem to be checking testing the common name at all for validity (in the manner that a browser might).
But, surely this isn't something you need to monitor? I mean, if you update a cert, you'll check it yourself (also to ensure that your client software has the relevant CA cert etc. etc.).
Regards, Buchan
O how I wish that were the case :). Actually, part of this is discovery. We have a lot of secure sites using different certs and with virtualhosts forwarding through load-balancers and HTTPS-HTTP or HTTP-HTTPS gateways. I'd like for Xymon to be able to catch unintended consequences when a virtual host suddenly ends up giving out the right content (that's checked for elsewhere) but the wrong credentials.
Like I said, it's not a huge requirement since I can build the check externally; just more of a nice-to-have if the data is available in the context of the built-in check.
Regards, -jc
participants (3)
-
bgmilne＠staff.telkomsa.net
-
jcleaver＠soe.sony.com
-
ralphmitchell＠gmail.com