Hi, folks. I've run across a wierd problem -- https/SSL works fine when accessed from the machine running httpd, but is unavailable from all others.
Software versions: Apache 1.3.37/mod_ssl-2.8.28-1.3.37/OpenSSL 0.9.8b
Running 'http' on port 8118, 'https' on port 8119
I get positive results from openssl's "s_client" when I connect to
8119 from the server's command line:
$ openssl s_client -connect webdev-gold:8119
CONNECTED(00000003)
depth=0 /C=US/ST=Oregon/L=Medford/O=Musey's
Pal/OU=WebDev/CN=webdev-gold.musiciansfriend.com/[EMAIL PROTECTED]
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Oregon/L=Medford/O=Musey's
Pal/OU=WebDev/CN=webdev-gold.musiciansfriend.com/[EMAIL PROTECTED]
< SNIP >
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID:
9D8989B47E6EE3546426AFC100348052D900956A40E0C33AAB41019D71CF515E
Session-ID-ctx:
Master-Key:
EF1AC496532EE1B8EF0F63988AB7CED1F05F9EAB8675DD76DC54A6DC6E91410C12B9808C8567B803838137B79089591C
Key-Arg : None
Krb5 Principal: None
Start Time: 1221497972
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
To verify this a bit further, I (again, from the server's command
line) made use of the 'lynx' browswer to attempt accessing https on
port 8119 -- this worked, as well.
Next thing I tried was running the same "s_client" command from my
workstation's command line:
(openssl version 0.9.8g))
$ openssl s_client -connect webdev-gold:8119 -state -debug
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x80c1340 [0x80c22f8] (124 bytes => 124 (0x7C))
0000 - 80 7a 01 03 01 00 51 00-00 00 20 00 00 39 00 00 .z....Q... ..9..
0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............
0020 - 00 00 33 00 00 32 00 00-2f 00 00 07 05 00 80 03 ..3..2../.......
0030 - 00 80 00 00 05 00 00 04-01 00 80 00 00 15 00 00 ................
0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 [EMAIL PROTECTED]
0050 - 00 00 06 04 00 80 00 00-03 02 00 80 78 79 d0 f1 ............xy..
0060 - 49 80 86 36 2c 4a 72 b0-9a 3d 73 a6 d7 2e e9 78 I..6,Jr..=s....x
0070 - 05 4e 73 b7 84 12 ea 38-18 b1 41 c2 .Ns....8..A.
SSL_connect:SSLv2/v3 write client hello A
read from 0x80c1340 [0x80c7858] (7 bytes => 7 (0x7))
0000 - 3c 21 44 4f 43 54 59 <!DOCTY
SSL_connect:error in SSLv2/v3 read server hello A
16389:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol:s23_clnt.c:583:
And the corresponding entry from the server's error log:
[Mon Sep 15 10:04:30 2008] [error] [client 172.16.70.182] Invalid
method in request \\x80t\\x01\\x03\\x01
Seems to be working from the server, but not from outside it. So I
thought I'd best be sure that I wasn't doing
something silly like listening only on the loopback address or something:
tcp 0 0 0.0.0.0:8118 0.0.0.0:*
LISTEN
tcp 0 0 0.0.0.0:8119 0.0.0.0:*
LISTEN
Which I think proves that httpd isn't confining itself to a single
network interface.
I've spent a couple of hours googling on this, and discovered that
while the the error shown in the Apache log excerpt is quite common,
the situation I'm describing is not. Any insights, thoughts, and
suggestions would be appreciated, as I feel I've taken this as far as
I can on my own.
I am attaching the relevant httpd.conf file -- in gzipped format -- on
the chance it may prove helpful.
Thank you.
-John
sample_httpd.conf.gz
Description: GNU Zip compressed data
