httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From n.@apache.org
Subject cvs commit: httpd-2.0/docs/manual/ssl ssl_compat.html.en ssl_compat.xml ssl_faq.html.en ssl_faq.xml ssl_howto.html.en ssl_howto.xml ssl_intro.html.en ssl_intro.xml
Date Wed, 23 Apr 2003 22:05:49 GMT
nd          2003/04/23 15:05:49

  Modified:    docs/manual/ssl Tag: APACHE_2_0_BRANCH ssl_compat.html.en
                        ssl_compat.xml ssl_faq.html.en ssl_faq.xml
                        ssl_howto.html.en ssl_howto.xml ssl_intro.html.en
                        ssl_intro.xml
  Log:
  keep typos consistent
  
  Revision  Changes    Path
  No                   revision
  
  
  No                   revision
  
  
  1.3.2.2   +2 -2      httpd-2.0/docs/manual/ssl/ssl_compat.html.en
  
  Index: ssl_compat.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_compat.html.en,v
  retrieving revision 1.3.2.1
  retrieving revision 1.3.2.2
  diff -u -r1.3.2.1 -r1.3.2.2
  --- ssl_compat.html.en	11 Dec 2002 22:27:07 -0000	1.3.2.1
  +++ ssl_compat.html.en	23 Apr 2003 22:05:48 -0000	1.3.2.2
  @@ -28,7 +28,7 @@
   perhaps know, mod_ssl is not the only existing SSL solution for Apache.
   Actually there are four additional major products available on the market: Ben
   Laurie's freely available <a href="http://www.apache-ssl.org/">Apache-SSL</a>
  -(from where mod_ssl were originally derived in 1998), RedHat's commercial <a href="http://www.redhat.com/products/product-details.phtml?id=rhsa">Secure
Web
  +(from where mod_ssl were originally derived in 1998), Red Hat's commercial <a href="http://www.redhat.com/products/product-details.phtml?id=rhsa">Secure
Web
   Server</a> (which is based on mod_ssl), Covalent's commercial <a href="http://raven.covalent.net/">Raven
SSL Module</a> (also based on mod_ssl)
   and finally C2Net's commercial product <a href="http://www.c2.net/products/stronghold/">Stronghold</a>
