openssl怎样创建个人证书
#openssl req -new > eric.csr#openssl x509 -req -in eric.csr -out eric.crt -signkey ca.key -CA ca.cert -CAkey ca.key -CAcreateserial -days 365
怎么我创建的crt不是个人证书,怎样才能创建个人证书.
ftp://www.linuxdoc.org/pub/linux/docs/HOWTO/SSL-Certificates-HOWTO
SSL Certificates HOWTO
Franck Martin
Revision History
Revision v0.3 2002-05-09 Revised by: FM
Adding x509v3 extension information - Correcting spelling
Revision v0.2 2001-12-06 Revised by: FM
Adding openssl.cnf file - Adding CRL info from Averroes- Correcting spelling
Revision v0.1 2001-11-18 Revised by: FM
Creation of the HOWTO
A first hand approach on how to manage a certificate authority (CA), and
issue or sign certificates to be used for secure web, secure e-mail, or
signing code and other usages.
-----------------------------------------------------------------------------
Table of Contents
1. Generalities
1.1. Introduction
1.2. What is SSL and what are Certificates?
1.3. What about S/Mime or other protocols?
2. Certificate Management
2.1. Installation
2.2. Create a Root Certification Authority Certificate.
2.3. Create a non root Certification Authority Certificate.
2.4. Install the CA root certificate as a Trusted Root Certificate
2.5. Certificate management
2.6. Securing Internet Protocols.
2.7. Securing E-mails.
2.8. Securing Code
-----------------------------------------------------------------------------
Chapter 1. Generalities
1.1. Introduction
Dear reader, like myself, you have intensively read the man pages of the
applications of the [http://www.openssl.org/] OpenSSL 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.
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:[mailto: franck@sopac.org] franck@sopac.org.
-----------------------------------------------------------------------------
1.1.1. Disclaimer and Licence
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.
In short, if the advises given here break the security of your e-commerce
application, then tough luck- it's never our fault. Sorry.
Copyright (c) 2001 by Franck Martin and others from the openssl-users mailing
list under GFDL (the [http://www.gnu.org/] GNU Free Documentation License).
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:
1. 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.
2. License the derivative work with this same license or use GPL. Include a
copyright notice and at least a pointer to the license used.
3. Give due credit to previous authors and major contributors. If you're
considering 易做图 a derived work other than a translation, it's
requested that you discuss your plans with the current maintainer.
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 ;-)
-----------------------------------------------------------------------------
1.1.2. Prior knowledge
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.
-----------------------------------------------------------------------------
1.2. What is SSL and what are Certificates?
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.
1. A browser requests a secure page (usually https://).
2. The web server sends its public key with its certificate.
3. 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.
4. 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.
5. The web server decrypts the symmetric encryption key using its private
key and uses the symmetric key to decrypt the URL and http data.
6. The web server sends back the requested html document and http data
encrypted with the symmetric key.
7. The browser decrypts the http data and html document using the symmetric
key and displays the information.
Several concepts have to be understood here.
-----------------------------------------------------------------------------
1.2.1. Private Key/Public Key:
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 emcrypts, 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 messag