Hi all,

We just upgraded to 1.8.3 from 1.7 (the last one) and it broke our Client
Certificate Verification. Nothing changed except the version of Pound. As far
as I know the only SSL related change in Pound was the CRL stuff (I might be
totally wrong on that). So I don't know what the problem could be.

I am using the s_client feature in openssl to do the testing. When I don't pass
a certificate I get the following from either version of Pound:

31620:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1052:SSL alert number 40
31620:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:226:

Which is what I would expect. When I pass the certificate, I get the following
from Pound 1.8.3:

31612:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown
ca:s3_pkt.c:1052:SSL alert number 48
31612:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:226:

With 1.7 it connects just fine. Our CAList is a single file containing all our
our certificates to verify against (there are only three in the file).

I don't think it matters but our OpenSSL version is: OpenSSL 0.9.7d 17 Mar 2004

I tried other versions of Pound as well. 1.7, 1.8 and 1.8.1 all work as I would
expect. 1.8.2 and 1.8.3 both seem to not work (haven't tried 1.8.4 yet as the
pid file name change isn't compatible with out current init script).

I appreciate any help anyone can provide, thanks.

John D.

PS From what I can tell, OpenSSL error 40 means you aren't passing a
certificate when one is required, and error 48 means you aren't passing an
allowed certificate.

On Tue, 10 May 2005 19:28:40 -0700 "John D" <jwdavid(at)ibizvision.com>
wrote:[...]

The only change that might be relevant here is the CRL checking
introduced in 1.8.2. Here is a recipe on how to disable it in 1.8.4.

After you run configure edit the generated config.h. Find a line that
looks like:

#define HAVE_X509_STORE_SET_FLAGS 1

Change the value to 0. Run make and you'll have a Pound without the CRL
stuff. Try it and see what it says.

As to why it happens: I suggest you have a look at your CRL stuff - it
might be that the client certificate you use is black-listed. You may
also want to look at the HTTPSHeader modes (you don't tell us what you
use) - it may just be that you need 3 rather than 1.

To the list at large: can anybody confirm that 1.8.4 works OK with
client certificates?[...]

Thanks for the suggestions.

The relivant parts of our config are:

HTTPSHeaders 2 ""
CAlist /root/certs.txt 1

We have an RPM of pound so the config change would be difficult, however, I
wrote a patch that would remove the CRL stuff from pound.c and this seems to
have fixed our problem.

Is there something else that has to be configured for CRL to work? There is no
mention in the docs about this (that I could find). We are using self signed
certs and certs signed by our CA (we are phasing out our self signed certs).
Our signed certs contain the url to the CRL. And the URL is valid.

Is there something I am missing? We want to be able to use the CRL stuff for
our Signed certs.

Thanks,

John D.

********** Original Email *********
** To:   pound(at)apsis.ch
** From: Robert Segall <roseg(at)apsis.ch>
** Date: Tue, 17 May 2005 13:09:02 +0200
**********

On Tue, 10 May 2005 19:28:40 -0700 "John D" <jwdavid(at)ibizvision.com>
wrote:[...]

The only change that might be relevant here is the CRL checking
introduced in 1.8.2. Here is a recipe on how to disable it in 1.8.4.

After you run configure edit the generated config.h. Find a line that
looks like:

#define HAVE_X509_STORE_SET_FLAGS 1

Change the value to 0. Run make and you'll have a Pound without the CRL
stuff. Try it and see what it says.

As to why it happens: I suggest you have a look at your CRL stuff - it
might be that the client certificate you use is black-listed. You may
also want to look at the HTTPSHeader modes (you don't tell us what you
use) - it may just be that you need 3 rather than 1.

To the list at large: can anybody confirm that 1.8.4 works OK with
client certificates?[...]

On Tue, 17 May 2005 08:09:03 -0700 "John D" <jwdavid(at)ibizvision.com>
wrote:[...]

That means Pound asks for a certificate and refuses to proceed unless
presented with a certificate it can verify. At least for testing
purposes a value of 3 might be better.
[...]

The "1" might be a problem. If you have a certificate chain the
verification will fail. A value between 5 and 9 is a much safer bet.

Also make sure your certs.txt contains the CA root certificates, not the
client certificates.

In any case this will fail with self-signed client certificates - by
definition Pound is unable to verify those.
[...]

Please read the relevant sections of the OpenSSL documentation - it
explains how to deal with the CRL stuff. Free tip: a URL in the
certificate is not enough.
[...]

Let us know how it works.[...]

Howdy,

"HTTPSHeaders 2" Is the configuration I want as I want pound to refuse the
connection if there isn't a Client Cert. This works exactly as I would expect.

"CAlist /root/certs.txt 1" You are probably correct that a higher number would
be better, however, I know for a fact that all my certs are only 1 level deep
as we only trust certs we issue.

Without the CRL stuff, self signed certs work as long as the cert is in the
CAlist. This may not be the way it is supposed to work but it does work this
way. This actually make sence since a self signed certificate would be trusted
by its self (hence the name self signed). In any case, we are moving away from
this and only have a few self signed certs left.

I am not sure what sections you would consider "relevant" in the OpenSSL docs.
I was not able to find any help on their site regarding this, only some very
vague refferences (using Google to search their site for
"X509_V_FLAG_CRL_CHECK" returns no results). I ultimatly found what I was
missing in the Net::SSLeay Perl module documentation. I am not sure that
pointing people to the OpenSSL documentation for help is the best course of
action, generally speaking. I would assume that you want more then developers
to be able to use Pound, in which case, stuff like this needs to be documented
in the Pound docs.

Therefore I would recommend the following change to the Man page for Pound:
---------- OLD ----------
Set the list of "trusted" CA's for this server. The CAcert_file is a file
containing a sequence of CA certificates (PEM format). The names of the define
CAs will be sent to the client on connection).
---------- NEW ----------
Set the list of "trusted" CA's for this server. The CAcert_file is a file
containing a sequence of CA certificates (PEM format) and revocation lists
(CRLs in PEM format). The names of the defined CA certificates will be sent to
the client on connection. Note: You will need to have both the certificate and
CRL for each "trusted" CA.
-------------------------

