Thread: More SSL questions..
Having some problems (still, hehe) getting SSL to work properly on windows in the new 8.0 (all vers) environment (where cert/key is required). On the client side when not finding the certificate/key psql would report the SSL error sslv3 alert handshale failure. After I figured out where psql was looking for the files and placing them there I now get the error: SSL SYSCALL error: Connection reset by peer (0x00002746/10054). On the server side it still reports that the peer did not return a certificate. I am able to connect to the server just fine using the same certificate/key on a linux machine...so I'm guessing it's just another good ol' windows issue? :)
Did we ever find the solution to this, or did anyone find the cause? --------------------------------------------------------------------------- T.J. wrote: > Having some problems (still, hehe) getting SSL to work properly on > windows in the new 8.0 (all vers) environment (where cert/key is required). > > On the client side when not finding the certificate/key psql would > report the SSL error sslv3 alert handshale failure. After I figured out > where psql was looking for the files and placing them there I now get > the error: SSL SYSCALL error: Connection reset by peer > (0x00002746/10054). On the server side it still reports that the peer > did not return a certificate. > > I am able to connect to the server just fine using the same > certificate/key on a linux machine...so I'm guessing it's just another > good ol' windows issue? :) > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Not to my knowledge. By the way, for future reference on windows it looks for the cert/key in the linux equivalent of `pwd`/.postgresql/postgresql.crt/key, instead of $HOME/.postgresql/postgresql.crt/key. Maybe you already knew this but I had to do testing to figure it out so hopefully that bit of knowledge will be of use to someone else :) I tried looking through the source myself for the cause of this problem but I guess there's a reason my perl is so sharp and c so rusty these days.. Don't know if it makes much difference but I have built with vcwin and mingw with the same resulting error. Bruce Momjian wrote: >Did we ever find the solution to this, or did anyone find the cause? > >--------------------------------------------------------------------------- > >T.J. wrote: > > >>Having some problems (still, hehe) getting SSL to work properly on >>windows in the new 8.0 (all vers) environment (where cert/key is required). >> >>On the client side when not finding the certificate/key psql would >>report the SSL error sslv3 alert handshale failure. After I figured out >>where psql was looking for the files and placing them there I now get >>the error: SSL SYSCALL error: Connection reset by peer >>(0x00002746/10054). On the server side it still reports that the peer >>did not return a certificate. >> >>I am able to connect to the server just fine using the same >>certificate/key on a linux machine...so I'm guessing it's just another >>good ol' windows issue? :) >> >> >>---------------------------(end of broadcast)--------------------------- >>TIP 6: Have you searched our list archives? >> >> http://archives.postgresql.org >> >> >> > > >
"T.J." <tjtoocool@phreaker.net> writes:
> Not to my knowledge. By the way, for future reference on windows it
> looks for the cert/key in the linux equivalent of
> `pwd`/.postgresql/postgresql.crt/key, instead of
> $HOME/.postgresql/postgresql.crt/key.
Actually, it asks getpwuid() for the user's home directory,
rather than looking for an environment variable named HOME.
See client_cert_cb() in fe-secure.c.
This could probably be documented better, but I'm not sure how.
The average user is even less likely to be familiar with getpwuid()
than $HOME, so it doesn't seem like referencing that library function
is much of an improvement.
regards, tom lane
After some more screwing around, I'm not entirely certain windows is
even trying to open my certs. After repeatedly trying to connect it
seemed like I was getting an equal amount of the sslv3 and SSL SYSCALL
errors, whether or not the certs were (where I thought?) windows was
looking for them..
Which leads me to my next question; that function client_cert_cb, does
it ever get executed on windows? :)
I mean, that's the function with the useful error messages (that helped
me on linux), is it not? And the error messages on windows are anything
but useful...and at the beginning of that function there is a:
#ifdef WIN32
return 0;
#else
... (function)
return 1;
#endif
Tom Lane wrote:
>"T.J." <tjtoocool@phreaker.net> writes:
>
>
>>Not to my knowledge. By the way, for future reference on windows it
>>looks for the cert/key in the linux equivalent of
>>`pwd`/.postgresql/postgresql.crt/key, instead of
>>$HOME/.postgresql/postgresql.crt/key.
>>
>>
>
>Actually, it asks getpwuid() for the user's home directory,
>rather than looking for an environment variable named HOME.
>See client_cert_cb() in fe-secure.c.
>
>This could probably be documented better, but I'm not sure how.
>The average user is even less likely to be familiar with getpwuid()
>than $HOME, so it doesn't seem like referencing that library function
>is much of an improvement.
>
> regards, tom lane
>
>
>
"T.J." <tjtoocool@phreaker.net> writes:
> Which leads me to my next question; that function client_cert_cb, does
> it ever get executed on windows? :)
Um. Looks like someone ifdef'd it out :-(. In fact, if you look
through fe-secure.c, you'll see that just about all the SSL code is
ifdef'd out on Windows.
Try removing the #ifs and see if it compiles.
win32 hackers, anyone know why it's like this?
regards, tom lane
Yeah I already tried removing the ifdef's...oh BOY was it not happy :'( Tom Lane wrote: >"T.J." <tjtoocool@phreaker.net> writes: > > >>Which leads me to my next question; that function client_cert_cb, does >>it ever get executed on windows? :) >> >> > >Um. Looks like someone ifdef'd it out :-(. In fact, if you look >through fe-secure.c, you'll see that just about all the SSL code is >ifdef'd out on Windows. > >Try removing the #ifs and see if it compiles. > >win32 hackers, anyone know why it's like this? > > regards, tom lane > >
I wrote:
> win32 hackers, anyone know why it's like this?
Looking through the code, it seems that it's because someone thought
that breaking SSL would be easier than replacing the pqGetpwuid() calls
that are used to find out the user's home directory.
Does Windows even have a concept of home directory? What would be a
reasonable equivalent to ~/.postgresql/ ?
regards, tom lane
Tom Lane wrote: >I wrote: > > >>win32 hackers, anyone know why it's like this? >> >> > >Looking through the code, it seems that it's because someone thought >that breaking SSL would be easier than replacing the pqGetpwuid() calls >that are used to find out the user's home directory. > >Does Windows even have a concept of home directory? What would be a >reasonable equivalent to ~/.postgresql/ ? > The versions of windows that the port supports (NT4, 2000, 2003, XP) do have home directories. The "Documents and Settings" (except NT 4 which uses "Profiles") directory in windows is like /home in Unix. Using my XP Pro box, I see two relevant environment variables HOMEDRIVE, and HOMEPATH. On my box they are set as follows: HOMEDRIVE=C: HOMEPATH=\Documents and Settings\matthew So: ~/.postgresql/ = C:\Documents and Settings\matthew\.postgresql\ Hope that helps. Matthew
"Matthew T. O'Connor" <matthew@zeut.net> writes:
> Tom Lane wrote:
>> Does Windows even have a concept of home directory? What would be a
>> reasonable equivalent to ~/.postgresql/ ?
> The versions of windows that the port supports (NT4, 2000, 2003, XP) do
> have home directories.
OK ... are you supposed to find it out by looking at the environment
vars, or is there another API defined?
I am planning to consolidate the platform dependency into a function
defined like
static bool pqGetHomeDirectory(char *buf, int bufsize)
{
-- Obtain pathname of user's home directory, store in
-- buf[] (of size bufsize)
-- Return TRUE if succeeded, FALSE if not
}
If someone can whip up and test a WIN32 version of this, I'll take care
of the rest.
regards, tom lane
Tom Lane wrote:
>OK ... are you supposed to find it out by looking at the environment
>vars, or is there another API defined?
>
>I am planning to consolidate the platform dependency into a function
>defined like
>
> static bool pqGetHomeDirectory(char *buf, int bufsize)
> {
> -- Obtain pathname of user's home directory, store in
> -- buf[] (of size bufsize)
> -- Return TRUE if succeeded, FALSE if not
> }
>
>If someone can whip up and test a WIN32 version of this, I'll take care
>of the rest.
>
>
I can't do the coding, but I took a quick look at msdn and I think this
is relevant:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetfolderpath.asp
HRESULT SHGetFolderPath(
HWND /hwndOwner/,
int /nFolder/,
HANDLE /hToken/,
DWORD /dwFlags/,
LPTSTR /pszPath/
);
Also, for nFolder, it looks like the we want to use a value of
CSIDL_PROFILE (0x0028).
Hope that helps someone out there.
Matthew
Andrew Dunstan <andrew@dunslane.net> writes:
> I think CSIDL_APPDDATA is probably the way to go, but one of the heavy
> Windows hitters will know better than I do.
Now that I look at it, there are several places that are depending on
getenv("HOME") or getenv("USERPROFILE") (on Windows) as the meaning of
"home directory". In particular ~/.pgpass is sought there, and psql
also uses get_home_path in a lot of places.
Seems like we should be consistent about this --- either we trust $HOME
or we don't.
regards, tom lane
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>>I think CSIDL_APPDDATA is probably the way to go, but one of the heavy
>>Windows hitters will know better than I do.
>
>
> Now that I look at it, there are several places that are depending on
> getenv("HOME") or getenv("USERPROFILE") (on Windows) as the meaning of
> "home directory". In particular ~/.pgpass is sought there, and psql
> also uses get_home_path in a lot of places.
>
> Seems like we should be consistent about this --- either we trust $HOME
> or we don't.
more fun. I just checked the environment of the postmaster service on a
win2000 Pro system (using www.sysinternals.com's excellent Process Explorer
tool, btw). HOME is not set. USERPROFILE is set to "C:\Documents and
Settings\postgres"...
For services that are running as 'NT AUTHORITY\SYSTEM', the profile is
"C:\Documents and Settings\Default User" (and the USERDOMAIN and USERNAME
aren't set at all)...
John R Pierce <pierce@hogranch.com> writes:
> Tom Lane wrote:
>> Seems like we should be consistent about this --- either we trust $HOME
>> or we don't.
> more fun. I just checked the environment of the postmaster service on a
> win2000 Pro system (using www.sysinternals.com's excellent Process Explorer
> tool, btw). HOME is not set. USERPROFILE is set to "C:\Documents and
> Settings\postgres"...
> For services that are running as 'NT AUTHORITY\SYSTEM', the profile is
> "C:\Documents and Settings\Default User" (and the USERDOMAIN and USERNAME
> aren't set at all)...
Actually, the server doesn't depend on home directories in any way shape
or form. The places that we are concerned about are on the client side,
either in libpq or in psql. So what we have to think about is the
environment that libpq might see.
regards, tom lane
> win2000 Pro system (using www.sysinternals.com's excellent Process > Explorer tool, btw). HOME is not set. USERPROFILE is set to > "C:\Documents and Settings\postgres"... > > For services that are running as 'NT AUTHORITY\SYSTEM', the profile is > "C:\Documents and Settings\Default User" (and the USERDOMAIN and > USERNAME aren't set at all)... this is also set on XP Pro, except for the 'SYSTEM' services, its "C:\Documents and Settings\LocalServices" On Win2000 Server, its the same, except the default profiles are \winnt\profiles\%username%
> Actually, the server doesn't depend on home directories in any way shape > or form. The places that we are concerned about are on the client side, > either in libpq or in psql. So what we have to think about is the > environment that libpq might see. libpq could be called from a service, such as inetinfo (IIS)...
Tom Lane wrote: >John R Pierce <pierce@hogranch.com> writes: > > >>more fun. I just checked the environment of the postmaster service on a >>win2000 Pro system (using www.sysinternals.com's excellent Process Explorer >>tool, btw). HOME is not set. USERPROFILE is set to "C:\Documents and >>Settings\postgres"... >> >> >Actually, the server doesn't depend on home directories in any way shape >or form. The places that we are concerned about are on the client side, >either in libpq or in psql. So what we have to think about is the >environment that libpq might see. > Right but I think the point is that the environment variable HOME does not exist on windows. At least I have never seen it. I think it does exist inside CYGWIN (perhaps in mingw also?) might the use of the HOME variable be related to the Cygwin port? The standard env variables relevant to this conversation are the two I mentioned before (HOMEDRIVE, HOMEPATH) and the one mentioned above (USERPROFILE) which seems to be equivalent to HOMEDRIVE and HOMEPATH concatenated together. Matthew
Matthew T. O'Connor wrote: > Tom Lane wrote: > >> >> >> If someone can whip up and test a WIN32 version of this, I'll take care >> of the rest. >> >> > > I can't do the coding, but I took a quick look at msdn and I think > this is relevant: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetfolderpath.asp > > > HRESULT SHGetFolderPath( HWND /hwndOwner/, > int /nFolder/, > HANDLE /hToken/, > DWORD /dwFlags/, > LPTSTR /pszPath/ > ); > > > Also, for nFolder, it looks like the we want to use a value of > CSIDL_PROFILE (0x0028). Er, I don't think so. MSDN says: CSIDL_PROFILE (0x0028) Version 5.0. The user's profile folder. A typical path is C:\Documents and Settings\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. I think CSIDL_APPDDATA is probably the way to go, but one of the heavy Windows hitters will know better than I do. cheers andrew
Tom Lane wrote: > I wrote: > >>win32 hackers, anyone know why it's like this? > > > Looking through the code, it seems that it's because someone thought > that breaking SSL would be easier than replacing the pqGetpwuid() calls > that are used to find out the user's home directory. > > Does Windows even have a concept of home directory? Yes, from the shell it would be: %HOMEDRIVE% %HOMEPATH% I believe. Sincerely, Joshua D. Drake What would be a > reasonable equivalent to ~/.postgresql/ ? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
Tom Lane wrote: > I wrote: > > win32 hackers, anyone know why it's like this? > > Looking through the code, it seems that it's because someone thought > that breaking SSL would be easier than replacing the pqGetpwuid() calls > that are used to find out the user's home directory. > I think what happened is that SSL was known to be broken on Win32 and someone submitted a patch and I thought it now worked, but obviously it doesn't. Perhaps the fix was just so it compiled with SSL. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote:
> "Matthew T. O'Connor" <matthew@zeut.net> writes:
> > Tom Lane wrote:
> >> Does Windows even have a concept of home directory? What would be a
> >> reasonable equivalent to ~/.postgresql/ ?
>
> > The versions of windows that the port supports (NT4, 2000, 2003, XP) do
> > have home directories.
>
> OK ... are you supposed to find it out by looking at the environment
> vars, or is there another API defined?
>
> I am planning to consolidate the platform dependency into a function
> defined like
>
> static bool pqGetHomeDirectory(char *buf, int bufsize)
> {
> -- Obtain pathname of user's home directory, store in
> -- buf[] (of size bufsize)
> -- Return TRUE if succeeded, FALSE if not
> }
>
I had this on my personal TODO list:
centralize missing struct passwd
I didn't do it because I only relized it during beta when Peter
mentioned it. Well, seems like it is done now. :-)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073