(based on a
   different evolution branch named Sioux up to Stronghold 2.x and based on
  @@ -53,7 +53,7 @@
   counterpart in mod_ssl are mapped silently while other directives lead to a
   warning message in the logfiles. The currently implemented directive mapping
   is listed in <a href="#table1">Table 1</a>. Currently full backward
  -compatibilty is provided only for Apache-SSL 1.x and mod_ssl 2.0.x.
  +compatibility is provided only for Apache-SSL 1.x and mod_ssl 2.0.x.
   Compatibility to Sioux 1.x and Stronghold 2.x is only partial because of
   special functionality in these interfaces which mod_ssl (still) doesn't
   provide.</p>
  
  
  
  1.3.2.3   +2 -2      httpd-2.0/docs/manual/ssl/ssl_compat.xml
  
  Index: ssl_compat.xml
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_compat.xml,v
  retrieving revision 1.3.2.2
  retrieving revision 1.3.2.3
  diff -u -r1.3.2.2 -r1.3.2.3
  --- ssl_compat.xml	16 Apr 2003 00:22:49 -0000	1.3.2.2
  +++ ssl_compat.xml	23 Apr 2003 22:05:48 -0000	1.3.2.3
  @@ -18,7 +18,7 @@
   perhaps know, mod_ssl is not the only existing SSL solution for Apache.
   Actually there are four additional major products available on the market: Ben
   Laurie's freely available <a href="http://www.apache-ssl.org/">Apache-SSL</a>
  -(from where mod_ssl were originally derived in 1998), RedHat's commercial <a
  +(from where mod_ssl were originally derived in 1998), Red Hat's commercial <a
   href="http://www.redhat.com/products/product-details.phtml?id=rhsa">Secure Web
   Server</a> (which is based on mod_ssl), Covalent's commercial <a
   href="http://raven.covalent.net/">Raven SSL Module</a> (also based on mod_ssl)
  @@ -41,7 +41,7 @@
   counterpart in mod_ssl are mapped silently while other directives lead to a
   warning message in the logfiles. The currently implemented directive mapping
   is listed in <a href="#table1">Table 1</a>. Currently full backward
  -compatibilty is provided only for Apache-SSL 1.x and mod_ssl 2.0.x.
  +compatibility is provided only for Apache-SSL 1.x and mod_ssl 2.0.x.
   Compatibility to Sioux 1.x and Stronghold 2.x is only partial because of
   special functionality in these interfaces which mod_ssl (still) doesn't
   provide.</p>
  
  
  
  1.5.2.6   +9 -9      httpd-2.0/docs/manual/ssl/ssl_faq.html.en
  
  Index: ssl_faq.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_faq.html.en,v
  retrieving revision 1.5.2.5
  retrieving revision 1.5.2.6
  diff -u -r1.5.2.5 -r1.5.2.6
  --- ssl_faq.html.en	8 Jan 2003 20:26:30 -0000	1.5.2.5
  +++ ssl_faq.html.en	23 Apr 2003 22:05:48 -0000	1.5.2.6
  @@ -25,7 +25,7 @@
   </blockquote>
   <p>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 <code><a href="news:comp.infosystems.www.servers.unix">comp.infosystems.www.servers.unix</a></code>
or the mod_ssl Support
  +questions occurred on the Newsgroup <code><a href="news:comp.infosystems.www.servers.unix">comp.infosystems.www.servers.unix</a></code>
or the mod_ssl Support
   Mailing List <code><a href="mailto:modssl-users@modssl.org">modssl-users@modssl.org</a></code>.
They are collected at this place
   to avoid answering the same questions over and over.</p>
   
  @@ -55,7 +55,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.</p>
   
  @@ -87,7 +87,7 @@
       
       <p>Additionally according to a <a href="http://www.apache.org/docs/misc/FAQ.html#year2000">Year
2000
       statement</a> 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.</p>
   
  @@ -100,9 +100,9 @@
       replaced the previous <dfn>CoCom</dfn> 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 <a href="http://www.wassenaar.org/">http://www.wassenaar.org/</a>.</p>
   
       
  @@ -683,7 +683,7 @@
   <h3><a name="load" id="load">Why has my webserver a higher load now that I
run SSL there?</a></h3>
   <p>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.</p>
   
   
  @@ -691,7 +691,7 @@
   the connection, although sometimes it works faster?</a></h3>
   <p>Usually this is caused by using a <code>/dev/random</code> device
for
       <code>SSLRandomSeed</code> 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 <code>SSLRandomSeed</code>.</p>
   
   
  @@ -731,9 +731,9 @@
   I try to connect to my freshly installed server?</a></h3>
   <p>Either you have messed up your <code>SSLCipherSuite</code>
       directive (compare it with the pre-configured example in
  -    <code>httpd.conf-dist</code>) or you have choosen the DSA/DH
  +    <code>httpd.conf-dist</code>) 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 @@
   </blockquote>
   <p>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 <code><a href="news:comp.infosystems.www.servers.unix"
  +questions occurred on the Newsgroup <code><a href="news:comp.infosystems.www.servers.unix"
   >comp.infosystems.www.servers.unix</a></code> or the mod_ssl Support
   Mailing List <code><a href="mailto:modssl-users@modssl.org"
   >modssl-users@modssl.org</a></code>. 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.</p>
   
  @@ -75,7 +75,7 @@
       <p>Additionally according to a <a
       href="http://www.apache.org/docs/misc/FAQ.html#year2000">Year 2000
       statement</a> 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.</p>
   </section>
  @@ -88,9 +88,9 @@
       replaced the previous <dfn>CoCom</dfn> 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 <a
       href="http://www.wassenaar.org/">http://www.wassenaar.org/</a>.</p>
   
  @@ -677,7 +677,7 @@
   <section id="load"><title>Why has my webserver a higher load now that I run
SSL there?</title>
   <p>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.</p>
   </section>
   
  @@ -685,7 +685,7 @@
   the connection, although sometimes it works faster?</title>
   <p>Usually this is caused by using a <code>/dev/random</code> device
for
       <code>SSLRandomSeed</code> 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 <code>SSLRandomSeed</code>.</p>
   </section>
   
  @@ -725,9 +725,9 @@
   I try to connect to my freshly installed server?</title>
   <p>Either you have messed up your <code>SSLCipherSuite</code>
       directive (compare it with the pre-configured example in
  -    <code>httpd.conf-dist</code>) or you have choosen the DSA/DH
  +    <code>httpd.conf-dist</code>) 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:</p>
       <div class="example"><h3>httpd.conf</h3><p><code>
  -      # allow all ciphers for the inital handshake,<br />
  +      # allow all ciphers for the initial handshake,<br />
         # so export browsers can upgrade via SGC facility<br />
         SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
         <br />
  @@ -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
  -    <code>ca.crt</code> and then verifiy the clients against this
  +    <code>ca.crt</code> and then verify the clients against this
       certificate.</p>
       <div class="example"><h3>httpd.conf</h3><p><code>
         # require a client certificate which has to be directly<br />
  @@ -165,7 +165,7 @@
   on certificates but still allow arbitrary clients to access the remaining
   parts of the server?</a></h3>
   
  -    <p>The key is to check for various ingredients of the client certficate.
  +    <p>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 <code class="module"><a
