1648.html

著名的linux英雄站点的文档打包

                          <TBODY>
                          <TR>
                            <TD>
                              <TABLE cellSpacing=0 cellPadding=3 width="100%" 
                              border=0>
                                <TBODY>
                                <TR>
                                      <TD vAlign=top> 
<p><FONT class=normalfont><B><font color=blue>openssl怎样创建个人证书</font></B></FONT><BR><FONT class=smallfont color=#ff9900>2004-04-23 15:18 pm</FONT><BR><FONT class=normalfont>作者：作者<br>来自：Linux知识宝库<br>联系方式：无名<br><br>#openssl req -new &gt; eric.csr<br>
#openssl x509 -req -in eric.csr -out eric.crt -signkey ca.key -CA ca.cert -CAkey ca.key -CAcreateserial -days 365<br>
怎么我创建的crt不是个人证书,怎样才能创建个人证书.<br>
ftp://www.linuxdoc.org/pub/linux/docs/HOWTO/SSL-Certificates-HOWTO<br>
<br>
<br>
<br>
<br>
SSL Certificates HOWTO<br>
<br>
Franck Martin<br>
<br>
Revision History                                                             <br>
Revision v0.3            2002-05-09            Revised by: FM                <br>
Adding x509v3 extension information - Correcting spelling                    <br>
Revision v0.2            2001-12-06            Revised by: FM                <br>
Adding openssl.cnf file - Adding CRL info from Averroes- Correcting spelling <br>
Revision v0.1            2001-11-18            Revised by: FM                <br>
Creation of the HOWTO                                                        <br>
<br>
<br>
A first hand approach on how to manage a certificate authority (CA), and<br>
issue or sign certificates to be used for secure web, secure e-mail, or<br>
signing code and other usages.<br>
<br>
-----------------------------------------------------------------------------<br>
Table of Contents<br>
1. Generalities<br>
    1.1. Introduction<br>
    1.2. What is SSL and what are Certificates?<br>
    1.3. What about S/Mime or other protocols?<br>
   <br>
   <br>
2. Certificate Management<br>
    2.1. Installation<br>
    2.2. Create a Root Certification Authority Certificate.<br>
    2.3. Create a non root Certification Authority Certificate.<br>
    2.4. Install the CA root certificate as a Trusted Root Certificate<br>
    2.5. Certificate management<br>
    2.6. Securing Internet Protocols.<br>
    2.7. Securing E-mails.<br>
    2.8. Securing Code<br>
   <br>
   <br>
