Merge pull request #62 from jasonleschnik/patch-1

Update SSL-Certificates-HOWTO.sgml

LDP/howto/docbook/SSL-Certificates-HOWTO.sgml

@@ -38,7 +38,7 @@
 <chapter><title>Generalities</title><sect1><title>Introduction</title><para>Dear reader, like myself, you have intensively read the man pages of the applications of the <ulink url="http://www.openssl.org/">OpenSSL</ulink> project, and like myself, you couldn't figure out where to start, and how to work securely with certificates. Here is the answer to most of your questions.</para><para>This HOWTO will also deal with non-linux applications: there is no use to issue certificates if you can't use them... All applications won't be listed here, but please, send me additional paragraphs and corrections. I can be reached at the following address:<ulink url="mailto: franck@sopac.org">franck@sopac.org</ulink>.</para><para>This HOWTO is published on <ulink url="http://www.tldp.org/">The Linux Documentation Project</ulink> this is where you will find the lastest version of this document.</para><sect2><title>Disclaimer and Licence</title><para>This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.</para><para>In short, if the advises given here break the security of your e-commerce application, then tough luck- it's never our fault. Sorry.</para><para>Copyright (c) 2001 by Franck Martin and others from the openssl-users mailing list under GFDL (the <ulink url="http://www.gnu.org/">GNU</ulink> Free Documentation License).</para><para>Please freely copy and distribute (sell or give away) this document in any format. It's requested that corrections and/or comments be forwarded to the document maintainer. You may create a derivative work and distribute it provided that you:</para><orderedlist><listitem><para>Send your derivative work (in the most suitable format such as sgml) to the LDP (Linux Documentation Project) or the like for posting on the Internet. If not the LDP, then let the LDP know where it is available. </para></listitem><listitem><para>License the derivative work with this same license or use GPL. Include a copyright notice and at least a pointer to the license used. </para></listitem><listitem><para>Give due credit to previous authors and major contributors. If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.</para></listitem></orderedlist><para>It is also requested that if you publish this HOWTO in hardcopy that you send the authors some samples for 'review purposes' :-). You may also want to send something to cook my noodles ;-)</para></sect2>
 <sect2><title>Prior knowledge</title><para>As indicated in the introduction, this documents is an hand-on HOWTO, and it is therefore required that you consult the man pages of the OpenSSL software. You should as well read security books to learn how your security could be compromised. Certificates are meant to increase the security of your transactions, it is VERY important that you understand all the security implications of your actions and what security OpenSSL does not provide.</para></sect2>
 </sect1>
-<sect1><title>What is SSL and what are Certificates?</title><para>The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works. </para><orderedlist><listitem><para>A browser requests a secure page (usually https://).</para></listitem><listitem><para>The web server sends its public key with its certificate.</para></listitem><listitem><para>The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.</para></listitem><listitem><para>The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.</para></listitem><listitem><para>The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data. </para></listitem><listitem><para>The web server sends back the requested html document and http data encrypted with the symmetric key. </para></listitem><listitem><para>The browser decrypts the http data and html document using the symmetric key and displays the information.</para></listitem></orderedlist><para>Several concepts have to be understood here.</para><sect2><title>Private Key/Public Key:</title><para>The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. This is sometime hard to understand, but believe me it works. The keys are similar in nature and can be used alternatively: what one key encrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite , you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key, remember!</para><para>One of the problem left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his publick key as well as a certificate.</para><programlisting><![CDATA[Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message
+<sect1><title>What is SSL and what are Certificates?</title><para>The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works. </para><orderedlist><listitem><para>A browser requests a secure page (usually https://).</para></listitem><listitem><para>The web server sends its public key with its certificate.</para></listitem><listitem><para>The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.</para></listitem><listitem><para>The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.</para></listitem><listitem><para>The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data. </para></listitem><listitem><para>The web server sends back the requested html document and http data encrypted with the symmetric key. </para></listitem><listitem><para>The browser decrypts the http data and html document using the symmetric key and displays the information.</para></listitem></orderedlist><para>Several concepts have to be understood here.</para><sect2><title>Private Key/Public Key:</title><para>The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. This is sometime hard to understand, but believe me it works. The keys are similar in nature and can be used alternatively: what one key encrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite , you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key, remember!</para><para>The problem left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his publick key as well as a certificate.</para><programlisting><![CDATA[Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message
 ]]></programlisting></sect2>
 <sect2><title>The Certificate:</title><para>How do you know that you are dealing with the right person or rather the right web site. Well, someone has taken great length (if they are serious) to ensure that the web site owners are who they claim to be. This someone, you have to implicitly trust: you have his/her certificate loaded in your browser (a root Certificate). A certificate, contains information about the owner of the certificate, like e-mail address, owner's name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who signs this certificate, therefore you also trust this certificate. This is a certificate trust tree or certificate path. Usually your browser or application has already loaded the root certificate of well known Certification Authorities (CA) or root CA Certificates. The CA maintains a list of all signed certificates as well as a list of revoked certificates. A certificate is insecure until it is signed, as only a signed certificate cannot be modified. You can sign a certificate using itself, it is called a self signed certificate. All root CA certificates are self signed.</para><programlisting><![CDATA[Certificate: 
 ]]><![CDATA[    Data: