Skip to content

Commit

Permalink
updated tls
Browse files Browse the repository at this point in the history
  • Loading branch information
bloxster committed Oct 30, 2024
1 parent 52d3506 commit b216062
Showing 1 changed file with 122 additions and 1 deletion.
123 changes: 122 additions & 1 deletion src/advanced/tls-authentication.md
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>

0 comments on commit b216062

Please sign in to comment.