diff options
author | Alberto Gonzalez Iniesta <agi@inittab.org> | 2012-11-05 16:28:09 +0100 |
---|---|---|
committer | Alberto Gonzalez Iniesta <agi@inittab.org> | 2012-11-05 16:28:09 +0100 |
commit | 8dd0350e1607aa30f7a043c8d5ec7a7eeb874115 (patch) | |
tree | 566d0620eb693320cb121dfd93a5675fa704a30b /easy-rsa/1.0/README | |
parent | 349cfa7acb95abe865209a28e417ec74b56f9bba (diff) |
Imported Upstream version 2.3_rc1
Diffstat (limited to 'easy-rsa/1.0/README')
-rw-r--r-- | easy-rsa/1.0/README | 161 |
1 files changed, 0 insertions, 161 deletions
diff --git a/easy-rsa/1.0/README b/easy-rsa/1.0/README deleted file mode 100644 index fd424ef..0000000 --- a/easy-rsa/1.0/README +++ /dev/null @@ -1,161 +0,0 @@ -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 |