From f29c9adab423eab58a60d26cde510cffc8db2ca3 Mon Sep 17 00:00:00 2001 From: Chris Pepper Date: Mon, 24 Mar 2003 01:54:27 +0000 Subject: [PATCH] Many simple typos. RedHat's -> Red Hat's, underlaying -> underlying the Netherlands, the United Kingdom, the United States Additionally, ssl_howto.xml uses 'coherences' unclearly -- should this be 'interactions?. ssl_compat.xml uses 'compactified', which isn't a real word, but I'm not sure what it's intended to mean. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@99052 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/ssl/ssl_compat.xml | 4 ++-- docs/manual/ssl/ssl_faq.xml | 18 +++++++++--------- docs/manual/ssl/ssl_howto.xml | 6 +++--- docs/manual/ssl/ssl_intro.xml | 6 +++--- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/manual/ssl/ssl_compat.xml b/docs/manual/ssl/ssl_compat.xml index c1fd0acb03..f7465edb4a 100644 --- a/docs/manual/ssl/ssl_compat.xml +++ b/docs/manual/ssl/ssl_compat.xml @@ -19,7 +19,7 @@ Here we talk about backward compatibility to other SSL solutions. As you 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 Apache-SSL -(from where mod_ssl were originally derived in 1998), RedHat's commercial Secure Web Server (which is based on mod_ssl), Covalent's commercial Raven SSL Module (also based on mod_ssl) @@ -42,7 +42,7 @@ solutions we do an on-the-fly mapping: directives which have a direct 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 Table 1. 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.

diff --git a/docs/manual/ssl/ssl_faq.xml b/docs/manual/ssl/ssl_faq.xml index 27fe959afa..8f9889ced1 100644 --- a/docs/manual/ssl/ssl_faq.xml +++ b/docs/manual/ssl/ssl_faq.xml @@ -16,7 +16,7 @@ he poses the right questions.

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 @@ -43,7 +43,7 @@ author.

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.

@@ -76,7 +76,7 @@ author.

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.

@@ -89,9 +89,9 @@ author.

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/.

@@ -678,7 +678,7 @@ Hosting to identify different SSL virtual hosts?
Why has my webserver a higher load now that I run SSL there?

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.

@@ -686,7 +686,7 @@ Hosting to identify different SSL virtual hosts? 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.

@@ -726,9 +726,9 @@ shared cipher'' errors? I try to connect to my freshly installed server?

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 diff --git a/docs/manual/ssl/ssl_howto.xml b/docs/manual/ssl/ssl_howto.xml index f74dfe4c87..69961e55f0 100644 --- a/docs/manual/ssl/ssl_howto.xml +++ b/docs/manual/ssl/ssl_howto.xml @@ -70,7 +70,7 @@ only, but allows export browsers to upgrade to stronger encryption? strong encryption or have to upgrade to strong encryption, but are not allowed to keep the export ciphers. The following does the trick:

httpd.conf - # 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

@@ -121,7 +121,7 @@ all my clients? 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.

httpd.conf # require a client certificate which has to be directly
@@ -154,7 +154,7 @@ parts of the server? 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? -

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_auth_basic based variant and the Frederick J. Hirsch, of The Open Group Research Institute, which was published in Web Security: A Matter of Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997. -Please send any postive feedback to Frederick Hirsch (the original article author) and all negative feedback to Ralf S. Engelschall (the @@ -112,7 +112,7 @@ messages which create the same digest -- thus eliminating the possibility of substituting one message for another while maintaining the same digest.

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.

@@ -176,7 +176,7 @@ certificates are used for authentication.

Administrative Information Version, Serial Number Extended Information - Basic Contraints, Netscape Flags, etc. + Basic Constraints, Netscape Flags, etc. -- 2.40.0