LibWWW - Verifying SSL Certificate domains

Author

Verifying SSL Certificate domains

Bill Moseley

2007-09-29, 7:20 pm

Hi all,

I'm wondering that the correct or recommended procedure is to verify
that a certificate matches the request domain.

If I tell SSLeay where my CA certs are stored then the certs are
verified:

$ HTTPS_CA_DIR=/etc/ssl/certs HEAD https://gmail.google.com

Where a self-signed cert (where I don't have the CA cert) will
generate an error:

500 SSL negotiation failed: error:1407E086:SSL routines:SSL2_SET_CERTIFICATE:certificat
e verify failed

Now, my question is how to catch certs that don't match the domain.
For example going to https://gmail.com will report that the cert is
for mail.google.com.

Is there a method other then parsing the CN out of Client-SSL-Cert-Subject
header available that I should be using? Of is parsing that header the
recommended approach?

use LWP::UserAgent;
use HTTP::Request;

$ENV{HTTPS_CA_DIR} = '/etc/ssl/certs';

my $req = HTTP::Request->new( GET => 'https://gmail.com' );
my $res = LWP::UserAgent->new->simple_request( $req );
print $res->headers_as_string;

Connection: Close
Date: Sat, 29 Sep 2007 18:30:13 GMT
Location: https://mail.google.com/mail/
Server: gws
Content-Length: 226
Content-Type: text/html
Content-Type: text/html;charset=utf-8
Client-Date: Sat, 29 Sep 2007 18:30:13 GMT
Client-Peer: 64.233.171.83:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
Client-SSL-Cert-Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
Client-SSL-Cipher: AES256-SHA
Client-SSL-Warning: Peer certificate not verified
Set-Cookie: PREF=ID=0bde9752f3ab3357:TM=1191090613:L
M=1191090613:S=wn3s5qf6X18GZ3gs; expires=Mon, 28-Sep-2009 18:30:13 GMT; path=/; domain=.google.com
Title: 301 Moved

--
Bill Moseley
moseley@hank.org

Bill Moseley

2007-10-01, 7:25 pm

On Sat, Sep 29, 2007 at 11:48:58AM -0700, Bill Moseley wrote:
> Is there a method other then parsing the CN out of Client-SSL-Cert-Subject
> header available that I should be using?

Working backwards from LWP::Protocol::https ;)

Yes, according to man LWP:

my $host = $req->uri->host;
$req->header( 'If-SSL-Cert-Subject', '\QCN=' . $host );

Seems to do the trick.

--
Bill Moseley
moseley@hank.org

Bill Moseley

2007-10-01, 10:19 pm

To continue this exciting debate:

On Mon, Oct 01, 2007 at 07:17:17AM -0700, Bill Moseley wrote:
> Yes, according to man LWP:
>
> my $host = $req->uri->host;
> $req->header( 'If-SSL-Cert-Subject', '\QCN=' . $host );

Oops, that doesn't look right. Perhaps:

> $req->header( 'If-SSL-Cert-Subject', qr/\QCN=$host/ );

Hum, but for possible wild card certificates might need something
like:

my $host = $request->uri->host;
my $match_string = "CN=(?:\Q$host\E";
$match_string .= "|\Q$host\E" if $host =~ s/[^.]+(\.[^.]{2,})/*$1/;
$match_string .= ')';

And a note for the archives:

I was wondering how to get SSLeay to use the default compiled-in CA
directory when using LWP/Crypt::SSLeay, which is done by calling
SSL_CTX_set_default_verify_paths() in SSLeay.

It might be handy to use the defaults in situation where you don't
know where the CA certs are installed in a deployed application.

So the question is how to enable searching the defaults?
Looking at SSLeay.xs I noted that

SSL_CTX_set_default_verify_paths(ctx);

was always called, but verify is only enabled if HTTPS_CA_DIR or
HTTPS_CA_FILE is set.

So the effect of setting $ENV{HTTPS_CA_DIR} to *any* value
will enable verification and thus searching in the default verify
paths.

That is, if the CA certs are in, say, /etc/ssl/certs and that happens
to be the default path then

$ENV{HTTPS_CA_DIR} = '/etc/ssl/certs';

and

$ENV{HTTPS_CA_DIR} = '/whatever';

probably work the same.

--
Bill Moseley
moseley@hank.org

Sponsored Links