BUG #1321: SSL error: sslv3 alert handshake failure

"PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:

After installing 8.0.0beta4 (previously tried with beta3,2,etc) on a linux
system with a working 7.4.x installation I was unable to connect with ssl.
Tried compiling with OpenSSL 0.9.7d/e. I used certificates created with
OpenSSL 0.9.7d/e that both worked fine with 7.4.x but apparently not so with
8.0.0. Server starts fine, but when I attempt to connect to the server with
latest pgadmin or psql (8.0.0beta4 both on the pgfoundry binary for windows
and a compiled version on Mandrake Linux) the error is always the same. The
error message returned to the client is "SSL error: sslv3 alert handshake
failure". The log reports: "could not accept SSL connection: 1".

The only SSL changes between beta3 and beta4 were Magnus' changes to
make ssl work on Windows, so I'm assuming this is his fault ...

regards, tom lane

After installing 8.0.0beta4 (previously tried with

beta3,2,etc) on a linux

system with a working 7.4.x installation I was unable to

connect with ssl.

Tried compiling with OpenSSL 0.9.7d/e. I used certificates

created with

OpenSSL 0.9.7d/e that both worked fine with 7.4.x but

apparently not so with

8.0.0. Server starts fine, but when I attempt to connect to

the server with

latest pgadmin or psql (8.0.0beta4 both on the pgfoundry

binary for windows

and a compiled version on Mandrake Linux) the error is

always the same. The

error message returned to the client is "SSL error: sslv3

alert handshake

failure". The log reports: "could not accept SSL connection: 1".

The only SSL changes between beta3 and beta4 were Magnus' changes to
make ssl work on Windows, so I'm assuming this is his fault ...

It would have to come from
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/libp
q/be-secure.c.diff?r1=1.51&r2=1.52, the part where it fixes error
handling.
(Previusly it did three API calls and didn't actually check their
results individually)
In open_server_ssl(), right at the bottom.

I can't see where the problem is though. And it did work in all my
testing - both Windows and Linux. But that part can certainly be
reversed - I only added it because I needed the better error reporting
during debugging, and figured it would be useful for others as well.

I'm not 100% sure from the post wether this problem was actually not
present in beta3, or if it possibly was. But that could be me reading
the report trying to make it fit my needs.

Upon reviewing this patch, I notice this horrible line slipped into the
patch earlier up (in the #ifdef WIN32 section):
+ printf("uhh\n");fflush(stdout);

Oopsie. Could you remove that, or do you want a patch to do it? :-)
Can't beleive I missed that...

//Magnus

On Tue, Nov 16, 2004 at 03:01:23PM -0500, Tom Lane wrote:

"PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:

After installing 8.0.0beta4 (previously tried with beta3,2,etc) on a linux
system with a working 7.4.x installation I was unable to connect with ssl.
Tried compiling with OpenSSL 0.9.7d/e. I used certificates created with
OpenSSL 0.9.7d/e that both worked fine with 7.4.x but apparently not so with
8.0.0. Server starts fine, but when I attempt to connect to the server with
latest pgadmin or psql (8.0.0beta4 both on the pgfoundry binary for windows
and a compiled version on Mandrake Linux) the error is always the same. The
error message returned to the client is "SSL error: sslv3 alert handshake
failure". The log reports: "could not accept SSL connection: 1".

The only SSL changes between beta3 and beta4 were Magnus' changes to
make ssl work on Windows, so I'm assuming this is his fault ...

Sounds like a problem due to the backend in recent betas demanding
a client certificate if $PGDATA/root.crt exists, but the client
certificate doesn't exist in ~/.postgresql/postgresql.{crt,key}.

What happens if you remove or rename $PGDATA/root.crt and restart
the backend? The server should print warnings like the following
but client connections should then succeed:

could not load root certificate file "/usr/local/pgsql/data/root.crt": No such file or directory
Will not verify client certificates.

Or you could install a client certificate and key in the locations
mentioned (~/.postgresql/postgresql.{crt,key}).

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Michael Fuhr <mike@fuhr.org> writes:

Sounds like a problem due to the backend in recent betas demanding
a client certificate if $PGDATA/root.crt exists, but the client
certificate doesn't exist in ~/.postgresql/postgresql.{crt,key}.

If that is the problem, it's still broken because the error message
is so unhelpful. (I'm quite certain I tested that case last time
I touched the SSL code, and it said something reasonable then.)

regards, tom lane

On Tue, Nov 16, 2004 at 03:33:49PM -0500, Tom Lane wrote:

Michael Fuhr <mike@fuhr.org> writes:

Sounds like a problem due to the backend in recent betas demanding
a client certificate if $PGDATA/root.crt exists, but the client
certificate doesn't exist in ~/.postgresql/postgresql.{crt,key}.

If that is the problem, it's still broken because the error message
is so unhelpful. (I'm quite certain I tested that case last time
I touched the SSL code, and it said something reasonable then.)

I get the following error if I use an 8.0.0beta4 client to connect
to an 8.0.0beta4 server that has a root.crt, but the client certificate
doesn't exist in ~/.postgresql:

psql: SSL error: sslv3 alert handshake failure

The server logs the following:

LOG: could not accept SSL connection: 1

If the certificate exists but I use a 7.4.6 client, then the client
fails with the following:

psql: unrecognized SSL error code

The server logs this:

LOG: could not accept SSL connection: 5

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

To clarify, what I have experienced was in all versions of 8.0.0.beta,
it did not just happen between 3 to 4. It was the change from 7.4 to
8.0. The error was not just windows based as I built psql on a seperate
linux machine communicating with a linux server and got the same
results. I created a client.crt client.key and placed them into the data
directory, no change. I read the below post again and renamed the files
to postgresql.crt and postgresql.key. No change. Read the below post
very carefully AGAIN and then copied those files up one directory into
the main pgsql dir. No change. Did I miss something?

Michael Fuhr wrote:

"T.J." <tjtoocool@phreaker.net> writes:

To clarify, what I have experienced was in all versions of 8.0.0.beta,
it did not just happen between 3 to 4. It was the change from 7.4 to
8.0. The error was not just windows based as I built psql on a seperate
linux machine communicating with a linux server and got the same
results. I created a client.crt client.key and placed them into the data
directory, no change. I read the below post again and renamed the files
to postgresql.crt and postgresql.key. No change. Read the below post
very carefully AGAIN and then copied those files up one directory into
the main pgsql dir. No change. Did I miss something?

The client key files go into something under the client user's HOME
directory (I think ~/.pgsql/client.key, but check the manual). This
is entirely unrelated to either PGDATA or the postgres user's home
(neither of which a client program would be able to read, typically).

This stuff is documented in the 8.0 libpq docs.

regards, tom lane

On Tue, 2004-11-16 at 21:13 +0100, Magnus Hagander wrote:

Upon reviewing this patch, I notice this horrible line slipped into the
patch earlier up (in the #ifdef WIN32 section):
+ printf("uhh\n");fflush(stdout);

Oopsie. Could you remove that, or do you want a patch to do it? :-)
Can't beleive I missed that...

Fixed.

-Neil