[deployment-guide/comm-rel: 637/727] Applied the SSL server section patch by Joe Orton.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 13:19:12 UTC 2010
commit ad24e71bef9a6506825e51a260e809cfb5c5c46b
Author: Jaromir Hradilek <jhradile at redhat.com>
Date: Fri Sep 10 14:41:30 2010 +0200
Applied the SSL server section patch by Joe Orton.
en-US/The_Apache_HTTP_Server.xml | 84 +++++++++++++++++++++++++++++++-------
1 files changed, 69 insertions(+), 15 deletions(-)
---
diff --git a/en-US/The_Apache_HTTP_Server.xml b/en-US/The_Apache_HTTP_Server.xml
index 1670acd..e981282 100644
--- a/en-US/The_Apache_HTTP_Server.xml
+++ b/en-US/The_Apache_HTTP_Server.xml
@@ -2969,21 +2969,75 @@ ErrorDocument 404 /404-not_found.html</screen>
</section>
<section id="s2-secureserver-overview-certs">
<title>An Overview of Certificates and Security</title>
- <para>
- Your secure server provides security using a combination of the Secure Sockets Layer (SSL) protocol and (in most cases) a digital certificate from a Certificate Authority (CA). SSL handles the encrypted communications as well as the mutual authentication between browsers and your secure server. The CA-approved digital certificate provides authentication for your secure server (the CA puts its reputation behind its certification of your organization's identity). When your browser is communicating using SSL encryption, the <computeroutput>https://</computeroutput> prefix is used at the beginning of the Uniform Resource Locator (URL) in the navigation bar.
- </para>
- <para>
- Encryption depends upon the use of keys (think of them as secret encoder/decoder rings in data format). In conventional or symmetric cryptography, both ends of the transaction have the same key, which they use to decode each other's transmissions. In public or asymmetric cryptography, two keys co-exist: a public key and a private key. A person or an organization keeps their private key a secret and publishes their public key. Data encoded with the public key can only be decoded with the private key; data encoded with the private key can only be decoded with the public key.
- </para>
- <para>
- To set up your secure server, use public cryptography to create a public and private key pair. In most cases, you send your certificate request (including your public key), proof of your company's identity, and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server.
- </para>
- <para>
- A secure server uses a certificate to identify itself to Web browsers. You can generate your own certificate (called a "self-signed" certificate), or you can get a certificate from a CA. A certificate from a reputable CA guarantees that a website is associated with a particular company or organization.
- </para>
- <para>
- Alternatively, you can create your own self-signed certificate. Note, however, that self-signed certificates should not be used in most production environments. Self-signed certificates are not automatically accepted by a user's browser — users are prompted by the browser to accept the certificate and create the secure connection. Refer to <xref linkend="s2-secureserver-certs" /> for more information on the differences between self-signed and CA-signed certificates.
- </para>
+ <para>Secure communication depends upon the use of keys (think of them as secret encoder/decoder rings in data format). In conventional or symmetric cryptography, both ends of the transaction have the same key, which they use to decode each other's transmissions. In public or asymmetric cryptography, two keys co-exist: a public key and a private key. A person or an organization keeps their private key a secret and publishes their public key. Data encoded with the public key can only be decoded with the private key; data encoded with the private key can only be decoded with the public key.</para>
+
+ <para>To provide secure communications using SSL, an SSL server
+ must use a digital certificate which is signed by a Certificate
+ Authority (CA). A server certificate lists various attributes
+ of the server (such as company name and location) - notably the
+ hostname of the server - and the signature produced using the
+ CA's private key. The signature can be used to verify both that
+ a particular CA has issued the certificate, and that the
+ certificate has not been modified since being signed.</para>
+
+ <para>When a web browser establishes a new SSL connection, the
+ server presents it with a certificate. The web browser must
+ verify the certificate to provide data integrity for the
+ connection. This is done by checking that the server
+ certificate has a signature from a trusted CA, and that the
+ hostname listed in the certificate matches the hostname used to
+ establish the connection. If either of these checks fail, the
+ web browser will refuse to communicate with the server and will
+ typically present an error page to the user.</para>
+
+ <para>Web browsers are configured to trust a set of CAs which
+ will issue certificates to SSL servers on the Internet.
+ Browsers can be configured to trust a CA operated privately
+ within a company or organisation. When you are setting up a
+ secure server, an appropriate CA must be chosen which is known
+ to be trusted by the browsers of all your target users. For a
+ public SSL server on the Internet, this will typically be a
+ commercial CA such as VeriSign. If you choose a CA which is not
+ trusted by the browsers run by your target users, those users
+ will be presented with error pages when visiting your SSL
+ server. They may be able to override the error pages and use
+ the site, but this requires them to manually verify the
+ certificate signature. In fact, encouraging users to manually
+ override certificate errors may train them into overriding a
+ <emphasis>genuine error</emphasis> which would occur when an SSL
+ connection is intercepted by an attacker.</para>
+
+ <note>
+ <title>Note</title>
+
+ <para>When choosing a Certificate Authority for a public SSL
+ server, check that the CA is trusted by popular web browsers.
+ The following sites give more information about the trusted
+ ("root") CA lists for some popular browsers:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><ulink
+ url="http://support.microsoft.com/kb/931125">Windows root
+ certificate program members</ulink> (for Internet
+ Explorer).</para>
+ </listitem>
+ <listitem>
+ <para><ulink
+ url="http://www.mozilla.org/projects/security/certs/included/">Mozilla
+ root CA list</ulink> (for Firefox)</para>
+ </listitem>
+ <listitem>
+ <para><ulink url="http://my.opera.com/rootstore/blog/">The Opera Rootstore</ulink>.</para>
+ </listitem>
+ </itemizedlist>
+ </note>
+
+ <para>When setting up your secure server, you create a certificate request and a private key. In most cases, you send your certificate request (which includes your public key), proof of your company's identity, and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your SSL server.</para>
+
+ <para>For testing purposes, a self-signed certificate can be
+ used which does not contain a signature from a CA. Note, however, that self-signed certificates should not be used in most production environments. Self-signed certificates are not automatically accepted by a user's browser — users are prompted by the browser to accept the certificate and create the secure connection. Refer to <xref
+ linkend="s2-sslserver-certs"/> for more information on the differences between self-signed and CA-signed certificates.</para>
<para>
Once you have a self-signed certificate or a signed certificate from the CA of your choice, you must install it on your secure server.
</para>
More information about the docs-commits
mailing list