That was the solution to the problem. CRL's need to be in the same file as the
trusted root certificates. I will admit that this makes sence, however it
really wasn't obvious. I figured that the URL in the cert wouldn't be enough,
but I was lost as to where to put them where OpenSSL could find them.

As I was looking through the Pound source (pound.c in particular) once I found
the solution, it appears to me that the CRL stuff may not be in the correct
place. I don't think it will cause a problem where it is, but shouldn't the CRL
Check Flag only be set if the CAlist is defined? (Basically just move the code
up a few lines inside the "if(ssl_CAlst != NULL) {".)

Thanks,

John D.

********** Original Email *********
** To:   pound(at)apsis.ch
** From: Robert Segall <roseg(at)apsis.ch>
** Date: Tue, 17 May 2005 18:30:58 +0200
**********

On Tue, 17 May 2005 08:09:03 -0700 "John D" <jwdavid(at)ibizvision.com>
wrote:[...]

That means Pound asks for a certificate and refuses to proceed unless
presented with a certificate it can verify. At least for testing
purposes a value of 3 might be better.
[...]

The "1" might be a problem. If you have a certificate chain the
verification will fail. A value between 5 and 9 is a much safer bet.

Also make sure your certs.txt contains the CA root certificates, not the
client certificates.

In any case this will fail with self-signed client certificates - by
definition Pound is unable to verify those.
[...]

Please read the relevant sections of the OpenSSL documentation - it
explains how to deal with the CRL stuff. Free tip: a URL in the
certificate is not enough.
[...]

Let us know how it works.[...]

On Wed, 18 May 2005 08:33:52 -0700 "John D" <jwdavid(at)ibizvision.com>
wrote:[...]

Thanks - that goes into the man page.
[...]

True, but it doesn't hurt if they are there (in the past OpenSSL had its
own locations, so enabling the check can't hurt).

In any case, I feel that your remark re. possible confusion is correct,
so I just uploaded 1.8.5, which has a separate CRLlist configuration
directive. Enjoy.[...]

Howdy,

Thanks for the quick response. I was just looking at the new code, and I might
be wrong on this, but I don't think it will work this way. If what I read in
the OpenSSL docs is correct, SSL_CTX_load_verify_locations is used for both the
Certificates and the CRLs. I don't think they can be slit up.

I think the way the code is written written now... the list of trusted certs
returned to the client will be pulled from CAlist and the certificates and CRLs
to verify against will come from CRLlist. This means that your Root
certificates have to go in both locations.

I was going to suggest an alternative, perhaps a flag to turn the CRL check on
and off, rather then a seperate location.

Thanks,

John D.

********** Original Email *********
** To:   pound(at)apsis.ch
** From: Robert Segall <roseg(at)apsis.ch>
** Date: Wed, 18 May 2005 18:10:13 +0200
**********

On Wed, 18 May 2005 08:33:52 -0700 "John D" <jwdavid(at)ibizvision.com>
wrote:[...]

Thanks - that goes into the man page.
[...]

True, but it doesn't hurt if they are there (in the past OpenSSL had its
own locations, so enabling the check can't hurt).

In any case, I feel that your remark re. possible confusion is correct,
so I just uploaded 1.8.5, which has a separate CRLlist configuration
directive. Enjoy.[...]

On Wed, 18 May 2005 09:43:54 -0700 "John D" <jwdavid(at)ibizvision.com>
wrote:[...]

That's correct.
[...]

True. The problem is that 'CA' is used in two roles: once as a list of
names sent to the client (basically: I'll accept certificates issued by
one of these authorities) and once as a list of root certificates (I
received a certificate from the client; was it signed by a CA I know?).
Sending CRL as part of the first may not be a great idea, though (given
the particular OpenSSL implementation) it wouldn't hurt.
[...]

Please do - I'd be happy to look at it[...]