diff --git a/content/tutorials/get-started/set-up-secure-signing.md b/content/tutorials/get-started/set-up-secure-signing.md index 2fb20de703..b5e4c9ba88 100644 --- a/content/tutorials/get-started/set-up-secure-signing.md +++ b/content/tutorials/get-started/set-up-secure-signing.md @@ -51,7 +51,7 @@ In this configuration, you run `rippled` on the machine that generates the trans In this configuration, you run a `rippled` server on a dedicated machine in the same private local area network (LAN) as the machine that generates the transactions to be signed. This configuration lets you assemble transaction instructions on one or more machines with very modest system specs, while using a single dedicated machine for running `rippled`. This may appeal to you if you run your own datacenter or server room. -To use this configuration, set the `rippled` server to accept `wss` and `https` connections within your LAN. You can use a self-signed certificate if you use [certificate pinning](https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning), or you can use a certificate signed by an in-house or well-known Certificate Authority. +To use this configuration, set the `rippled` server to accept `wss` and `https` connections within your LAN. You can use a self-signed certificate if you use [certificate pinning](https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning), or you can use a certificate signed by an in-house or well-known Certificate Authority. Some certificate authorities, such as [Let's Encrypt](https://letsencrypt.org/) issue certificates automatically for free. diff --git a/content/tutorials/manage-the-rippled-server/configuration/api-over-lan.md b/content/tutorials/manage-the-rippled-server/configuration/api-over-lan.md index 1c7361c7ef..89084b048f 100644 --- a/content/tutorials/manage-the-rippled-server/configuration/api-over-lan.md +++ b/content/tutorials/manage-the-rippled-server/configuration/api-over-lan.md @@ -2,7 +2,7 @@ -***TODO: Describe how to set up a self-signed cert and use certificate-pinning on the client side to protect against MITM attacks.*** +***TODO: Describe how to generate a self-signed cert and use certificate-pinning on the client side to protect against MITM attacks AND/OR describe how to use Let's Encrypt to get and renew a ceritificate automatically. In either case, instruct how to configure the server w/ the cert.*** **Warning:** This configuration comes with the additional downside that anyone on the LAN can sniff traffic between your machines, potentially gaining access to your secret keys. Do not use this configuration on a network that may have strangers on it. For example, on the LAN at a colocation facility or cloud host, other customers may be able to get access to the traffic between your machines. If you employ several developers sending test transactions, you could run one `rippled` machine for your whole office, while the developers use cheaper hardware, but any user on your office network could potentially use a packet sniffer to get access to developers' secret keys. ***TODO: with proper certs set up this mostly doesn't apply*** diff --git a/img/secure-signing-dedicated-hardware.png b/img/secure-signing-dedicated-hardware.png index c8b2a86202..366adfecfe 100644 Binary files a/img/secure-signing-dedicated-hardware.png and b/img/secure-signing-dedicated-hardware.png differ diff --git a/img/secure-signing-lan-rippled.png b/img/secure-signing-lan-rippled.png index b3b6388ee5..834d770724 100644 Binary files a/img/secure-signing-lan-rippled.png and b/img/secure-signing-lan-rippled.png differ