summaryrefslogtreecommitdiff
path: root/easy-rsa/1.0/README
diff options
context:
space:
mode:
authorAlberto Gonzalez Iniesta <agi@inittab.org>2012-11-05 16:28:09 +0100
committerAlberto Gonzalez Iniesta <agi@inittab.org>2012-11-05 16:28:09 +0100
commit8dd0350e1607aa30f7a043c8d5ec7a7eeb874115 (patch)
tree566d0620eb693320cb121dfd93a5675fa704a30b /easy-rsa/1.0/README
parent349cfa7acb95abe865209a28e417ec74b56f9bba (diff)
Imported Upstream version 2.3_rc1
Diffstat (limited to 'easy-rsa/1.0/README')
-rw-r--r--easy-rsa/1.0/README161
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