diff --git a/.gitignore b/.gitignore
index 547ad2481..405017d58 100644
--- a/.gitignore
+++ b/.gitignore
@@ -23,7 +23,6 @@ _testmain.go
 *.test
 bin/
 .vagrant/
-
-
 website/npm-debug.log
-
+*.old
+*.attr
diff --git a/website/source/docs/agent/encryption.html.markdown b/website/source/docs/agent/encryption.html.markdown
index b4c396e52..94710b6dd 100644
--- a/website/source/docs/agent/encryption.html.markdown
+++ b/website/source/docs/agent/encryption.html.markdown
@@ -8,11 +8,12 @@ sidebar_current: "docs-agent-encryption"
 
 The Consul agent supports encrypting all of its network traffic. The exact
 method of this encryption is described on the
-[encryption internals page](/docs/internals/security.html).
+[encryption internals page](/docs/internals/security.html). There are two
+seperate systems, one for gossip traffic and one for RPC.
 
-## Enabling Encryption
+## Gossip Encryption
 
-Enabling encryption only requires that you set an encryption key when
+Enabling gossip encryption only requires that you set an encryption key when
 starting the Consul agent. The key can be set using the `-encrypt` flag
 on `consul agent` or by setting the `encrypt_key` in a configuration file.
 It is advisable to put the key in a configuration file to avoid other users
@@ -47,3 +48,30 @@ $ consul agent -data=/tmp/consul -encrypt=cg8StVXbQJ0gPvMd9o7yrg==
 All nodes within a Consul cluster must share the same encryption key in
 order to send and receive cluster information.
 
+# RPC Encryption with TLS
+
+Consul supports using TLS to verify the authenticity of servers and clients. For this
+to work, Consul requires that all clients and servers have key pairs that are generated
+by a single Certificate Authority. This can be a private CA, used only internally. The
+CA then signs keys for each of the agents. [Here](https://langui.sh/2009/01/18/openssl-self-signed-ca/)
+is a tutorial on generating both a CA and signing keys using OpenSSL.
+
+There are a number of things to consider when setting up TLS for Consul. Either we can
+use TLS just to verify the authenticity of the servers, or we can also verify the authenticity
+of clients. The former can be used to prevent unauthorized access. This behavior is controlled
+using either the `verify_incoming` and `verify_outgoing` [options](/docs/agent/options.html).
+
+If `verify_outgoing` is set, then agents verify the authenticity of Consuls for outgoing
+connections. This means server nodes must present a certificate signed by the `ca_file` that
+the agent has. This option must be set on all agents, and there must be a `ca_file` provided
+to check the certificate against. If this is set, then all server nodes must have an appropriate
+key pair set using `cert_file` and `key_file`.
+
+If `verify_incoming` is set, then the servers verify the authenticity of all incoming
+connections. Servers will also disallow any non-TLS connections. If this is set, then all
+clients must have a valid key pair set using `cert_file` and `key_file`. To force clients to
+use TLs, `verify_outgoing` must also be set.
+
+TLS is used to secure the RPC calls between agents, but gossip between nodes is done over UDP
+and is secured using a symmetric key. See above for enabling gossip encryption.
+