-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
bloxster
committed
Oct 30, 2024
1 parent
52d3506
commit b216062
Showing
1 changed file
with
122 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,125 @@ | ||
# TLS Authentication | ||
|
||
|
||
<img class="center" src="/images/WIP.png" alt="work in progress"> | ||
TLS authentication can be enabled to ensure communication integrity and access control to the Erigon node. | ||
|
||
At a high level, the process consists of: | ||
|
||
1. Generate the Certificate Authority (CA) key pair. | ||
2. Create the Certificate Authority certificate file | ||
3. Generate a key pair | ||
4. Create the certificate file for each public key | ||
5. Deploy the files to each instance | ||
6. Run Erigon and RPCdaemon with the correct tags | ||
|
||
The following is a detailed description of how to use the **OpenSSL** suite of tools to secure the connection between a remote Erigon node and a remote or local RPCdaemon. | ||
|
||
The same procedure applies to any Erigon component you wish to run separately; it is recommended to name the files accordingly. | ||
|
||
<div class="warning"> | ||
|
||
**Warning** | ||
|
||
To maintain a high level of security, it is recommended to create all the keys locally and then copy the 3 required files remotely to the remote node. | ||
</div> | ||
|
||
To install openssl open your terminal and paste: | ||
|
||
```bash | ||
sudo apt install openssl | ||
``` | ||
|
||
## 1. Generating the key pair for the Certificate Authority (CA) | ||
|
||
Generate the CA key pair using Elliptic Curve (as opposed to RSA). The generated CA key will be in the `CA-key.pem` file. | ||
<div class="warning"> | ||
|
||
**Warning** | ||
|
||
Access to this file will allow anyone to later add any new instance key pair to the “cluster of trust”, so keep this file safe. | ||
</div> | ||
|
||
```bash | ||
openssl ecparam -name prime256v1 -genkey -noout -out CA-key.pem | ||
``` | ||
|
||
## 2. Creating the CA certificate file | ||
|
||
Create CA self-signed certificate (this command will ask questions, the answers aren’t important for now, but at least the first one needs to be filled in with some data). The file created by this command will be called ``CA-cert.pem``: | ||
|
||
```bash | ||
openssl req -x509 -new -nodes -key CA-key.pem -sha256 -days 3650 -out CA-cert.pem | ||
``` | ||
|
||
## 3. Generating a key pair | ||
|
||
Generate a key pair for the Erigon node: | ||
|
||
```bash | ||
openssl ecparam -name prime256v1 -genkey -noout -out erigon-key.pem | ||
``` | ||
|
||
Also generate a key pair for the RPC daemon: | ||
|
||
```bash | ||
openssl ecparam -name prime256v1 -genkey -noout -out RPC-key.pem | ||
``` | ||
|
||
## 4. Creating the certificate file for each public key | ||
|
||
Now create the Certificate Signing Request for the Erigon key pair, and from this request, produce the certificate (signed by the CA) that proves that this key is now part of the “cluster of trust”: | ||
|
||
```bash | ||
openssl x509 -req -in erigon.csr -CA CA-cert.pem -CAkey CA-key.pem -CAcreateserial -out erigon.crt -days 3650 -sha256 | ||
``` | ||
|
||
Then create the certificate signing request for the RPC daemon key pair: | ||
|
||
```bash | ||
openssl req -new -key RPC-key.pem -out RPC.csr | ||
``` | ||
|
||
From this request, produce the certificate (signed by CA), proving that this key is now part of the “cluster of trust”: | ||
|
||
```bash | ||
openssl x509 -req -in RPC.csr -CA CA-cert.pem -CAkey CA-key.pem -CAcreateserial -out RPC.crt -days 3650 -sha256 | ||
``` | ||
|
||
## 5. Deploy the files on each instance | ||
|
||
These three files must be placed in the /erigon folder on the machine running Erigon: | ||
|
||
``CA-cert.pem`` | ||
|
||
``erigon-key.pem`` | ||
|
||
``erigon.crt`` | ||
|
||
On the RPCdaemon machine, these three files must also be placed in the /erigon folder: | ||
|
||
``CA-cert.pem`` | ||
|
||
``RPC key.pem`` | ||
|
||
``RPC.crtv`` | ||
|
||
## 6. Run Erigon and RPCdaemon with the correct tags | ||
|
||
Once all the files have been moved, Erigon must be run with these additional options: | ||
|
||
```bash | ||
--tls --tls.cacert CA-cert.pem --tls.key erigon-key.pem --tls.cert erigon.crt | ||
``` | ||
|
||
While the RPC daemon must be started with these additional options: | ||
|
||
```bash | ||
--tls.key RPC-key.pem --tls.cacert CA-cert.pem --tls.cert RPC.crt | ||
``` | ||
|
||
<div class="warning"> | ||
|
||
**Warning** | ||
|
||
Normally, the "client side" (in our case, the RPCdaemon) will check that the server's host name matches the "Common Name" attribute of the "server" certificate. At this time, this check is disabled and will be re-enabled when the instructions above on how to correctly generate Common Name certificates are updated. For example, if you are running the Erigon instance in the Google Cloud, you will need to specify the internal IP in the -private.api.addr option. You will also need to open the firewall on the port you use to connect to the Erigon instances. | ||
</div> |