From 349cfa7acb95abe865209a28e417ec74b56f9bba Mon Sep 17 00:00:00 2001 From: Alberto Gonzalez Iniesta Date: Tue, 21 Feb 2012 15:53:40 +0100 Subject: Imported Upstream version 2.2.1 --- easy-rsa/1.0/README | 161 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 easy-rsa/1.0/README (limited to 'easy-rsa/1.0/README') 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 -- cgit v1.2.3