Re: [TESTERS] Location of certs -Windows 7 SSL mode?

Magnus,

Tks for your response.

> What is your connection string? Are you specifying the cert file there as well?

Well, no. Specifically, the exercise was to determine default locations of certs on Windows 7, as inferred from - the expected - error message from the PG client. In this case, the client was pgAdmin. (Is pgAdmin not a valid 'default' test?)

> Does the file actually exist in that directory? Does the permissions on the file and all the directories leading up to it let you read the file?

Yes, exists; and all files wer created by the 'administrator' user - the only user on the system, with the system having been installed fresh specifically to effect this test. We're trying to develop a 'recipe' for our Windows 7 users.

> The code itself should actually "never" do this - it specifically checks if the file doesn't exist, and should *not* show that error..
> It should fail much later, when the server actually requests the cert..

Oh? I didn't realize this. In fact, past experience has been consistent with my findings; that pqlib will hiccup quickly if it cannot find a cert, and that this error message would appear before ever presenting that (non-)cert to the server. If a cert is found, on the other hand, error messages would be different, assuming it's an invalid cert in the context of pg_hba.cconf.

> Can you try specifying an explicit file say directly in c:\, just to see if that works?

Presumably you're proposing an environment variable approach? Sure, please propose an exact test, and we'll perform. (No one else here is using certs under Windows 7?)

(BTW, specifically did not post to bugs list as, since we are testing betas, I don't know whether I'm uncovering bugs - or 'new behaviors'! Or, whether I'm uncovering a 'bug' in, uhh... 'userspace'.)

Thanks again, Lou Picciano

----- Original Message -----
From: "Magnus Hagander" <magnus(at)hagander(dot)net>
To: "Lou Picciano" <LouPicciano(at)comcast(dot)net>
Cc: "pgsql-testers" <pgsql-testers(at)postgresql(dot)org>, "pgsql-bugs" <pgsql-bugs(at)postgresql(dot)org>
Sent: Wednesday, July 7, 2010 4:50:03 AM
Subject: Re: [TESTERS] Location of certs -Windows 7 SSL mode?

On Wed, Jul 7, 2010 at 01:37, Lou Picciano <LouPicciano(at)comcast(dot)net> wrote:
> [TEST REPORT]
> [Release]: 9.0Beta2
> [Test Type]: Testing connection - pgAdmin - using certificate on Windows 7 -
> Specifically, what is correct default placement of certs?
> [Test]: Attempt to connect - SSL required or better - using standard
> AppData/Roaming location for certs, key.
> [Platform]: Windows 7 Ultimate 64-bit - attempting connection using
> pgAdminIII as a test of SSL connectivity.
> [Parameters]: First, attempted connection, with SSL required and NO certs,
> to determine default location based on error message!
> [Failure]: Yes
> [Results]: Installation of a pre-packaged PostgreSQL, using an installer (in
> this case a b1 packaged by EnterpriseDB), did create a postgresql folder in
> the expected location: C:\Users\<username>\AppData\Roaming\postgresql.
> After placement of valid certs and key in this folder, cannot connect in
> any SSL mode.
> Interestingly, the error message reverses the pathname delimiter, halfway
> through the message, from Windows-standard to UNIX-standard (is this
> relevant?)...
> "Error connecting to the server: could not open certificate file
> "C:\Users\<username>\AppData\roaming/postgresql/potgresql.crt": No such file
> or directory.

The reversed slashes are pretty normal, and should work just fine.

What is your connection string? Are you specifying the cert file there as well?

Does the file actually exist in that directory? Does the permissions
on the file and all the directories leading up to it let you read the
file?

The code itself should actually "never" do this - it specifically
checks if the file doesn't exist, and should *not* show that error..
It should fail much later, when the server actually requests the
cert.. And the API documentation for stat() on windows says it'll
always return ENOENT on failure. Seems to me Windows is confused, but
I'm not entirely sure how.

Can you try specifying an explicit file say directly in c:\, just to
see if that works?

BTW, if you post bug reports to -bugs, it'll make a lot more people see them.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/