href="../mod/mod_auth.html">mod_auth</a></code> based variant and the <code
class="directive"><a href="../mod/mod_ssl.html#sslrequire">SSLRequire</a></code>
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:</p>
       <example><title>httpd.conf</title>
  -      # allow all ciphers for the inital handshake,<br />
  +      # allow all ciphers for the initial handshake,<br />
         # so export browsers can upgrade via SGC facility<br />
         SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
         <br />
  @@ -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
  -    <code>ca.crt</code> and then verifiy the clients against this
  +    <code>ca.crt</code> and then verify the clients against this
       certificate.</p>
       <example><title>httpd.conf</title>
         # require a client certificate which has to be directly<br />
  @@ -153,7 +153,7 @@
   <title>How can I authenticate only particular clients for a some URLs based
   on certificates but still allow arbitrary clients to access the remaining
   parts of the server?</title>
  -    <p>The key is to check for various ingredients of the client certficate.
  +    <p>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 <module
       >mod_auth</module> based variant and the <directive
  
  
  
  1.3.2.2   +3 -3      httpd-2.0/docs/manual/ssl/ssl_intro.html.en
  
  Index: ssl_intro.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_intro.html.en,v
  retrieving revision 1.3.2.1
  retrieving revision 1.3.2.2
  diff -u -r1.3.2.1 -r1.3.2.2
  --- ssl_intro.html.en	11 Dec 2002 22:27:07 -0000	1.3.2.1
  +++ ssl_intro.html.en	23 Apr 2003 22:05:49 -0000	1.3.2.2
  @@ -40,7 +40,7 @@
   SSL and Certificates using SSLeay</a> from <a href="http://home.earthlink.net/~fjhirsch/">Frederick
J. Hirsch</a>, of The
   Open Group Research Institute, which was published in <a href="http://www.ora.com/catalog/wjsum97/">Web
Security: A Matter of
   Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
  -Please send any postive feedback to <a href="mailto:hirsch@fjhirsch.com">Frederick
Hirsch</a> (the original
  +Please send any positive feedback to <a href="mailto:hirsch@fjhirsch.com">Frederick
Hirsch</a> (the original
   article author) and all negative feedback to <a href="mailto:rse@engelschall.com">Ralf
S. Engelschall</a> (the
   <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>
author).</p>
   </div>
  @@ -122,7 +122,7 @@
   substituting one message for another while maintaining the same digest.</p>
   <p>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.</p>
   
   
  @@ -185,7 +185,7 @@
       <tr><th>Administrative Information</th>
           <td>Version, Serial Number</td></tr>
       <tr><th>Extended Information</th>
  -        <td>Basic Contraints, Netscape Flags, etc.</td></tr>
  +        <td>Basic Constraints, Netscape Flags, etc.</td></tr>
       </table>
       
   
  
  
  
  1.3.2.3   +3 -3      httpd-2.0/docs/manual/ssl/ssl_intro.xml
  
  Index: ssl_intro.xml
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_intro.xml,v
  retrieving revision 1.3.2.2
  retrieving revision 1.3.2.3
  diff -u -r1.3.2.2 -r1.3.2.3
  --- ssl_intro.xml	16 Apr 2003 00:22:49 -0000	1.3.2.2
  +++ ssl_intro.xml	23 Apr 2003 22:05:49 -0000	1.3.2.3
  @@ -33,7 +33,7 @@
   Open Group Research Institute, which was published in <a
   href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
   Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
  -Please send any postive feedback to <a
  +Please send any positive feedback to <a
   href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> (the original
   article author) and all negative feedback to <a
   href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the
  @@ -111,7 +111,7 @@
   substituting one message for another while maintaining the same digest.</p>
   <p>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.</p>
   </section>
   
  @@ -175,7 +175,7 @@
       <tr><th>Administrative Information</th>
           <td>Version, Serial Number</td></tr>
       <tr><th>Extended Information</th>
  -        <td>Basic Contraints, Netscape Flags, etc.</td></tr>
  +        <td>Basic Constraints, Netscape Flags, etc.</td></tr>
       </table>
       </section>
   
  
  
  

Mime
View raw message