On Thu, Dec 03, 1998 at 05:03:14PM +0100, [EMAIL PROTECTED] wrote:
> On Thu, Dec 03, 1998, [EMAIL PROTECTED] wrote:
> > Full_Name: Jake Buchholz
> > Version: 2.1.1
> > OS: linux 2.0.36
> > Submission from: windowpane.execpc.com (169.207.1.11)
> >
> > mod_ssl 2.1.x doesn't pick up the primary port number for the server
> > from the Listen directive the way 2.0.x appears to have done. Using
> > the Port directive solves the problem, but I'm wondering if this may
> > have been an oversight.
>
> Hmmm... no changes were made in this direction. So how do you know that the
> Port setting is not inherited? What's the effect, i.e. where do you see that
> the port is not correct? And what particular config file are you using?
I'm using a custom set of heirarchical config files:
httpd.conf
(LoadModule stuff)
Include common.conf
(stuff common to HTTP & SSL)
<IfDefine SSL>
Include ssl.conf
Listen 10.3.2.1:443
Include vssl.conf
(virtual host stuff)
</IfDefine>
<IfDefine !SSL>
Include web.conf
Listen 10.3.2.1:80
Include vweb.conf
(virtual host stuff)
</IfDefine>
I start two httpd's, one with -DSSL and one without, each runs as a
separate user/group.
When I had upgraded from 2.0.15 to 2.1.0 (and subsequently 2.1.1), and
tried to start with -DSSL, it never made it past initialization phase 2,
and always aborted with "Ops, can't find server certificate?!".
This was the start of about two weeks of:
making sure my self-signed server cert was signed properly--maybe
2.1.x did some extra cert checking? The cert was okay.
double-checking the 'bsafeglue' library I use to link SSLeay with
BSAFE... strace indicated that after opening, reading, and closing
/dev/urandom, it was exiting. Everything was okay, if there were
any problems I probably would have also seen it in 2.0.x...
Maybe there was something not right with reading or writing to table
that stores certs and keys between inits... There didn't seem to be
anything wrong with those routines.
Maybe BSAFE was doing a little aggressive housecleaning at the second
SSLeay init? My tests came up negative on that one too. I then tried
to pinpoint where exactly it was that I was losing the certificate,
and scattered a number of debug log writes through both initialization
phases. The cert for hostname:443 was being lost _before_ the second
init. Then I noticed something I overlooked all this while:
[info] Init: 1st startup round (still not detached)
[info] Init: Initializing SSLeay library
[info] Init: Loading certificate & private key of SSL-aware server host:0
^^^^^^
[trace] Init: (host:0) unencrypted private key - pass phrase not required
[info] Init: 2nd startup round (already detached)
[info] Init: Initializing SSLeay library
[info] Init: Generating temporary (512 bit) RSA private key
[info] Init: Initializing (virtual) servers for SSL
[info] Init: Configuring server host:0 for SSL protocol
^^^^^^
[trace] Init: (host:443) Creating new SSL context
[trace] Init: (host:443) Configuring permitted SSL ciphers
[trace] Init: (host:443) Configuring server certificate
[error] Init: (host:443) Ops, can't find server certificate?!
^^^^^^^^
It was saving the certificate and key in the table as host:0 and then
trying to read it back later as host:443!
I decided to take a gamble and add one line to my ssl.conf file right
after my Listen directive: "Port 443".
Problem solved... Talk about being relieved that it was working, but
frustrated that it took so long to figure out what was going on...
--
Jake Buchholz http://www.execpc.com/~jake
ExecPC Senior Systems Administrator [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]
