You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@covalent.net> on 2001/10/31 17:15:57 UTC
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
I've committed Ralf's patch to ssl-std.conf, since we had 6 of 9 in favor
of a seperated config for ssl.
Y'r all welcome to jump in here, now that we have a good starting point.
Consistify, clarify, etc. I see already that some things such as the
mime types could just as simply go into mime.types, types are always
useful regardless of the current config.
I thought we decided not to rely on -D SSL anymore, or am I mistaken?
If that 'feature' is needed (and they don't know how to uncomment the
LoadModule directive, or they are a static build) I suppose we could
introduce the obverse, -D NOSSL, to let folks hobble along while they
are fixing their config.
Ralf, thank you muchly, for the .conf, and the docs clarification! Your
team's efforts (and all the predecessors before you - Ben et al;) are very
much appreciated.
Bill
----- Original Message -----
From: <wr...@apache.org>
To: <ht...@apache.org>
Sent: Wednesday, October 31, 2001 9:50 AM
Subject: cvs commit: httpd-2.0/docs/conf ssl-std.conf
> wrowe 01/10/31 07:50:53
>
> Modified: . CHANGES
> docs/conf ssl-std.conf
> Log:
> Introduce an Apache mod_ssl initial configuration template
> (ssl.conf, generated from ssl-std.conf). [Ralf S. Engelschall]
>
> Revised Cliff's intro paragraph to point folks at docs until
> docs are provided. [Will Rowe]
>
> Revision Changes Path
> 1.410 +3 -0 httpd-2.0/CHANGES
>
> Index: CHANGES
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/CHANGES,v
> retrieving revision 1.409
> retrieving revision 1.410
> diff -u -r1.409 -r1.410
> --- CHANGES 2001/10/31 03:43:24 1.409
> +++ CHANGES 2001/10/31 15:50:52 1.410
> @@ -1,5 +1,8 @@
> Changes with Apache 2.0.28-dev
>
> + *) Introduce an Apache mod_ssl initial configuration template
> + (ssl.conf, generated from ssl-std.conf). [Ralf S. Engelschall]
> +
> Changes with Apache 2.0.27
>
> *) Fix a truncation bug in how we print the port on the Via: header.
>
>
>
> 1.3 +259 -4 httpd-2.0/docs/conf/ssl-std.conf
>
> Index: ssl-std.conf
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/docs/conf/ssl-std.conf,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- ssl-std.conf 2001/10/31 05:37:06 1.2
> +++ ssl-std.conf 2001/10/31 15:50:53 1.3
> @@ -1,7 +1,262 @@
> #
> -# ssl-std.conf
> +# ssl-std.conf -- Apache httpd configuration for SSL Support
> #
> -# This file is a placeholder for the soon-to-be sample mod_ssl
> -# configuration. Until this is populated, check http://www.modssl.org/
> -# for config examples.
> +
> +# Until documentation is completed, please check http://www.modssl.org/
> +# for additional config examples and module docmentation. Directives
> +# and features of mod_ssl are largely unchanged from the mod_ssl project
> +# for Apache 1.3.
> +
> #
> +# When we also provide SSL we have to listen to the
> +# standard HTTP port (see above) and to the HTTPS port
> +#
> +<IfDefine SSL>
> +Listen 443
> +</IfDefine>
> +
> +#
> +# Dynamic Shared Object (DSO) Support
> +#
> +# To be able to use the functionality of a module which was built as a DSO you
> +# ErrorLog logs/dummy-host.example.com-error_log
> +# CustomLog logs/dummy-host.example.com-access_log common
> +
> +##
> +## SSL Global Context
> +##
> +## All SSL configuration in this context applies both to
> +## the main server and all SSL-enabled virtual hosts.
> +##
> +
> +#
> +# Some MIME-types for downloading Certificates and CRLs
> +#
> +<IfDefine SSL>
> +AddType application/x-x509-ca-cert .crt
> +AddType application/x-pkcs7-crl .crl
> +</IfDefine>
> +
> +<IfModule mod_ssl.c>
> +
> +# Pass Phrase Dialog:
> +# Configure the pass phrase gathering process.
> +# The filtering dialog program (`builtin' is a internal
> +# terminal dialog) has to provide the pass phrase on stdout.
> +SSLPassPhraseDialog builtin
> +
> +# Inter-Process Session Cache:
> +# Configure the SSL Session Cache: First the mechanism
> +# to use and second the expiring timeout (in seconds).
> +#SSLSessionCache none
> +#SSLSessionCache shmht:logs/ssl_scache(512000)
> +#SSLSessionCache shmcb:logs/ssl_scache(512000)
> +SSLSessionCache dbm:logs/ssl_scache
> +SSLSessionCacheTimeout 300
> +
> +# Semaphore:
> +# Configure the path to the mutual exclusion semaphore the
> +# SSL engine uses internally for inter-process synchronization.
> +SSLMutex file:logs/ssl_mutex
> +
> +# Pseudo Random Number Generator (PRNG):
> +# Configure one or more sources to seed the PRNG of the
> +# SSL library. The seed data should be of good random quality.
> +# WARNING! On some platforms /dev/random blocks if not enough entropy
> +# is available. This means you then cannot use the /dev/random device
> +# because it would lead to very long connection times (as long as
> +# it requires to make more entropy available). But usually those
> +# platforms additionally provide a /dev/urandom device which doesn't
> +# block. So, if available, use this one instead. Read the mod_ssl User
> +# Manual for more details.
> +SSLRandomSeed startup builtin
> +SSLRandomSeed connect builtin
> +#SSLRandomSeed startup file:/dev/random 512
> +#SSLRandomSeed startup file:/dev/urandom 512
> +#SSLRandomSeed connect file:/dev/random 512
> +#SSLRandomSeed connect file:/dev/urandom 512
> +
> +# Logging:
> +# The home of the dedicated SSL protocol logfile. Errors are
> +# additionally duplicated in the general error log file. Put
> +# this somewhere where it cannot be used for symlink attacks on
> +# a real server (i.e. somewhere where only root can write).
> +# Log levels are (ascending order: higher ones include lower ones):
> +# none, error, warn, info, trace, debug.
> +SSLLog logs/ssl_engine_log
> +SSLLogLevel info
> +
> +</IfModule>
> +
> +<IfDefine SSL>
> +
> +##
> +## SSL Virtual Host Context
> +##
> +
> +<VirtualHost _default_:443>
> +
> +# General setup for the virtual host
> +DocumentRoot "@@ServerRoot@@/htdocs"
> +ServerName new.host.name
> +ServerAdmin you@your.address
> +ErrorLog logs/error_log
> +TransferLog logs/access_log
> +
> +# SSL Engine Switch:
> +# Enable/Disable SSL for this virtual host.
> +SSLEngine on
> +
> +# SSL Cipher Suite:
> +# List the ciphers that the client is permitted to negotiate.
> +# See the mod_ssl documentation for a complete list.
> +SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
> +
> +# Server Certificate:
> +# Point SSLCertificateFile at a PEM encoded certificate. If
> +# the certificate is encrypted, then you will be prompted for a
> +# pass phrase. Note that a kill -HUP will prompt again. A test
> +# certificate can be generated with `make certificate' under
> +# built time. Keep in mind that if you've both a RSA and a DSA
> +# certificate you can configure both in parallel (to also allow
> +# the use of DSA ciphers, etc.)
> +SSLCertificateFile @@ServerRoot@@/conf/ssl.crt/server.crt
> +#SSLCertificateFile @@ServerRoot@@/conf/ssl.crt/server-dsa.crt
> +
> +# Server Private Key:
> +# If the key is not combined with the certificate, use this
> +# directive to point at the key file. Keep in mind that if
> +# you've both a RSA and a DSA private key you can configure
> +# both in parallel (to also allow the use of DSA ciphers, etc.)
> +SSLCertificateKeyFile @@ServerRoot@@/conf/ssl.key/server.key
> +#SSLCertificateKeyFile @@ServerRoot@@/conf/ssl.key/server-dsa.key
> +
> +# Server Certificate Chain:
> +# Point SSLCertificateChainFile at a file containing the
> +# concatenation of PEM encoded CA certificates which form the
> +# certificate chain for the server certificate. Alternatively
> +# the referenced file can be the same as SSLCertificateFile
> +# when the CA certificates are directly appended to the server
> +# certificate for convinience.
> +#SSLCertificateChainFile @@ServerRoot@@/conf/ssl.crt/ca.crt
> +
> +# Certificate Authority (CA):
> +# Set the CA certificate verification path where to find CA
> +# certificates for client authentication or alternatively one
> +# huge file containing all of them (file must be PEM encoded)
> +# Note: Inside SSLCACertificatePath you need hash symlinks
> +# to point to the certificate files. Use the provided
> +# Makefile to update the hash symlinks after changes.
> +#SSLCACertificatePath @@ServerRoot@@/conf/ssl.crt
> +#SSLCACertificateFile @@ServerRoot@@/conf/ssl.crt/ca-bundle.crt
> +
> +# Certificate Revocation Lists (CRL):
> +# Set the CA revocation path where to find CA CRLs for client
> +# authentication or alternatively one huge file containing all
> +# of them (file must be PEM encoded)
> +# Note: Inside SSLCARevocationPath you need hash symlinks
> +# to point to the certificate files. Use the provided
> +# Makefile to update the hash symlinks after changes.
> +#SSLCARevocationPath @@ServerRoot@@/conf/ssl.crl
> +#SSLCARevocationFile @@ServerRoot@@/conf/ssl.crl/ca-bundle.crl
> +
> +# Client Authentication (Type):
> +# Client certificate verification type and depth. Types are
> +# none, optional, require and optional_no_ca. Depth is a
> +# number which specifies how deeply to verify the certificate
> +# issuer chain before deciding the certificate is not valid.
> +#SSLVerifyClient require
> +#SSLVerifyDepth 10
> +
> +# Access Control:
> +# With SSLRequire you can do per-directory access control based
> +# on arbitrary complex boolean expressions containing server
> +# variable checks and other lookup directives. The syntax is a
> +# mixture between C and Perl. See the mod_ssl documentation
> +# for more details.
> +#<Location />
> +#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
> +# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
> +# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
> +# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
> +# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
> +# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
> +#</Location>
> +
> +# SSL Engine Options:
> +# Set various options for the SSL engine.
> +# o FakeBasicAuth:
> +# Translate the client X.509 into a Basic Authorisation. This means that
> +# the standard Auth/DBMAuth methods can be used for access control. The
> +# user name is the `one line' version of the client's X.509 certificate.
> +# Note that no password is obtained from the user. Every entry in the user
> +# file needs this password: `xxj31ZMTZzkVA'.
> +# o ExportCertData:
> +# This exports two additional environment variables: SSL_CLIENT_CERT and
> +# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
> +# server (always existing) and the client (only existing when client
> +# authentication is used). This can be used to import the certificates
> +# into CGI scripts.
> +# o StdEnvVars:
> +# This exports the standard SSL/TLS related `SSL_*' environment variables.
> +# Per default this exportation is switched off for performance reasons,
> +# because the extraction step is an expensive operation and is usually
> +# useless for serving static content. So one usually enables the
> +# exportation for CGI and SSI requests only.
> +# o CompatEnvVars:
> +# This exports obsolete environment variables for backward compatibility
> +# to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold 2.x. Use this
> +# to provide compatibility to existing CGI scripts.
> +# o StrictRequire:
> +# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
> +# under a "Satisfy any" situation, i.e. when it applies access is denied
> +# and no other module can change it.
> +# o OptRenegotiate:
> +# This enables optimized SSL connection renegotiation handling when SSL
> +# directives are used in per-directory context.
> +#SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
> +<Files ~ "\.(cgi|shtml|phtml|php3?)$">
> + SSLOptions +StdEnvVars
> +</Files>
> +<Directory "@@ServerRoot@@/cgi-bin">
> + SSLOptions +StdEnvVars
> +</Directory>
> +
> +# SSL Protocol Adjustments:
> +# The safe and default but still SSL/TLS standard compliant shutdown
> +# approach is that mod_ssl sends the close notify alert but doesn't wait for
> +# the close notify alert from client. When you need a different shutdown
> +# approach you can use one of the following variables:
> +# o ssl-unclean-shutdown:
> +# This forces an unclean shutdown when the connection is closed, i.e. no
> +# SSL close notify alert is send or allowed to received. This violates
> +# the SSL/TLS standard but is needed for some brain-dead browsers. Use
> +# this when you receive I/O errors because of the standard approach where
> +# mod_ssl sends the close notify alert.
> +# o ssl-accurate-shutdown:
> +# This forces an accurate shutdown when the connection is closed, i.e. a
> +# SSL close notify alert is send and mod_ssl waits for the close notify
> +# alert of the client. This is 100% SSL/TLS standard compliant, but in
> +# practice often causes hanging connections with brain-dead browsers. Use
> +# this only for browsers where you know that their SSL implementation
> +# works correctly.
> +# Notice: Most problems of broken clients are also related to the HTTP
> +# keep-alive facility, so you usually additionally want to disable
> +# keep-alive for those clients, too. Use variable "nokeepalive" for this.
> +# Similarly, one has to force some clients to use HTTP/1.0 to workaround
> +# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
> +# "force-response-1.0" for this.
> +SetEnvIf User-Agent ".*MSIE.*" \
> + nokeepalive ssl-unclean-shutdown \
> + downgrade-1.0 force-response-1.0
> +
> +# Per-Server Logging:
> +# The home of a custom SSL log file. Use this when you want a
> +# compact non-error SSL logfile on a virtual host basis.
> +CustomLog logs/ssl_request_log \
> + "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
> +
> +</VirtualHost>
> +
> +</IfDefine>
> +
>
>
>
>
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 31 October 2001 08:15 am, William A. Rowe, Jr. wrote:
> I've committed Ralf's patch to ssl-std.conf, since we had 6 of 9 in favor
> of a seperated config for ssl.
>
> Y'r all welcome to jump in here, now that we have a good starting point.
> Consistify, clarify, etc. I see already that some things such as the
> mime types could just as simply go into mime.types, types are always
> useful regardless of the current config.
>
> I thought we decided not to rely on -D SSL anymore, or am I mistaken?
> If that 'feature' is needed (and they don't know how to uncomment the
> LoadModule directive, or they are a static build) I suppose we could
> introduce the obverse, -D NOSSL, to let folks hobble along while they
> are fixing their config.
>
> Ralf, thank you muchly, for the .conf, and the docs clarification! Your
> team's efforts (and all the predecessors before you - Ben et al;) are very
> much appreciated.
Why would we want to remove -DSSL? It makes sense to me to force people
to enable SSL specially.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 31 October 2001 09:19 am, Justin Erenkrantz wrote:
> On Wed, Oct 31, 2001 at 09:11:30AM -0800, Ryan Bloom wrote:
> > Just add startssl to apachectl, which adds the -DSSL, same way we do
> > with Apache 1.3. We have to support startssl anyway, because there are
> > going to be a lot of admins with scripts that rely on it. Why are we
> > trying to re-invent the wheel here?
>
> I'm not seeing startssl as an option in apachectl (at least the
> one that we distribute). Where do you see it? -- justin
Apply the mod_ssl patches for 1.3
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Oct 31, 2001 at 09:11:30AM -0800, Ryan Bloom wrote:
> Just add startssl to apachectl, which adds the -DSSL, same way we do
> with Apache 1.3. We have to support startssl anyway, because there are
> going to be a lot of admins with scripts that rely on it. Why are we trying
> to re-invent the wheel here?
I'm not seeing startssl as an option in apachectl (at least the
one that we distribute). Where do you see it? -- justin
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Wednesday, October 31, 2001 11:11 AM
> On Wednesday 31 October 2001 09:04 am, Justin Erenkrantz wrote:
> > On Wed, Oct 31, 2001 at 10:49:33AM -0600, William A. Rowe, Jr. wrote:
> > > OTOH, this doesn't work for static builds of mod_ssl.c, since the user
> > > can't unload modules from Apache 2.0 and re-add in the same way as 1.3
> > > did. So we may wish to provide a mechansm for them to cripple ssl
> > > convenienly.
> >
> > Hmm, sounds like we should have a syntax that says, "Static module foo
> > go away. I don't like you anymore." Can't be too hard, can it? =)
> > Actually, it might be...
>
> No it's easy, but it requires adding back ClearModuleList and AddModule, which
> is just a mess IMHO.
Revision 1.104 / (download) - annotate - [select for diffs] , Sun Jan 21 22:14:16 2001 UTC (9 months, 1 week ago) by rbb
Branch: MAIN
Changes since 1.103: +0 -18 lines
Diff to previous 1.103 (colored)
Remove AddModule and ClearModuleList. Neither directive really makes
much sense anymore, since we use the hooks to order modules correctly.
This also removes the possability that one module will ever register the
same function for the same hook twice.
I'm thinking this was the wrong way to go. Let's consider Win32 or any other
create-process oriented server model. If the user compiles in a bunch of modules
for speed (to avoid per-process resolution of each .dll/.so linkage) so their
individual server processes start up quickly (e.g. MaxRequests is set to 10000 or
so for some mod_perl leakage) but they don't want one of the pre-compiled modules,
we are jammed. I understand the desire to set up each module individually under
unix, but this doesn't work for a Win32 binary very well.
A slick solution might be RemoveModule, which would simply drop one undesireable
module from the precompiled modules list before we invoked the second pass through
the config. If modules postponed hook registration until the second init pass,
the other cited problem goes away. Does that make sense?
> Just add startssl to apachectl, which adds the -DSSL, same way we do
> with Apache 1.3. We have to support startssl anyway, because there are
> going to be a lot of admins with scripts that rely on it. Why are we trying
> to re-invent the wheel here?
Sounds like the way to go, +1.
Bill
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 31 October 2001 09:04 am, Justin Erenkrantz wrote:
> On Wed, Oct 31, 2001 at 10:49:33AM -0600, William A. Rowe, Jr. wrote:
> > OTOH, this doesn't work for static builds of mod_ssl.c, since the user
> > can't unload modules from Apache 2.0 and re-add in the same way as 1.3
> > did. So we may wish to provide a mechansm for them to cripple ssl
> > convenienly.
>
> Hmm, sounds like we should have a syntax that says, "Static module foo
> go away. I don't like you anymore." Can't be too hard, can it? =)
> Actually, it might be...
No it's easy, but it requires adding back ClearModuleList and AddModule, which
is just a mess IMHO.
> > I was under the impression we had decided so. I guess I'm mistaken, and
> > on this entire issue, I'm agnostic. We have a means in Apache 2.0 to
> > change the startup args, so to enable ssl, simply;
> >
> > apache -k config -n ApacheSSL -D SSL -d d:\serverroot -f conf\httpd.conf
> >
> > Really simple, actually.
>
> Yeah, but most people (at least in Unix land) will use apachectl. And,
> from my perspective, adding the -D SSL to apachectl seems like the
> wrong thing to be doing (if you do a make install over an exisiting
> installation, apachectl will get blown away - as does mime.types which
> is *really* pissing me off - but that's another issue). IMHO, this
> should be handled in the config file not in the startup invocation.
> How about adding a config semantic like:
>
> Define SSL
>
> to the config file? It would essentially do the same thing as the
> -D SSL option (and I guess you could continue to do that), but add it
> on the first pass through the config tree (we do it twice right, so if
> we caught it the first time around, when we parse it the second time,
> <IfDefine SSL> works?). -- justin
Just add startssl to apachectl, which adds the -DSSL, same way we do
with Apache 1.3. We have to support startssl anyway, because there are
going to be a lot of admins with scripts that rely on it. Why are we trying
to re-invent the wheel here?
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Oct 31, 2001 at 10:49:33AM -0600, William A. Rowe, Jr. wrote:
> OTOH, this doesn't work for static builds of mod_ssl.c, since the user
> can't unload modules from Apache 2.0 and re-add in the same way as 1.3 did.
> So we may wish to provide a mechansm for them to cripple ssl convenienly.
Hmm, sounds like we should have a syntax that says, "Static module foo
go away. I don't like you anymore." Can't be too hard, can it? =)
Actually, it might be...
> I was under the impression we had decided so. I guess I'm mistaken, and on
> this entire issue, I'm agnostic. We have a means in Apache 2.0 to change the
> startup args, so to enable ssl, simply;
>
> apache -k config -n ApacheSSL -D SSL -d d:\serverroot -f conf\httpd.conf
>
> Really simple, actually.
Yeah, but most people (at least in Unix land) will use apachectl. And,
from my perspective, adding the -D SSL to apachectl seems like the
wrong thing to be doing (if you do a make install over an exisiting
installation, apachectl will get blown away - as does mime.types which
is *really* pissing me off - but that's another issue). IMHO, this
should be handled in the config file not in the startup invocation.
How about adding a config semantic like:
Define SSL
to the config file? It would essentially do the same thing as the
-D SSL option (and I guess you could continue to do that), but add it
on the first pass through the config tree (we do it twice right, so if
we caught it the first time around, when we parse it the second time,
<IfDefine SSL> works?). -- justin
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Justin Erenkrantz" <je...@ebuilt.com>
Sent: Wednesday, October 31, 2001 10:20 AM
> On Wed, Oct 31, 2001 at 10:15:57AM -0600, William A. Rowe, Jr. wrote:
> > I thought we decided not to rely on -D SSL anymore, or am I mistaken?
> > If that 'feature' is needed (and they don't know how to uncomment the
> > LoadModule directive, or they are a static build) I suppose we could
> > introduce the obverse, -D NOSSL, to let folks hobble along while they
> > are fixing their config.
>
> Why not <IfModule mod_ssl.c>? Or, do we want them to explicitly
> enable it by some action? Why not just have those lines commented
> out in ssl-std.conf, but protected by <IfModule>? -- justin
First, +1 on that syntax, irrespective of my next argument ;) I believe
we have the Include ssl.conf already wrapped in an <IfModule > so that
isn't an issue.
OTOH, this doesn't work for static builds of mod_ssl.c, since the user
can't unload modules from Apache 2.0 and re-add in the same way as 1.3 did.
So we may wish to provide a mechansm for them to cripple ssl convenienly.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Wednesday, October 31, 2001 10:27 AM
> Why would we want to remove -DSSL? It makes sense to me to force people
> to enable SSL specially.
I was under the impression we had decided so. I guess I'm mistaken, and on
this entire issue, I'm agnostic. We have a means in Apache 2.0 to change the
startup args, so to enable ssl, simply;
apache -k config -n ApacheSSL -D SSL -d d:\serverroot -f conf\httpd.conf
Really simple, actually.
Bill
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 31 October 2001 08:20 am, Justin Erenkrantz wrote:
> On Wed, Oct 31, 2001 at 10:15:57AM -0600, William A. Rowe, Jr. wrote:
> > I thought we decided not to rely on -D SSL anymore, or am I mistaken?
> > If that 'feature' is needed (and they don't know how to uncomment the
> > LoadModule directive, or they are a static build) I suppose we could
> > introduce the obverse, -D NOSSL, to let folks hobble along while they
> > are fixing their config.
>
> Why not <IfModule mod_ssl.c>? Or, do we want them to explicitly
> enable it by some action? Why not just have those lines commented
> out in ssl-std.conf, but protected by <IfModule>? -- justin
Because IfModule doesn't help if you have a static build with SSL.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/docs/conf ssl-std.conf
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Oct 31, 2001 at 10:15:57AM -0600, William A. Rowe, Jr. wrote:
> I thought we decided not to rely on -D SSL anymore, or am I mistaken?
> If that 'feature' is needed (and they don't know how to uncomment the
> LoadModule directive, or they are a static build) I suppose we could
> introduce the obverse, -D NOSSL, to let folks hobble along while they
> are fixing their config.
Why not <IfModule mod_ssl.c>? Or, do we want them to explicitly
enable it by some action? Why not just have those lines commented
out in ssl-std.conf, but protected by <IfModule>? -- justin