Return-Path:
This chapter is a collection of frequently asked questions (FAQ) and
corresponding answers following the popular USENET tradition. Most of these
-questions occured on the Newsgroup comp.infosystems.www.servers.unix
or the mod_ssl Support
+questions occurred on the Newsgroup comp.infosystems.www.servers.unix
or the mod_ssl Support
Mailing List modssl-users@modssl.org
. They are collected at this place
to avoid answering the same questions over and over.
Additionally according to a Year 2000 statement from the Apache Group, the Apache webserver is Year 2000 - compliant, too. But whether OpenSSL or the underlaying Operating System + compliant, too. But whether OpenSSL or the underlying Operating System (either a Unix or Win32 platform) is Year 2000 compliant is a different question which cannot be answered here.
@@ -100,9 +100,9 @@ replaced the previous CoCom regime. 33 countries are signatories: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, - Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic + Luxembourg, the Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, - Switzerland, Turkey, Ukraine, United Kingdom and United States. For more + Switzerland, Turkey, Ukraine, the United Kingdom and the United States. For more details look at http://www.wassenaar.org/. @@ -683,7 +683,7 @@Because SSL uses strong cryptographic encryption and this needs a lot of number crunching. And because when you request a webpage via HTTPS even - the images are transfered encrypted. So, when you have a lot of HTTPS + the images are transferred encrypted. So, when you have a lot of HTTPS traffic the load increases.
@@ -691,7 +691,7 @@ the connection, although sometimes it works faster?Usually this is caused by using a /dev/random
device for
SSLRandomSeed
which is blocking in read(2) calls if not
- enough entropy is available. Read more about this problem in the refernce
+ enough entropy is available. Read more about this problem in the reference
chapter under SSLRandomSeed
.
Either you have messed up your SSLCipherSuite
directive (compare it with the pre-configured example in
- httpd.conf-dist
) or you have choosen the DSA/DH
+ httpd.conf-dist
) or you have chosen the DSA/DH
algorithms instead of RSA when you generated your private key
- and ignored or overlooked the warnings. If you have choosen
+ and ignored or overlooked the warnings. If you have chosen
DSA/DH, then your server no longer speaks RSA-based SSL ciphers
(at least not until you also configure an additional RSA-based
certificate/key pair). But current browsers like NS or IE only speak
1.5.2.7 +9 -9 httpd-2.0/docs/manual/ssl/ssl_faq.xml
Index: ssl_faq.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_faq.xml,v
retrieving revision 1.5.2.6
retrieving revision 1.5.2.7
diff -u -r1.5.2.6 -r1.5.2.7
--- ssl_faq.xml 16 Apr 2003 00:22:49 -0000 1.5.2.6
+++ ssl_faq.xml 23 Apr 2003 22:05:48 -0000 1.5.2.7
@@ -15,7 +15,7 @@
This chapter is a collection of frequently asked questions (FAQ) and
corresponding answers following the popular USENET tradition. Most of these
-questions occured on the Newsgroup comp.infosystems.www.servers.unix
or the mod_ssl Support
Mailing List modssl-users@modssl.org
. They are collected at this place
@@ -42,7 +42,7 @@
Laurie's development cycle it then was re-assembled from scratch for
Apache 1.3.0 by merging the old mod_ssl 1.x with the newer Apache-SSL
1.18. From this point on mod_ssl lived its own life as mod_ssl v2. The
- first publically released version was mod_ssl 2.0.0 from August 10th,
+ first publicly released version was mod_ssl 2.0.0 from August 10th,
1998. As of this writing (August 1999) the current mod_ssl version
is 2.4.0.
Additionally according to a Year 2000 statement from the Apache Group, the Apache webserver is Year 2000 - compliant, too. But whether OpenSSL or the underlaying Operating System + compliant, too. But whether OpenSSL or the underlying Operating System (either a Unix or Win32 platform) is Year 2000 compliant is a different question which cannot be answered here.
@@ -88,9 +88,9 @@ replaced the previous CoCom regime. 33 countries are signatories: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, - Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic + Luxembourg, the Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, - Switzerland, Turkey, Ukraine, United Kingdom and United States. For more + Switzerland, Turkey, Ukraine, the United Kingdom and the United States. For more details look at http://www.wassenaar.org/. @@ -677,7 +677,7 @@Because SSL uses strong cryptographic encryption and this needs a lot of number crunching. And because when you request a webpage via HTTPS even - the images are transfered encrypted. So, when you have a lot of HTTPS + the images are transferred encrypted. So, when you have a lot of HTTPS traffic the load increases.
Usually this is caused by using a /dev/random
device for
SSLRandomSeed
which is blocking in read(2) calls if not
- enough entropy is available. Read more about this problem in the refernce
+ enough entropy is available. Read more about this problem in the reference
chapter under SSLRandomSeed
.
Either you have messed up your SSLCipherSuite
directive (compare it with the pre-configured example in
- httpd.conf-dist
) or you have choosen the DSA/DH
+ httpd.conf-dist
) or you have chosen the DSA/DH
algorithms instead of RSA when you generated your private key
- and ignored or overlooked the warnings. If you have choosen
+ and ignored or overlooked the warnings. If you have chosen
DSA/DH, then your server no longer speaks RSA-based SSL ciphers
(at least not until you also configure an additional RSA-based
certificate/key pair). But current browsers like NS or IE only speak
1.3.2.3 +3 -3 httpd-2.0/docs/manual/ssl/ssl_howto.html.en
Index: ssl_howto.html.en
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_howto.html.en,v
retrieving revision 1.3.2.2
retrieving revision 1.3.2.3
diff -u -r1.3.2.2 -r1.3.2.3
--- ssl_howto.html.en 11 Dec 2002 22:27:07 -0000 1.3.2.2
+++ ssl_howto.html.en 23 Apr 2003 22:05:49 -0000 1.3.2.3
@@ -83,7 +83,7 @@
strong encryption or have to upgrade to strong encryption, but are
not allowed to keep the export ciphers. The following does the trick:
- # allow all ciphers for the inital handshake,
+ # allow all ciphers for the initial handshake,
# so export browsers can upgrade via SGC facility
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
@@ -132,7 +132,7 @@
situation), as it's the case for instance in an Intranet, you can
use plain certificate authentication. All you have to do is to
create client certificates signed by your own CA certificate
- ca.crt
and then verifiy the clients against this
+ ca.crt
and then verify the clients against this
certificate.
The key is to check for various ingredients of the client certficate.
+ The key is to check for various ingredients of the client certificate.
Usually this means to check the whole or part of the Distinguished
Name (DN) of the Subject. For this two methods exists: The
# require a client certificate which has to be directly
@@ -165,7 +165,7 @@
on certificates but still allow arbitrary clients to access the remaining
parts of the server?
- mod_auth
based variant and the SSLRequire
variant. The first method is
good when the clients are of totally different type, i.e. when their
1.3.2.4 +3 -3 httpd-2.0/docs/manual/ssl/ssl_howto.xml
Index: ssl_howto.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_howto.xml,v
retrieving revision 1.3.2.3
retrieving revision 1.3.2.4
diff -u -r1.3.2.3 -r1.3.2.4
--- ssl_howto.xml 16 Apr 2003 00:22:49 -0000 1.3.2.3
+++ ssl_howto.xml 23 Apr 2003 22:05:49 -0000 1.3.2.4
@@ -69,7 +69,7 @@
strong encryption or have to upgrade to strong encryption, but are
not allowed to keep the export ciphers. The following does the trick:
+ # allow all ciphers for the initial handshake,
# so export browsers can upgrade via SGC facility
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
@@ -120,7 +120,7 @@
situation), as it's the case for instance in an Intranet, you can
use plain certificate authentication. All you have to do is to
create client certificates signed by your own CA certificate
- ca.crt
and then verifiy the clients against this
+ ca.crt
and then verify the clients against this
certificate.
The key is to check for various ingredients of the client certficate. +
The key is to check for various ingredients of the client certificate.
Usually this means to check the whole or part of the Distinguished
Name (DN) of the Subject. For this two methods exists: The mod_ssl
author).
Another challenge that Alice faces is finding a way to send the digest to the bank securely; when this is achieved, the integrity of the associated message -is assured. One way to to this is to include the digest in a digital +is assured. One way to do this is to include the digest in a digital signature.
@@ -185,7 +185,7 @@Another challenge that Alice faces is finding a way to send the digest to the bank securely; when this is achieved, the integrity of the associated message -is assured. One way to to this is to include the digest in a digital +is assured. One way to do this is to include the digest in a digital signature.
@@ -175,7 +175,7 @@