[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [hobbit] SSL cert testing to match common name with host/URL?
- To: hobbit (at) hswn.dk
- Subject: Re: [hobbit] SSL cert testing to match common name with host/URL?
- From: Ralph Mitchell <ralphmitchell (at) gmail.com>
- Date: Tue, 15 Jun 2010 19:02:44 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=a0l2DNfbOSFLCnmK+CFUeyKPU33YaMeUop+RwJPAiDU=; b=VJaUS+W66ZVe1jj9z4Gh7NHP7FN5mUEPRRxU69Igm7TPQyGo6ZidYnQfCT3cLZDb37 fYYsmGByGlDUw/8/6LCeDw8aLK1tIFMrtOszKFtoac1enOhHI8valYj3wT1h3x2H1Wlv vovjAeuT0sZTIyCi/3cJ1QQcSrYyftJ9ygT2c=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=FeIFCDm54U2Y9vOJu07/uzRVRcOnqJlNUVTvKsmxq+0b6V1zlcfOPHTMKS56Rx4iUj e2b4juzcKPwT8hCwBOEU+cgVnqWewwfC8ibIH1wA/tV1/47qz0F1UMzhsKRMDJhEaiWj CUD+vBkT5E52CC6oyShUZvOs4KlW6XgzDbH/I=
- References: <7EA6A25EC6360A488E0EBB5F3F21A0DC2B952FCA (at) mail-sd4.ad.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.com
returns:
* 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