<br>
-----------------------------------------------------------------------------<br>
Chapter 1. Generalities<br>
<br>
1.1. Introduction<br>
<br>
Dear reader, like myself, you have intensively read the man pages of the<br>
applications of the [http://www.openssl.org/] OpenSSL project, and like<br>
myself, you couldn't figure out where to start, and how to work securely with<br>
certificates. Here is the answer to most of your questions.<br>
<br>
This HOWTO will also deal with non-linux applications: there is no use to<br>
issue certificates if you can't use them... All applications won't be listed<br>
here, but please, send me additional paragraphs and corrections. I can be<br>
reached at the following address:[mailto: [e-mail]] [e-mail].<br>
-----------------------------------------------------------------------------<br>
<br>
1.1.1. Disclaimer and Licence<br>
<br>
This document is distributed in the hope that it will be useful, but WITHOUT<br>
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS<br>
FOR A PARTICULAR PURPOSE.<br>
<br>
In short, if the advises given here break the security of your e-commerce<br>
application, then tough luck- it's never our fault. Sorry.<br>
<br>
Copyright (c) 2001 by Franck Martin and others from the openssl-users mailing<br>
list under GFDL (the [http://www.gnu.org/] GNU Free Documentation License).<br>
<br>
Please freely copy and distribute (sell or give away) this document in any<br>
format. It's requested that corrections and/or comments be forwarded to the<br>
document maintainer. You may create a derivative work and distribute it<br>
provided that you:<br>
<br>
 1. Send your derivative work (in the most suitable format such as sgml) to<br>
    the LDP (linux Documentation Project) or the like for posting on the<br>
    Internet. If not the LDP, then let the LDP know where it is available.<br>
   <br>
 2. License the derivative work with this same license or use GPL. Include a<br>
    copyright notice and at least a pointer to the license used.<br>
   <br>
 3. Give due credit to previous authors and major contributors. If you're<br>
    considering making a derived work other than a translation, it's<br>
    requested that you discuss your plans with the current maintainer.<br>
   <br>
<br>
It is also requested that if you publish this HOWTO in hardcopy that you send<br>
the authors some samples for 'review purposes' :-). You may also want to send<br>
something to cook my noodles ;-)<br>
-----------------------------------------------------------------------------<br>
<br>
1.1.2. Prior knowledge<br>
<br>
As indicated in the introduction, this documents is an hand-on HOWTO, and it<br>
is therefore required that you consult the man pages of the OpenSSL software.<br>
You should as well read security books to learn how your security could be<br>
compromised. Certificates are meant to increase the security of your<br>
transactions, it is VERY important that you understand all the security<br>
implications of your actions and what security OpenSSL does not provide.<br>
-----------------------------------------------------------------------------<br>
<br>
1.2. What is SSL and what are Certificates?<br>
<br>
The Secure Socket Layer protocol was created by Netscape to ensure secure<br>
transactions between web servers and browsers. The protocol uses a third<br>
party, a Certificate Authority (CA), to identify one end or both end of the<br>
transactions. This is in short how it works.<br>
<br>
 1. A browser requests a secure page (usually https://).<br>
   <br>
 2. The web server sends its public key with its certificate.<br>
   <br>
 3. The browser checks that the certificate was issued by a trusted party<br>
    (usually a trusted root CA), that the certificate is still valid and that<br>
    the certificate is related to the site contacted.<br>
   <br>
 4. The browser then uses the public key, to encrypt a random symmetric<br>
    encryption key and sends it to the server with the encrypted URL required<br>
    as well as other encrypted http data.<br>
   <br>
 5. The web server decrypts the symmetric encryption key using its private<br>
    key and uses the symmetric key to decrypt the URL and http data.<br>
   <br>
 6. The web server sends back the requested html document and http data<br>
    encrypted with the symmetric key.<br>
   <br>
 7. The browser decrypts the http data and html document using the symmetric<br>
    key and displays the information.<br>
   <br>
<br>
Several concepts have to be understood here.<br>
-----------------------------------------------------------------------------<br>
<br>
1.2.1. Private Key/Public Key:<br>
<br>
The encryption using a private key/public key pair ensures that the data can<br>
be encrypted by one key but can only be decrypted by the other key pair. This<br>
is sometime hard to understand, but believe me it works. The keys are similar<br>
in nature and can be used alternatively: what one key emcrypts, the other key<br>
pair can decrypt. The key pair is based on prime numbers and their length in<br>
terms of bits ensures the difficulty of being able to decrypt the message<br>
without the key pairs. The trick in a key pair is to keep one key secret (the<br>
private key) and to distribute the other key (the public key) to everybody.<br>
Anybody can send you an encrypted message, that only you will be able to<br>
decrypt. You are the only one to have the other key pair, right? In the<br>
opposite , you can certify that a message is only coming from you, because<br>
you have encrypted it with you private key, and only the associated public<br>
key will decrypt it correctly. Beware, in this case the message is not<br>
secured you have only signed it. Everybody has the public key, remember!<br>
<br>
One of the problem left is to know the public key of your correspondent.<br>
Usually you will ask him to send you a non confidential signed message that<br>
will contains his publick key as well as a certificate.<br>
-----------------------------------------------------------------------------<br>
<br>
1.2.2. The Certificate:<br>
<br>
How do you know that you are dealing with the right person or rather the<br>
right web site. Well, someone has taken great length (if they are serious) to<br>
ensure that the web site owners are who they claim to be. This someone, you<br>
have to implicitly trust: you have his/her certificate loaded in your browser<br>
(a root Certificate). A certificate, contains information about the owner of<br>
the certificate, like e-mail address, owner's name, certificate usage,<br>
duration of validity, resource location or Distinguished Name (DN) which<br>
includes the Common Name (CN) (web site address or e-mail address depending<br>
of the usage) and the certificate ID of the person who certifies (signs) this<br>
information. It contains also the public key and finally a hash to ensure<br>
that the certificate has not been tampered with. As you made the choice to<br>
trust the person who signs this certificate, therefore you also trust this<br>
certificate. This is a certificate trust tree or certificate path. Usually<br>
your browser or application has already loaded the root certificate of well<br>
known Certification Authorities (CA) or root CA Certificates. The CA<br>
maintains a list of all signed certificates as well as a list of revoked<br>
certificates. A certificate is insecure until it is signed, as only a signed<br>
certificate cannot be modified. You can sign a certificate using itself, it<br>
is called a self signed certificate. All root CA certificates are self<br>
signed.<br>
-----------------------------------------------------------------------------<br>
<br>
1.2.3. The Symmetric key:<br>
<br>
Well, Private Key/Public Key encryption algorithms are great, but they are<br>
not usually practical. It is asymmetric because you need the other key pair<br>
to decrypt. You can't use the same key to encrypt and decrypt. An algorithm<br>
using the same key to decrypt and encrypt is deemed to have a symmetric key.<br>
A symmetric algorithm is much faster in doing its job than an asymmetric<br>
algorithm. But a symmetric key is potentially highly insecure. If the enemy<br>
gets hold of the key then you have no more secret information. You must<br>
therefore transmit the key to the other party without the enemy getting its<br>
hands on it. As you know, nothing is secure on the Internet. The solution is<br>
to encapsulate the symmetric key inside a message encrypted with an<br>
asymmetric algorithm. You have never transmitted your private key to anybody,<br>
then the message encrypted with the public key is secure (relatively secure,<br>
nothing is certain except death and taxes). The symmetric key is also chosen<br>
randomly, so that if the symmetric secret key is discovered then the next<br>
transaction will be totally different.<br>
-----------------------------------------------------------------------------<br>
<br>
1.2.4. Encryption algorithm:<br>
<br>
There are several encryption algorithms available, using symmetric or<br>
asymmetric methods, with keys of various lengths. Usually, algorithms cannot<br>
be patented, if Henri Poincare had patented his algorithms, then he would<br>
have been able to sue Albert Einstein... So algorithms cannot be patented<br>
except mainly in USA. OpenSSL is developed in a country where algorithms<br>
cannot be patented and where encryption technology is not reserved to state<br>
agencies like military and secret services. During the negotiation between<br>