Re: Netscape + ModSSL=Dead slow.
Looking forward to your list of BrowserMatch statements.
Many of us would find this highly useful.
Thanks!
Chris
WSO
At 08:13 AM 6/20/2001 -0700, you wrote:
>on 6/19/01 5:02 PM, David Rees at [EMAIL PROTECTED] wrote:
>
>>
>> I've got a couple things for you to try.
>
>> If that doesn't work, can you try adding this line?
>>
>> BrowserMatch "Mozilla" nokeepalive downgrade-1.0 force-response-1.0
>>
>> This will disable keepalive for all versions of Netscape and make sure that
>> the response is 1.0, not 1.1. If it helps, we can then tailor it to
>> Netscape on the Mac after we figure out what the UserAgent header is. You
>> can pull the UserAgent header out of the log files if you're using the
>> combined log format.
>YES YES YES YES YES YES!!! instant response!
>
>Log file SAYSS..
>
>Mozilla/4.75C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
>
>I will begin testing every version we have available in the testlab and get
>a good match. I'll then return this info to the list.
>
>Thank you Dave, where are you at? I'm in Seattle and will be in Indianapolis
>this fall. I owe you a beverage of choice.
>
>DAve
>
>--
>Dave Goodrich
>Director of Interface Development
>Reality Based Learning Company
>9521 NE Willows Road, Suite 100
>Redmond, WA 98052
>Toll Free 1-877-869-6603 ext. 237
>Fax (425) 558-5655
>[EMAIL PROTECTED]
>http://www.rblc.com
>
>
>__
>Apache Interface to OpenSSL (mod_ssl) www.modssl.org
>User Support Mailing List [EMAIL PROTECTED]
>Automated List Manager[EMAIL PROTECTED]
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
RE: Netscape + ModSSL=Dead slow.
Does solving this problem with sweeping wildcard BrowserMatch statements adversely affect the functionality of Apache and ModSSL? What I getting at is, why don't we just BrowserMatch everything and call it a day? What are be losing when we downgrade or force 1.0? Thanks, Chris WSO At 12:38 PM 6/20/2001 -0400, you wrote: >I can confirm that I had this same slow/hang problem with Macs running >netscape 4.73 and 4.75, using several mod_ssl and apache version, running >on Solaris. This was not a Linux-centric issue. It wasn't a priority for >my client at the time, but I did send a BrowserMatch statement for them to >try. > >-Brian > > > > >> I've been using Netscape 4.77 (OS 9.1 I think) on an iMac over here without >> any problems and stock settings. Before that I've used Netscape 4.76 >> without any problems as well. I don't recall testing anything earlier, >> although I've got a couple production sites running mod_ssl on Linux (RedHat >> 6.2 systems with 2.2.18/19) without any problems. >> >> -Dave > >-- >== >Brian O'Neill @ home [EMAIL PROTECTED] >At work I'm: [EMAIL PROTECTED] > > >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Ultimate BrowserMatch List (was: Netscape + ModSSL=Dead slow.)
Thanks Dave, much appreciated! So, has anybody compiled the "ultimate BrowserMatch list" for ModSSL-Apache? In my regular Apache I've had the following in for some time now: BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 I build my regular Apache separately from my ModSSL-Apache so that I can run the ModSSL version at nice level -20, so that it appears to be as fast as possible. I would assume that the "ultimate BrowserMatch list" for ModSSL-Apache would be different and more inclusive than one for regular Apache? This is a great dialog, I appreciate the active responses. By the way, I run mine stuff on BSDI 2.1, 4.0.1 and 4.1 boxes without problems. Thanks, -Chris WSO At 03:05 PM 6/20/2001 -0700, you wrote: >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of WSO Support >> >> Does solving this problem with sweeping wildcard BrowserMatch >> statements adversely affect the functionality of Apache and ModSSL? > >No. Everything will function fine. > >> What I getting at is, why don't we just BrowserMatch everything >> and call it a day? What are be losing when we downgrade or >> force 1.0? > >Performance. By downgrading to HTTP 1.0 and disabling keep alives, the >client has to negotiate a new connection on every hit. If your site >contains many small images, your clients will definately notice a slowdown >if they are on a slow link (dial up, across the ocean, etc). Pages will >take longer to load. You may also notice a slight increase in server load, >but also see that more httpd processes are needed (since they will be tied >up longer waiting for the client to send something over the pipe instead of >disconnecting immediately after sending a response). > >But some browsers are simply broken with regards to SSL, keep alives and >HTTP 1.1. All versions of MSIE older than 5.0 are known to be problematic, >and now it appears that Netscape on Macintosh is also broken. > >For more info related to this, search the archives for the thread "KeepAlive >and IE, again...". > >-Dave > >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Ultimate BrowserMatch List (second try)
So, has anybody compiled an "ultimate BrowserMatch list" for ModSSL-Apache? In my regular Apache I've had the following in for some time now: BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 I would assume that the "ultimate BrowserMatch list" for ModSSL-Apache would be different and more inclusive than one for regular Apache? This is a great dialog, I appreciate the active responses. By the way, I run mine stuff on BSDI 2.1, 4.0.1 and 4.1 boxes without problems. Thanks, -Chris WSO At 03:05 PM 6/20/2001 -0700, you wrote: >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of WSO Support >> >> Does solving this problem with sweeping wildcard BrowserMatch >> statements adversely affect the functionality of Apache and ModSSL? > >No. Everything will function fine. > >> What I getting at is, why don't we just BrowserMatch everything >> and call it a day? What are be losing when we downgrade or >> force 1.0? > >Performance. By downgrading to HTTP 1.0 and disabling keep alives, the >client has to negotiate a new connection on every hit. If your site >contains many small images, your clients will definately notice a slowdown >if they are on a slow link (dial up, across the ocean, etc). Pages will >take longer to load. You may also notice a slight increase in server load, >but also see that more httpd processes are needed (since they will be tied >up longer waiting for the client to send something over the pipe instead of >disconnecting immediately after sending a response). > >But some browsers are simply broken with regards to SSL, keep alives and >HTTP 1.1. All versions of MSIE older than 5.0 are known to be problematic, >and now it appears that Netscape on Macintosh is also broken. > >For more info related to this, search the archives for the thread "KeepAlive >and IE, again...". > >-Dave > >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Ultimate BrowserMatch List (second try)
Thanks so much for sharing your findings, it has helped me a great deal. Thanks, Chris At 03:28 PM 7/18/2001 -0700, you wrote: >You can see my message dated 6/20 for an example of where to put it. So far >my additions work perfectly. > >DAve > >on 7/18/01 12:01 PM, David Rees at [EMAIL PROTECTED] wrote: > >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED]]On Behalf Of Andrea Cerrito >>> >>> What about: >>> >>> SetEnvIf User-Agent "MSIE [1-4]" nokeepalive ssl-unclean-shutdown >>> downgrade-1.0 force-response-1.0 >>> SetEnvIf User-Agent "MSIE [5-9]" ssl-unclean-shutdown >> >> Make sure those are only in your SSL virtual hosts, keep alive works fine >> for most MSIE browsers for normal HTTP. >> >> -Dave >> >> __ >> Apache Interface to OpenSSL (mod_ssl) www.modssl.org >> User Support Mailing List [EMAIL PROTECTED] >> Automated List Manager[EMAIL PROTECTED] >> > >-- >Dave Goodrich >Director of Interface Development >Reality Based Learning Company >9521 NE Willows Road, Suite 100 >Redmond, WA 98052 >Toll Free 1-877-869-6603 ext. 237 >Fax (425) 558-5655 >[EMAIL PROTECTED] >http://www.rblc.com > > >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
X509v3 extensions
I've just installed Apache 1.3.9+OpenSSL_0.9.4+mod_ssl_2.4.2 I moved my existing certs (issued by VeriSign & Thawte) into the /usr/local/apache/conf/ssl.crt directory. I moved my existing .key files into 'ssl.key'. I then ran 'make' from inside the 'ssl.crt' directory to create the hash symlink files. This is where is problem starts. If I examine my existing certs using the command: openssl x509 -noout -text -in name.crt They all view fine... but they are all Version: 1 certs. I recently get a cert renewal from Thawte and it was a v3 cert. I can view it fine using the above openssl command, but when the Makefile tries to read it and make the hash symlink, I get the following error: unable to load certificate error:0906906C:PEM routines:PEM_read:no start line Now, I took a look at the certs, I noticed that all of them start with "-BEGIN X509 CERTIFICATE-". When I originally got these from Thawte, the header was "-BEGIN CERTIFICATE-". I was using an OLD version of SSLeay, where I would issue the command 'getversign domain < tempfile' Where domain was the same name used for generating the key (genkey domain) and tempfile contained the cert from Thawte. This seemed to "convert" it to the X509 style... Anyway, now that I'm using OpenSSL I don't see any command similar to this. If I simply try to edit the cert and put the X509 in there and then run make again, I get a different set of errors, like this: unable to load certificate error:0D074071:asn1 encoding routines:d2i_ASN1_INTEGER:expecting an integer error:0D08C070:asn1 encoding routines:D2I_X509_CINF:error stack error:0D089070:asn1 encoding routines:D2I_X509:error stack error:0906600D:PEM routines:PEM_ASN1_read:ASN1 lib I just can't figure it out. All of my old certs work fine. I've TRIPLE checked with Thawte about the correctness of the new v3 cert they have issued, everything is okay on their end. This isn't a "trailing space" problem either. I've looked at all the simple things already... Any ideas at all would be greatly appreciated. Thank you very much, Chris __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: X509v3 extensions
Thanks for the response, but it seems you've misunderstood me. >> Now, I took a look at the certs, I noticed that all of them >> start with "-BEGIN X509 CERTIFICATE-". When I originally >> got these from Thawte, the header was "-BEGIN CERTIFICATE-". >Yes, OpenSSL looks for "BEGIN CERTIFICATE", so just >remove the "X509" part and try again. When I said "all of them" I was referring to the Thawte certs that has already been installed using the stronghold "getverisign" command over a year ago, using our old software. I have no problem with these, they work fine with OpenSSL & mod_ssl. The *new* cert I have from Thawte starts with just "-BEGIN CERTIFICATE-", as all of the others I have ever gotten in the past from Thawte. The only difference now is that this is a v3 cert, not v1, as all these others were. You said to remove the X590, but it isn't there. The new cert from Thawte doesn't have this in the header and it still won't work. Please again see my original message. http://www.progressive-comp.com/Lists/?l=apache-modssl&m=93808996711717&w=2 The main problem is that the 'Makefile' in 'ssl.crt' doesn't recognize the new style v3 cert from Thawte and thus will not create a "hash link" for it. Is there some sort of equivelent to the "getversign" command in OpenSSL? Or was the purpose or the getverisign command simply to move the cert from a temp file into the "certs" directory and create a hash link? I have put my time in on this one, I have spent almost 15 hours on the problem. Can somebody please shed some light? Thank you.. -Chris At 11:36 AM 9/27/1999 +0200, you wrote: >On Wed, Sep 22, 1999, WSO Support wrote: > > > [...] > > I get the following error: > > unable to load certificate > > error:0906906C:PEM routines:PEM_read:no start line > > > > > > I was using an OLD version of SSLeay, where I would issue the > > command 'getversign domain < tempfile' > > [...] > >"getverisign" was from Stronghold, not from SSLeay. > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: X509v3 extensions
Yes, here is the cert I'm having the problem with. I've had Thawte triple check it, and they have found no problems. This is a cert for a client of mine, of course. -BEGIN CERTIFICATE- MIICsDCCAhmgAwIBAgIDAIPNMA0GCSqGSIb3DQEBBAUAMIHEMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xHTAb BgNVBAoTFFRoYXd0ZSBDb25zdWx0aW5nIGNjMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMRkwFwYDVQQDExBUaGF3dGUgU2VydmVyIENB MSYwJAYJKoZIhvcNAQkBFhdzZXJ2ZXItY2VydHNAdGhhd3RlLmNvbTAeFw05OTA5 MTMxMzM0NDVaFw0wMDA5MjYxMzM0NDVaMIGRMQswCQYDVQQGEwJVUzEQMA4GA1UE CBMHRmxvcmlkYTEOMAwGA1UEBxMFTWlhbWkxGjAYBgNVBAoTEUZyZWVsYW5jZSBT dWNjZXNzMSEwHwYDVQQLExhTZWN1cmUgU2VydmljZXMgRGl2aXNpb24xITAfBgNV BAMTGHd3dy5mcmVlbGFuY2VzdWNjZXNzLmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sA MEgCQQC8bvTfSBgoKNaqMlXUv7Fr4GVNWY/6CuriCtggMeC0BqSKq021bhwfo3DL oav8rGbLJBvbbSwa89P0FUvf0pj5AgMBAAGjJTAjMBMGA1UdJQQMMAoGCCsGAQUF BwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEALt7627Hs+30X4Kc9 k1OyppVfE3i2JcgzpF5ZVF1pd1JCkAiSlKh94EnmIWbgZpImvZSeZgixYhT6bMXS 7N53vuMpWKdlMhdXb1aWX2y157aeAlVvGv3jFePejaNzw7SUDdsuplabE8r11n4l UMtE1UKmRQBKQua/WLReskiWrVM= -END CERTIFICATE- I really appreciate the help... My original posting contains the errors I receive from the Makefile in 'ssl.crt'. http://www.progressive-comp.com/Lists/?l=apache-modssl&m=93808996711717&w=2 Thanks again, Chris At 10:00 AM 9/28/1999 +0200, you wrote: >On Mon, Sep 27, 1999, WSO Support wrote: > > > [...] > > The *new* cert I have from Thawte starts with just > > "-BEGIN CERTIFICATE-", as all of the others I have ever > > gotten in the past from Thawte. The only difference now is that > > this is a v3 cert, not v1, as all these others were. > > > > You said to remove the X590, but it isn't there. The new cert from > > Thawte doesn't have this in the header and it still won't work. > > Please again see my original message. > > > > http://www.progressive-comp.com/Lists/?l=apache-modssl&m=93808996711717&w=2 > > > > The main problem is that the 'Makefile' in 'ssl.crt' doesn't > > recognize the new style v3 cert from Thawte and thus will not > > create a "hash link" for it. > >Errr.. the Makefile uses "openssl x509" command and this one _DOES_ understand >x509v3 certs, of course. Hmmm... can you post your certificate (not the key, >only the cert, of course) so we can have a more closer look at this particular >cert and to find out why the hash isn't created? > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Compile ar warnings?
While compiling Apache 1.3.9 with mod_ssl 2.4.2 and OpenSSL 0.9.4 I got the following warnings: ar cr libssl.a mod_ssl.o ssl_engine_config.o ssl_engine_compat.o ssl_engine_ds.o ssl_engine_dh.o ssl_engine_init.o ssl_engine_kernel.o ssl_engine_rand.o ssl_engine_io.o ssl_engine_log.o ssl_engine_mutex.o ssl_engine_pphrase.o ssl_engine_scache.o ssl_engine_vars.o ssl_engine_ext.o ssl_expr.o ssl_expr_scan.o ssl_expr_parse.o ssl_expr_eval.o ssl_util.o ssl_util_ssl.o ssl_util_sdbm.o ssl_util_table.o ar: warning: ssl_engine_config.o truncated to ssl_engine_conf ar: warning: ssl_engine_compat.o truncated to ssl_engine_comp ar: warning: ssl_engine_init.o truncated to ssl_engine_init ar: warning: ssl_engine_kernel.o truncated to ssl_engine_kern ar: warning: ssl_engine_rand.o truncated to ssl_engine_rand ar: warning: ssl_engine_log.o truncated to ssl_engine_log. ar: warning: ssl_engine_mutex.o truncated to ssl_engine_mute ar: warning: ssl_engine_pphrase.o truncated to ssl_engine_pphr ar: warning: ssl_engine_scache.o truncated to ssl_engine_scac ar: warning: ssl_engine_vars.o truncated to ssl_engine_vars ar: warning: ssl_engine_ext.o truncated to ssl_engine_ext. ar: warning: ssl_expr_parse.o truncated to ssl_expr_parse. ar: warning: ssl_util_table.o truncated to ssl_util_table. Should I be worried about this? I wish I know what they meant, but I'm not a guru yet... Thanks, Chris __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: X509v3 extensions
The problem was that at the top of the Makefile script in 'ssl.crt' the variable SSL_PROGRAM was undefined. I'm not sure why? I replaced it with: SSL_PROGRAM=/usr/local/bin/openssl And everything works great! Thanks for your help and patience! -Chris At 09:42 PM 9/28/1999 +0200, you wrote: >On Tue, Sep 28, 1999, WSO Support wrote: > > > Yes, here is the cert I'm having the problem with. I've had > > Thawte triple check it, and they have found no problems. This > > is a cert for a client of mine, of course. > > > > -BEGIN CERTIFICATE- > > MIICsDCCAhmgAwIBAgIDAIPNMA0GCSqGSIb3DQEBBAUAMIHEMQswCQYDVQQGEwJa > > QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xHTAb > > BgNVBAoTFFRoYXd0ZSBDb25zdWx0aW5nIGNjMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 > > aW9uIFNlcnZpY2VzIERpdmlzaW9uMRkwFwYDVQQDExBUaGF3dGUgU2VydmVyIENB > > MSYwJAYJKoZIhvcNAQkBFhdzZXJ2ZXItY2VydHNAdGhhd3RlLmNvbTAeFw05OTA5 > > MTMxMzM0NDVaFw0wMDA5MjYxMzM0NDVaMIGRMQswCQYDVQQGEwJVUzEQMA4GA1UE > > CBMHRmxvcmlkYTEOMAwGA1UEBxMFTWlhbWkxGjAYBgNVBAoTEUZyZWVsYW5jZSBT > > dWNjZXNzMSEwHwYDVQQLExhTZWN1cmUgU2VydmljZXMgRGl2aXNpb24xITAfBgNV > > BAMTGHd3dy5mcmVlbGFuY2VzdWNjZXNzLmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sA > > MEgCQQC8bvTfSBgoKNaqMlXUv7Fr4GVNWY/6CuriCtggMeC0BqSKq021bhwfo3DL > > oav8rGbLJBvbbSwa89P0FUvf0pj5AgMBAAGjJTAjMBMGA1UdJQQMMAoGCCsGAQUF > > BwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEALt7627Hs+30X4Kc9 > > k1OyppVfE3i2JcgzpF5ZVF1pd1JCkAiSlKh94EnmIWbgZpImvZSeZgixYhT6bMXS > > 7N53vuMpWKdlMhdXb1aWX2y157aeAlVvGv3jFePejaNzw7SUDdsuplabE8r11n4l > > UMtE1UKmRQBKQua/WLReskiWrVM= > > -END CERTIFICATE- > >Sorry, I've cut & pasted it into a `x.crt' file in a ssl.crt/ directory, ran >`make' there and got no error. Instead I got a correct hash symlink > >lrwxr-xr-x 1 rse wheel 5 Sep 28 21:40 4b136f34.0 -> x.crt > >So it seems like a local problem for you and I've no clue what's the problem >is. Perhaps you've CRLFs in the file or other invisible things? > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: X509v3 extensions
At 02:33 PM 9/30/1999 +0200, you wrote: >On Wed, Sep 29, 1999, WSO Support wrote: > > > The problem was that at the top of the Makefile script > > in 'ssl.crt' the variable SSL_PROGRAM was undefined. I'm > > not sure why? > > > > I replaced it with: > > SSL_PROGRAM=/usr/local/bin/openssl > > > > And everything works great! > > Thanks for your help and patience! > >Confusing. The variable is intentionally undefined there. Because if called >from the top-level the top-level provides this variable (by overiding it on >the "make" command line). And even if you run the "make" locally the embedded >shell script finds a reasonable "openssl" or "ssleay" program in your $PATH. >So either your $PATH was broken or you messed up something else. But ok, now >that it works be happy... I just wanted to say that I cannot fix anything in >this Makefile because it is not broken IMO ;) Two things: 1. Not sure what you mean by "top-level". 2. It was probably finding an old installation of ssleay before it found openssl is my guess. Thanks, Chris __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
