summaryrefslogtreecommitdiff
path: root/src/openvpn/easy-rsa/README
diff options
context:
space:
mode:
authorOthmar Gsenger <otti@anytun.org>2008-04-12 11:38:42 +0000
committerOthmar Gsenger <otti@anytun.org>2008-04-12 11:38:42 +0000
commitfffd213c8cba2135afda493d797c41c10354770e (patch)
treebb5eea1b12871d8c3fed0e687d83be3e504d11b2 /src/openvpn/easy-rsa/README
parentsvn cleanup (diff)
big svn cleanup
Diffstat (limited to 'src/openvpn/easy-rsa/README')
-rw-r--r--src/openvpn/easy-rsa/README161
1 files changed, 161 insertions, 0 deletions
diff --git a/src/openvpn/easy-rsa/README b/src/openvpn/easy-rsa/README
new file mode 100644
index 0000000..fd424ef
--- /dev/null
+++ b/src/openvpn/easy-rsa/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