You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2002/12/23 08:40:00 UTC
DO NOT REPLY [Bug 15625] New: -
mention mod_ssl in http://nagoya.apache.org/dist/httpd/binaries/*/*.README
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15625>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15625
mention mod_ssl in http://nagoya.apache.org/dist/httpd/binaries/*/*.README
Summary: mention mod_ssl in
http://nagoya.apache.org/dist/httpd/binaries/*/*.README
Product: Apache httpd-2.0
Version: 2.0.32
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Documentation
AssignedTo: bugs@httpd.apache.org
ReportedBy: hauser@acm.org
As mentioned in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15624, a naive
admin can end up believing to ssl-protect his content under port 443 while it is
still served as http.
Because security as continuously increasing in importance, it should become more
and more the default that httpd's are configured to also include https.
One contributing factor for the possible error described above is that in the
binary distributions, many mod_*.so's are provided with "as is" while mod_ssl.so
is not.
Therefore, my suggestions are:
1) mention in the README files for binary downloads, that mod_ssl needs to be
obtained separately (an provide a link for the how-to-obtain-it)
2) change the file naming on http://nagoya.apache.org/dist/httpd/binaries/*
similarly to the win32 binary on http://httpd.apache.org/download.cgi to
*-no_ssl.tar.gz!
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org