cannot make mod_ssl work
Hello, I wrote earlier advising that I could not get mod_ssl to work on a Linux box ... RedHat 5.0 - Kernel 2.0.34. I have installed SSLeay-0.9.0b and mod_ssl-2.0.10-1.3.1 for Apache 1.3.1. I installed per INSTALL instructions and the installation went just fine. I however get nothing with Netscape Communicator 4.05 except the certificate warning boxes. After that there is a timeout of about 3-minutes and then Netscape pops up "Document contains no data". I have looked high and low, and tried all manner of changes to the test certificate to get this behavior to change. The certificate CN has the same as the web server hostname in the configuration and this hostname is the machines real primary ethernet interface and Unix hostname. I have stripped the httpd.conf.dist bare to its stock auto created version and the problem still persists. I doubt that SSLeay or mod_ssl are on RedHat Linux anywhere installed that would conflict, so I am out of ideas. A test with s_client, as previously suggested I previously posted results in the following: * I don't have Lynx-SSL set up anywhere, but, s_client ... after several minutes tells: read:errno=0 Apache error_log tells: connect: Connection timed out When I pipe the output of s_client to less so that I can view all of it, there is verify errors such as: verify error:num=20:unable to get local issuer certificate verify return:1 verify error:num=21:unable to verify the first certificate I have done the whole installation over and over again, and have done "make certificate" and "make install" in the Apache 1.3.1 directory many times trying to get this to work. Not a thing seems to change this failure to make a complete SSL connection. Funny thing, I installed from the exact same tar.gz's at home on another RedHat Linux box with an older kernel, and the same exact version web server (ok I upgraded to 1.3.1 ;-) and Lo-and-Behold the one here at home works! I can get the SSL lock via my local ethernet and I have had someone else test via the Internet where it worked also. I sure could use some help ... like someone that can analyze this at a level deeper than I'd care to go, and tell me what silly little thing down in a nook or cranny I am looking over like such a big elephant wearing orange trousers. Could this thing be looking up reverse-dns or something and is not agreeing with the CN I am giving in the certificate? Or is something with SSL or port 443 broken on two remote machines of mine that is not broken on the local one here? Why does Raven Eval 1.2.2 work? If I can get a response from the author, I will at his convenience provide any information that is needed to debug this problem, including if necessary - access to the machine via secure shell. TIA Alan G. Spicer (Independant SysAdmin/Webmaster,...) PS: [fyi the small company contract I currently have is not wanting to buy Raven or such for just testing this capability. I already demo'd SSL with Raven's Evaluation 1.2.2. I also have done Raven for "secure.satelnet.org" long ago. Pardon me for being new to the SSLeay and mod_ssl. I'm about to buy Raven myself and then it'll be mine ;-) ] --- Alan Spicer ([EMAIL PROTECTED]) __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot make mod_ssl work
On Wed, Oct 07, 1998, Alan Spicer wrote: >[..] > I have installed SSLeay-0.9.0b and mod_ssl-2.0.10-1.3.1 for > Apache 1.3.1. I installed per INSTALL instructions and the > installation went just fine. I however get nothing with > Netscape Communicator 4.05 except the certificate warning > boxes. After that there is a timeout of about 3-minutes and > then Netscape pops up "Document contains no data". 3 minutes? Hmmm... sounds like a typical DNS timeout. >[...] > s_client ... > after several minutes tells: read:errno=0 > Apache error_log tells: connect: Connection timed out But this sounds more like a network problem. > When I pipe the output of s_client to less so that I can view all > of it, there is verify errors such as: > > verify error:num=20:unable to get local issuer certificate > verify return:1 > verify error:num=21:unable to verify the first certificate This is harmless, just because s_client cannot verify the server certificate. It has nothing to do with your network problems, IMO. >[...] > Funny thing, I installed from the exact same tar.gz's at home > on another RedHat Linux box with an older kernel, and the > same exact version web server (ok I upgraded to 1.3.1 ;-) > and Lo-and-Behold the one here at home works! I can get the > SSL lock via my local ethernet and I have had someone else > test via the Internet where it worked also. This means that it's a local problem on this particular other Linux box. Because you said its a RH 5.0 box and I already know of reports for strange problems under RH 5.0 related to Apache and mod_ssl I conclude that RH 5.0 is your problem here, too. But we do not know, of course. >[...] > If I can get a response from the author, I will at his > convenience provide any information that is needed to debug > this problem, including if necessary - access to the machine > via secure shell. Yes, without tracing the code you cannot find the root of your problems. I recommend you the following: 1. Try to find out wheter there are 5.0 updates related to kernel and libc from RedHat which perhaps solve your problems. Because other RH 5.0 users reported similar problems for Apache recently, the chance is high that there is something broken under RH 5.0. Especially the glibc2 stuff causes problems. After people have downgraded to libc5 Apache worked for them. Perhaps this is the case for you, too. 2. After 1.) failed you can create an "rse" account on your box, reachable via SSH. Then when I find time I can spent an hour to trace the code. This way we at least know at which corner the problem is. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot make mod_ssl work
At 11:12 AM 10/7/98 +0200, you wrote: >On Wed, Oct 07, 1998, Alan Spicer wrote: > >>[..] >> I have installed SSLeay-0.9.0b and mod_ssl-2.0.10-1.3.1 for >> Apache 1.3.1. I installed per INSTALL instructions and the >> installation went just fine. I however get nothing with >> Netscape Communicator 4.05 except the certificate warning >> boxes. After that there is a timeout of about 3-minutes and >> then Netscape pops up "Document contains no data". > >3 minutes? Hmmm... sounds like a typical DNS timeout. > >>[...] >> s_client ... >> after several minutes tells: read:errno=0 >> Apache error_log tells: connect: Connection timed out > >But this sounds more like a network problem. > >> When I pipe the output of s_client to less so that I can view all >> of it, there is verify errors such as: >> >> verify error:num=20:unable to get local issuer certificate >> verify return:1 >> verify error:num=21:unable to verify the first certificate > >This is harmless, just because s_client cannot verify >the server certificate. It has nothing to do with your >network problems, IMO. > >>[...] >> Funny thing, I installed from the exact same tar.gz's at home >> on another RedHat Linux box with an older kernel, and the >> same exact version web server (ok I upgraded to 1.3.1 ;-) >> and Lo-and-Behold the one here at home works! I can get the >> SSL lock via my local ethernet and I have had someone else >> test via the Internet where it worked also. > >This means that it's a local problem on this particular other Linux box. >Because you said its a RH 5.0 box and I already know of reports for strange >problems under RH 5.0 related to Apache and mod_ssl I conclude that RH 5.0 is >your problem here, too. But we do not know, of course. > >>[...] >> If I can get a response from the author, I will at his >> convenience provide any information that is needed to debug >> this problem, including if necessary - access to the machine >> via secure shell. > >Yes, without tracing the code you cannot find the root >of your problems. I recommend you the following: > >1. Try to find out wheter there are 5.0 updates related to kernel and libc > from RedHat which perhaps solve your problems. Because other RH 5.0 users > reported similar problems for Apache recently, the chance is high that > there is something broken under RH 5.0. Especially the glibc2 stuff causes > problems. After people have downgraded to libc5 Apache worked for them. > Perhaps this is the case for you, too. > >2. After 1.) failed you can create an "rse" account on your box, > reachable via SSH. Then when I find time I can spent an hour to trace the > code. This way we at least know at which corner the problem is. > > Ralf S. Engelschall > [EMAIL PROTECTED] > www.engelschall.com * Wow. Tell me again how to tell what C Library I have? I remember recently installing some software that had to be downloaded depending on which libc. I want to compare which libc the local "working" mod_ssl has as compared to the remote 2 machines that currently won't work with mod_ssl. I'm a little leary about changing libc's on these two remote production machines. I don't want to break anything else that is currently working. It's funny ... I'd think my local machine, running a Cyrix clone Pentium would be the problem one ;-) I had to recently install a patch so that GCC could compile 'C' programs at all. It was specific to problems with Cyrix 6x86's and GCC. Anyway I think all three have the same type of glibc, but I want to confirm that. Funny now the Cyrix is the one that WORKS and not the true blue Intel Pentium's ;-) All three machines were originally installed from the same RedHat 5.0 CD from Macmillan Computer Publishing. --- Alan Spicer ([EMAIL PROTECTED]) __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot make mod_ssl work
On Wed, Oct 07, 1998, Alan Spicer wrote: >[...] > >1. Try to find out wheter there are 5.0 updates related to kernel and libc > > from RedHat which perhaps solve your problems. Because other RH 5.0 users > > reported similar problems for Apache recently, the chance is high that > > there is something broken under RH 5.0. Especially the glibc2 stuff causes > > problems. After people have downgraded to libc5 Apache worked for them. > > Perhaps this is the case for you, too. > > > >2. After 1.) failed you can create an "rse" account on your box, > > reachable via SSH. Then when I find time I can spent an hour to trace the > > code. This way we at least know at which corner the problem is. > * Wow. Tell me again how to tell what C Library I have? I remember recently > installing some software that had to be downloaded depending on which libc. > I want to compare which libc the local "working" mod_ssl has as compared to > the remote 2 machines that currently won't work with mod_ssl. I'm a little > leary about changing libc's on these two remote production machines. I don't > want to break anything else that is currently working. I've no RedHat box available, so I cannot help you here. But when these are production machines you should be carefully. Only upgrade or downgrade libc when you really know what you're doing. Then the best way for you is to install a different machine under RH 5.1 (where people didn't reported problems), try mod_ssl there and when it goes fine you can thing about upgrading the OS on your production machine. I recommend you to consult any RH/Linux-related newsgroups or mailing lists for this, because we usually cannot help you here, of course. > It's funny ... I'd think my local machine, running a Cyrix clone Pentium would > be the problem one ;-) I had to recently install a patch so that GCC could > compile 'C' programs at all. It was specific to problems with Cyrix 6x86's and > GCC. Anyway I think all three have the same type of glibc, but I want to > confirm that. Funny now the Cyrix is the one that WORKS and not the true blue > Intel Pentium's ;-) It's not related to the CPU, IMHO. I'm sure you messed up something related to your libc or the compiler. > All three machines were originally installed from the same RedHat 5.0 CD from > Macmillan Computer Publishing. Yes "originally", but know you have a different installation ;-) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot make mod_ssl work
At 01:09 PM 10/7/98 +0200, you wrote: >On Wed, Oct 07, 1998, Alan Spicer wrote: > >>[...] >> >1. Try to find out wheter there are 5.0 updates related to kernel and libc >> > from RedHat which perhaps solve your problems. Because other RH 5.0 users >> > reported similar problems for Apache recently, the chance is high that >> > there is something broken under RH 5.0. Especially the glibc2 stuff causes >> > problems. After people have downgraded to libc5 Apache worked for them. >> > Perhaps this is the case for you, too. >> > >> >2. After 1.) failed you can create an "rse" account on your box, >> > reachable via SSH. Then when I find time I can spent an hour to trace the >> > code. This way we at least know at which corner the problem is. > >> * Wow. Tell me again how to tell what C Library I have? I remember recently >> installing some software that had to be downloaded depending on which libc. >> I want to compare which libc the local "working" mod_ssl has as compared to >> the remote 2 machines that currently won't work with mod_ssl. I'm a little >> leary about changing libc's on these two remote production machines. I don't >> want to break anything else that is currently working. > >I've no RedHat box available, so I cannot help you here. But when these are >production machines you should be carefully. Only upgrade or downgrade libc >when you really know what you're doing. Then the best way for you is to >install a different machine under RH 5.1 (where people didn't reported >problems), try mod_ssl there and when it goes fine you can thing about >upgrading the OS on your production machine. I recommend you to consult any >RH/Linux-related newsgroups or mailing lists for this, because we usually >cannot help you here, of course. > >> It's funny ... I'd think my local machine, running a Cyrix clone Pentium would >> be the problem one ;-) I had to recently install a patch so that GCC could >> compile 'C' programs at all. It was specific to problems with Cyrix 6x86's and >> GCC. Anyway I think all three have the same type of glibc, but I want to >> confirm that. Funny now the Cyrix is the one that WORKS and not the true blue >> Intel Pentium's ;-) > >It's not related to the CPU, IMHO. I'm sure you messed up something >related to your libc or the compiler. > >> All three machines were originally installed from the same RedHat 5.0 CD from >> Macmillan Computer Publishing. > >Yes "originally", but know you have a different installation ;-) > > Ralf S. Engelschall > [EMAIL PROTECTED] > www.engelschall.com * Thanks again for your time and suggestions. I'm going to try the suggestion for RedHat 5.1, I just so happen to have RedHat 5.1 directly from RedHat here and it was already installed on this same Pentium 200 where I am emailing you from Win95. I'll boot down to RedHat 5.1 and install the stuff and test from there. FYI RedHat ran into a bug in a certain version of GCC (C and C++) with Cyrix CPU's that numerous people noticed and reported. They released an RPM of a patched GCC and whatever else part was needed for C++. As I remember I have only done the C RPM and so far have not had a need for C++. Much thanks again for your insight and help. --- Alan Spicer ([EMAIL PROTECTED]) __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot make mod_ssl work
At 11:12 AM 10/7/98 +0200, you wrote: >On Wed, Oct 07, 1998, Alan Spicer wrote: > >>[..] >> I have installed SSLeay-0.9.0b and mod_ssl-2.0.10-1.3.1 for >> Apache 1.3.1. I installed per INSTALL instructions and the >> installation went just fine. I however get nothing with >> Netscape Communicator 4.05 except the certificate warning >> boxes. After that there is a timeout of about 3-minutes and >> then Netscape pops up "Document contains no data". > >3 minutes? Hmmm... sounds like a typical DNS timeout. * H then why doesn't it tell DNS error in Netscape? Like otherwise when a host is not found in DNS. Also why do you get the certificate all the way to Netscape on the other side of the world when there is a network error? > >>[...] >> s_client ... >> after several minutes tells: read:errno=0 * I just did a RedHat 5.1 installation of Apache 1.3.1 and all of the SSLeay and mod_ssl, and move httpd.conf.default to httpd.conf, and did apachectl startssl and Apache starts ok, asks for cert password. s_client makes test just fine and gets / home page. Interestingly testing this on both of the working machines gets that exact same "read:errno=0" even after sending the / HTML page just fine. That seems to be a normal thing. Probably a left-over from the cert errors that you say do not matter. However the logging in the error_log (mentioned below) does not occur on the working test machines here at home. >> Apache error_log tells: connect: Connection timed out > >But this sounds more like a network problem. * H, why then does Apache give the non-secure pages just fine. Apache functions normally except for mod_ssl. I really don't understand how glibc or libc5 have anything to do with it. I compile Apache and all of this other software (SSLeay) (mod_ssl) and everything zings right into place without an error. We get certificate to the remote Netscape and then the connection hangs. Something must not be working in that negotiation phase. Why does Netscape finally get "document contains no data" ? SSL Handshaking and/or Cypher negotiation never finishes. I can get secure connections irregardless of what the certificate says from the machines that work ... I just get warned by Netscape that the site name is not the same. If I accept that, zing! I'm locked in a secure session. So the certificate does not seem to be it either. Doesn't matter if I URL to the 192.168.10.x or to my PPP connection IP, or the real PPP connection hostname. I have never had a problem related to Apache with either of the two remote hosts. Apache compiles file always and runs fine always. If anything SSLeay or mod_ssl, or both, don't like something on these systems. The both have Linux 2.0.34 kernels. So does the new RedHat 5.1. If something in RedHat is wrong (5.0 or 5.1) then your going to get a lot of questions because RedHat is the most popular distribution of Linux. Both of remote machines are existing Apache installs been running at high traffic levels every day. Both have been on 1.3.1 since not long after it came out. The only source change was to raise HARD_SERVER_LIMIT from 256 to 512. Libraries on these systems should be stock from RedHat. > >> When I pipe the output of s_client to less so that I can view all >> of it, there is verify errors such as: >> >> verify error:num=20:unable to get local issuer certificate >> verify return:1 >> verify error:num=21:unable to verify the first certificate > >This is harmless, just because s_client cannot verify >the server certificate. It has nothing to do with your >network problems, IMO. > >>[...] >> Funny thing, I installed from the exact same tar.gz's at home >> on another RedHat Linux box with an older kernel, and the >> same exact version web server (ok I upgraded to 1.3.1 ;-) >> and Lo-and-Behold the one here at home works! I can get the >> SSL lock via my local ethernet and I have had someone else >> test via the Internet where it worked also. > >This means that it's a local problem on this particular other Linux box. >Because you said its a RH 5.0 box and I already know of reports for strange >problems under RH 5.0 related to Apache and mod_ssl I conclude that RH 5.0 is >your problem here, too. But we do not know, of course. > >>[...] >> If I can get a response from the author, I will at his >> convenience provide any information that is needed to debug >> this problem, including if necessary - access to the machine >> via secure shell. > >Yes, without tracing the code you cannot find the root >of your problems. I recommend you the following: > >1. Try to find out wheter there are 5.0 updates related to kernel and libc > from RedHat which perhaps solve your problems. Because other RH 5.0 users > reported similar problems for Apache recently, the chance is high that > there is something broken under RH 5.0. Especially the glibc2 stuff causes > problems. After people have downgraded to libc5 Apache worked for them. > Perhaps this is the case for you, too. > >2. Afte
