version 2.1_beta1

git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@581 e7ae566f-a301-0410-adde-c780ea21d3b5

1 files changed, 161 insertions, 0 deletions

diff --git a/easy-rsa/1.0/README b/easy-rsa/1.0/README
new file mode 100644
index 0000000..fd424ef
--- /dev/null
+++ b/easy-rsa/1.0/README
@@ -0,0 +1,161 @@
+This is a small RSA key management package,
+based on the openssl command line tool, that
+can be found in the easy-rsa subdirectory
+of the OpenVPN distribution.
+
+These are reference notes.  For step
+by step instructions, see the HOWTO:
+
+http://openvpn.net/howto.html
+
+INSTALL
+
+1. Edit vars.
+2. Set KEY_CONFIG to point to the openssl.cnf file
+   included in this distribution.
+3. Set KEY_DIR to point to a directory which will
+   contain all keys, certificates, etc.  This
+   directory need not exist, and if it does,
+   it will be deleted with rm -rf, so BE
+   CAREFUL how you set KEY_DIR.
+4. (Optional) Edit other fields in vars
+   per your site data.  You may want to
+   increase KEY_SIZE to 2048 if you are
+   paranoid and don't mind slower key
+   processing, but certainly 1024 is
+   fine for testing purposes.  KEY_SIZE
+   must be compatible across both peers
+   participating in a secure SSL/TLS
+   connection.
+5  . vars
+6. ./clean-all
+7. As you create certificates, keys, and
+   certificate signing requests, understand that
+   only .key files should be kept confidential.
+   .crt and .csr files can be sent over insecure
+   channels such as plaintext email.
+8. You should never need to copy a .key file
+   between computers.  Normally each computer
+   will have its own certificate/key pair.
+
+BUILD YOUR OWN ROOT CERTIFICATE AUTHORITY (CA) CERTIFICATE/KEY
+
+1. ./build-ca
+2. ca.crt and ca.key will be built in your KEY_DIR
+   directory
+
+BUILD AN INTERMEDIATE CERTIFICATE AUTHORITY CERTIFICATE/KEY (optional)
+
+1. ./build-inter inter
+2. inter.crt and inter.key will be built in your KEY_DIR
+   directory and signed with your root certificate.
+
+BUILD DIFFIE-HELLMAN PARAMETERS (necessary for
+the server end of a SSL/TLS connection).
+
+1. ./build-dh
+
+BUILD A CERTIFICATE SIGNING REQUEST (If
+you want to sign your certificate with a root
+certificate controlled by another individual
+or organization, or residing on a different machine).
+
+1. Get ca.crt (the root certificate) from your
+   certificate authority.  Though this
+   transfer can be over an insecure channel, to prevent
+   man-in-the-middle attacks you must confirm that
+   ca.crt was not tampered with.  Large CAs solve this
+   problem by hardwiring their root certificates into
+   popular web browsers.  A simple way to verify a root
+   CA is to call the issuer on the telephone and confirm
+   that the md5sum or sha1sum signatures on the ca.crt
+   files match (such as with the command: "md5sum ca.crt").
+2. Choose a name for your certificate such as your computer
+   name.  In our example we will use "mycert".
+3. ./build-req mycert
+4. You can ignore most of the fields, but set
+   "Common Name" to something unique such as your
+   computer's host name.  Leave all password
+   fields blank, unless you want your private key
+   to be protected by password.  Using a password
+   is not required -- it will make your key more secure
+   but also more inconvenient to use, because you will
+   need to supply your password anytime the key is used.
+   NOTE: if you are using a password, use ./build-req-pass
+   instead of ./build-req
+5. Your key will be written to $KEY_DIR/mycert.key
+6. Your certificate signing request will be written to
+   to $KEY_DIR/mycert.csr
+7. Email mycert.csr to the individual or organization
+   which controls the root certificate.  This can be
+   done over an insecure channel.
+8. After the .csr file is signed by the root certificate
+   authority, you will receive a file mycert.crt
+   (your certificate).  Place mycert.crt in your
+   KEY_DIR directory.
+9. The combined files of mycert.crt, mycert.key,
+   and ca.crt can now be used to secure one end of
+   an SSL/TLS connection.
+
+SIGN A CERTIFICATE SIGNING REQUEST
+
+1. ./sign-req mycert
+2. mycert.crt will be built in your KEY_DIR
+   directory using mycert.csr and your root CA
+   file as input.
+
+BUILD AND SIGN A CERTIFICATE SIGNING REQUEST
+USING A LOCALLY INSTALLED ROOT CERTIFICATE/KEY -- this
+script generates and signs a certificate in one step,
+but it requires that the generated certificate and private
+key files be copied to the destination host over a
+secure channel.
+
+1. ./build-key mycert (no password protection)
+2. OR ./build-key-pass mycert (with password protection)
+3. OR ./build-key-pkcs12 mycert (PKCS #12 format)
+4. OR ./build-key-server mycert (with nsCertType=server)
+5. mycert.crt and mycert.key will be built in your
+   KEY_DIR directory, and mycert.crt will be signed
+   by your root CA. If ./build-key-pkcs12 was used a
+   mycert.p12 file will also be created including the
+   private key, certificate and the ca certificate.
+
+IMPORTANT
+
+To avoid a possible Man-in-the-Middle attack where an authorized
+client tries to connect to another client by impersonating the
+server, make sure to enforce some kind of server certificate
+verification by clients.  There are currently four different ways
+of accomplishing this, listed in the order of preference:
+
+(1) Build your server certificates with the build-key-server
+    script.  This will designate the certificate as a
+    server-only certificate by setting nsCertType=server.
+    Now add the following line to your client configuration:
+      
+    ns-cert-type server
+
+    This will block clients from connecting to any
+    server which lacks the nsCertType=server designation
+    in its certificate, even if the certificate has been
+    signed by the CA which is cited in the OpenVPN configuration
+    file (--ca directive).
+
+(2) Use the --tls-remote directive on the client to
+    accept/reject the server connection based on the common
+    name of the server certificate.
+
+(3) Use a --tls-verify script or plugin to accept/reject the
+    server connection based on a custom test of the server
+    certificate's embedded X509 subject details.
+
+(4) Sign server certificates with one CA and client certificates
+    with a different CA.  The client config "ca" directive should
+    reference the server-signing CA while the server config "ca"
+    directive should reference the client-signing CA.
+
+NOTES
+
+Show certificate fields:
+  openssl x509 -in cert.crt -text