[deployment-guide/comm-rel: 651/727] Updated the An Overview of Certificates and Security section.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 13:20:25 UTC 2010
commit d2e6245ce0f53128dfdb654a69a435f05f011991
Author: Jaromir Hradilek <jhradile at redhat.com>
Date: Tue Sep 14 15:34:38 2010 +0200
Updated the An Overview of Certificates and Security section.
I have also moved Types of Certificates under the above section.
en-US/The_Apache_HTTP_Server.xml | 248 ++++++++++++++++++-------------------
1 files changed, 121 insertions(+), 127 deletions(-)
---
diff --git a/en-US/The_Apache_HTTP_Server.xml b/en-US/The_Apache_HTTP_Server.xml
index 32a87ce..63cde56 100644
--- a/en-US/The_Apache_HTTP_Server.xml
+++ b/en-US/The_Apache_HTTP_Server.xml
@@ -2942,147 +2942,141 @@ ErrorDocument 404 /404-not_found.html</screen>
</para>
<section id="s2-apache-mod_ssl-certificates">
<title>An Overview of Certificates and Security</title>
- <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.
+ Secure communication is based on the use of keys. In conventional or <firstterm>symmetric cryptography</firstterm>, both ends of the transaction have the same key they can use to decode each other's transmissions. On the other hand, in public or <firstterm>asymmetric cryptography</firstterm>, two keys co-exist: a <firstterm>private key</firstterm> that is kept a secret, and a <firstterm>public key</firstterm> that is usually shared with the public. While the data encoded with the public key can only be decoded with the private key, data encoded with the private key can in turn only be decoded with the public key.
</para>
- </section>
- <section id="s2-secureserver-certs">
- <title>Types of Certificates</title>
<para>
- If you installed your secure server from the RPM package provided by Red Hat, a randomly generated private key and a test certificate are generated and put into the appropriate directories. Before you begin using your secure server, however, you must generate your own key and obtain a certificate which correctly identifies your server.
+ To provide secure communications using SSL, an SSL server must use a digital certificate signed by a <firstterm>Certificate Authority</firstterm> (<acronym>CA</acronym>). The certificate lists various attributes of the server (that is, the server hostname, the name of the company, its location, etc.), and the signature produced using the CA's private key. This signature ensures that a particular certificate authority has issued the certificate, and that the certificate has not been modified in any way.
</para>
<para>
- You need a key and a certificate to operate your secure server — which means that you can either generate a self-signed certificate or purchase a CA-signed certificate from a CA. What are the differences between the two?
+ When a web browser establishes a new SSL connection, it checks the certificate provided by the web server. If the certificate does not have a signature from a trusted CA, or if the hostname listed in the certificate does not match the hostname used to establish the connection, it refuses to communicate with the server and usually presents a user with an appropriate error message.
</para>
<para>
- A CA-signed certificate provides two important capabilities for your server:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Browsers (usually) automatically recognize the certificate and allow a secure connection to be made, without prompting the user.
- </para>
- </listitem>
- <listitem>
- <para>
- When a CA issues a signed certificate, they are guaranteeing the identity of the organization that is providing the webpages to the browser.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- If your secure server is being accessed by the public at large, your secure server needs a certificate signed by a CA so that people who visit your website know that the website is owned by the organization who claims to own it. Before signing a certificate, a CA verifies that the organization requesting the certificate was actually who they claimed to be.
- </para>
- <para>
- Most Web browsers that support SSL have a list of CAs whose certificates they automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection.
+ By default, most web browsers are configured to trust a set of widely used certificate authorities. Because of this, an appropriate CA should be chosen when setting up a secure server, so that target users can trust the connection, otherwise they will be presented with an error messge, and will have to accept the certificate manually. Since encouraging users to override certificate errors can allow an attacker to intercept the connection, you should use a trusted CA whenever possible. For more information on this, see <xref linkend="table-apache-mod_ssl-certificates-authorities" />.
</para>
+ <table id="table-apache-mod_ssl-certificates-authorities">
+ <title>CA lists for most common web browsers</title>
+ <tgroup cols="2">
+ <colspec colname="option" colnum="1" colwidth="20*" />
+ <colspec colname="description" colnum="2" colwidth="60*" />
+ <thead>
+ <row>
+ <entry>
+ Web Browser
+ </entry>
+ <entry>
+ Link
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ <application>Mozilla Firefox</application>
+ </entry>
+ <entry>
+ <ulink url="http://www.mozilla.org/projects/security/certs/included/">Mozilla root CA list</ulink>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <application>Opera</application>
+ </entry>
+ <entry>
+ <ulink url="http://my.opera.com/rootstore/blog/">The Opera Rootstore</ulink>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <application>Internet Explorer</application>
+ </entry>
+ <entry>
+ <ulink url="http://support.microsoft.com/kb/931125">Windows root certificate program members</ulink>.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
<para>
- You can generate a self-signed certificate for your secure server, but be aware that a self-signed certificate does not provide the same functionality as a CA-signed certificate. A self-signed certificate is not automatically recognized by most Web browsers and does not provide any guarantee concerning the identity of the organization that is providing the website. A CA-signed certificate provides both of these important capabilities for a secure server. If your secure server is to be used in a production environment, a CA-signed certificate is recommended.
+ When setting up an SSL server, you need to generate a certificate request and a private key, and then send the certificate request, proof of the company's identity, and payment to a certificate authority. Once the CA verifies the certificate request and your identity, it will send you a signed certificate you can use with your server.
</para>
+ <!--
<para>
- The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:
+ 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>
- <orderedlist continuation="restarts" inheritnum="ignore">
- <listitem>
- <para>
- Create an encryption private and public key pair.
- </para>
- </listitem>
- <listitem>
- <para>
- Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.
- </para>
- </listitem>
- <listitem>
- <para>
- Send the certificate request, along with documents proving your identity, to a CA. Red Hat does not make recommendations on which certificate authority to choose. Your decision may be based on your past experiences, on the experiences of your friends or colleagues, or purely on monetary factors.
- </para>
- <para>
- Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them.
- </para>
- </listitem>
- <listitem>
- <para>
- When the CA is satisfied that you are indeed who you claim to be, they provide you with a digital certificate.
- </para>
- </listitem>
- <listitem>
- <para>
- Install this certificate on your secure server and begin handling secure transactions.
- </para>
- </listitem>
- </orderedlist>
<para>
- Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key. Refer to <xref linkend="s2-secureserver-generatingkey" /> for instructions.
+ 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>
+ -->
+ <section id="s2-secureserver-certs">
+ <title>Types of Certificates</title>
+ <para>
+ If you installed your secure server from the RPM package provided by Red Hat, a randomly generated private key and a test certificate are generated and put into the appropriate directories. Before you begin using your secure server, however, you must generate your own key and obtain a certificate which correctly identifies your server.
+ </para>
+ <para>
+ You need a key and a certificate to operate your secure server — which means that you can either generate a self-signed certificate or purchase a CA-signed certificate from a CA. What are the differences between the two?
+ </para>
+ <para>
+ A CA-signed certificate provides two important capabilities for your server:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Browsers (usually) automatically recognize the certificate and allow a secure connection to be made, without prompting the user.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ When a CA issues a signed certificate, they are guaranteeing the identity of the organization that is providing the webpages to the browser.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ If your secure server is being accessed by the public at large, your secure server needs a certificate signed by a CA so that people who visit your website know that the website is owned by the organization who claims to own it. Before signing a certificate, a CA verifies that the organization requesting the certificate was actually who they claimed to be.
+ </para>
+ <para>
+ Most Web browsers that support SSL have a list of CAs whose certificates they automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection.
+ </para>
+ <para>
+ You can generate a self-signed certificate for your secure server, but be aware that a self-signed certificate does not provide the same functionality as a CA-signed certificate. A self-signed certificate is not automatically recognized by most Web browsers and does not provide any guarantee concerning the identity of the organization that is providing the website. A CA-signed certificate provides both of these important capabilities for a secure server. If your secure server is to be used in a production environment, a CA-signed certificate is recommended.
+ </para>
+ <para>
+ The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:
+ </para>
+ <orderedlist continuation="restarts" inheritnum="ignore">
+ <listitem>
+ <para>
+ Create an encryption private and public key pair.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Send the certificate request, along with documents proving your identity, to a CA. Red Hat does not make recommendations on which certificate authority to choose. Your decision may be based on your past experiences, on the experiences of your friends or colleagues, or purely on monetary factors.
+ </para>
+ <para>
+ Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ When the CA is satisfied that you are indeed who you claim to be, they provide you with a digital certificate.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Install this certificate on your secure server and begin handling secure transactions.
+ </para>
+ </listitem>
+ </orderedlist>
+ <para>
+ Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key. Refer to <xref linkend="s2-secureserver-generatingkey" /> for instructions.
+ </para>
+ </section>
</section>
<section id="s2-apache-mod_ssl-enabling">
<title>Enabling the <systemitem class="resource">mod_ssl</systemitem> Module</title>
More information about the docs-commits
mailing list