search

sentinel-official / dvpn-node

The official Sentinel dVPN node
Apache License 2.0
108 stars 33 forks source link

"unknown certificate" #183

Open rick-deckard-2049 opened 10 months ago

rick-deckard-2049 commented 10 months ago

I'm trying to launch a dvpn node on a rpi4 using docker on 32bit rpi os. The image I'm running is wajatmaka/sentinel-arm7-debian:v0.7.1 which is the one referred to on the Sentinel docs site. I know this is no an official Sentinel site but it is currently linked to from the Sentinel docs site soo...

Everything works perfectly fine and the node starts up. However, as soon as I try to call the wireguard tcp endpoint (port 7777) i get the following tls errors:

2024/01/14 12:26:49 http: TLS handshake error from <ip>:52680: remote error: tls: unknown certificate
2024/01/14 12:26:49 http: TLS handshake error from <ip>:52681: remote error: tls: unknown certificate
2024/01/14 12:26:52 http: TLS handshake error from <ip>:52683: remote error: tls: unknown certificate
...

The command I used for generating the cert files is:

openssl req -new \
    --verbose \
    -newkey ec \
    -pkeyopt ec_paramgen_curve:prime256v1 \
    -x509 \
    -sha256 \
    -days 365 \
    -nodes \
    -out ${HOME_NODE}/.sentinelnode/tls.crt \
    -keyout ${HOME_NODE}/.sentinelnode/tls.key \
    -subj "/C=SE/ST=SE/L=./O=SE/OU=./CN=."

The node account has been funded so that's not the issue. I guess the problem is 100% tls related. What could be wrong here?

UPDATE This is what some of the log entries look like:

2024-01-15T05:36:42Z INF Transaction info gas=74544 sequence=60
2024-01-15T05:36:42Z INF Broadcasting the transaction size=306
2024-01-15T05:36:48Z INF Transaction result code=0 codespace= height=14496272 tx                                                                                                                                                                                                                                             _hash=26B9DF228B64DF1CA2BBD4A03FA3F71073B7FFE7C3AC872A4EBB31F69581E8B3
2024-01-15T05:46:39Z INF Updating the node status...
2024-01-15T05:46:39Z INF Preparing the transaction messages=1
2024-01-15T05:46:39Z INF Querying the account address=<... my node account>                                                                                                                                                                                                                                             efey6eprzdcmya4vl
2024-01-15T05:46:41Z INF Transaction info gas=95182 sequence=61
2024-01-15T05:46:41Z INF Broadcasting the transaction size=270
2024-01-15T05:46:44Z INF Transaction result code=0 codespace= height=14496373 tx                                                                                                                                                                                                                                             _hash=81F2173F6B490889089F717A98EEBE33943373B4F94E819A1D96BA2C974A6E13
2024-01-15T06:05:16Z INF Querying the account address=sent1c4nvz43tlw6d0c9nfu6r9                                                                                                                                                                                                                                             57y5d9pgjk5czl3n3
2024/01/15 06:19:29 http: TLS handshake error from 172.56.168.118:59369: EOF
2024/01/15 06:30:25 http: TLS handshake error from 172.56.169.122:42139: EOF
2024-01-15T06:41:39Z INF Updating the node status...
2024-01-15T06:41:39Z INF Preparing the transaction messages=1
2024-01-15T06:41:39Z INF Querying the account address=<... my node account>
brokenthumbs commented 10 months ago

The TLS handshake error is when you are visiting the endpoint. As the generated certificate is self-signed.

172.56.168.118 is the IP address of the requesting client, and the log is noting that the client does not know the certificate origin, as the certificate is self-signed.

What I am still trying to figure out is how to make the config_exchange_timestamp and location_fetch_timestamp update successfully. There are no errors. https://api.health.sentinel.co/v1/records/sentnode1j7xjen94heet3drsl5te6k0ylxlswzuev5m7up