reply on: Connect SN wallet for autowithdraw to your Core Lightning (CLN) node via CLNRest \ stacker news ~lightning

1 sat \ 13 replies \ @ek 21 May freebie \ on: Connect SN wallet for autowithdraw to your Core Lightning (CLN) node via CLNRest lightning

Hey, thanks for the guide! Formatting looks great, just unfortunate that the connection failed, lol

Regarding the error:

request to https://hidden.onion:2104/v1/invoice failed, reason: write EPROTO C077EC2F067F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:354:

I've seen this error multiple times in the past. Unfortunately, I don't remember how I fixed it but after some research that also mentions this, I think I remember: it's when the response is HTTP not HTTPS which confuses openssl (good error messages are hard).

So just to be sure, are you sure you are running CLNRest over HTTPS not HTTP? But I guess the error could also happen under a lot of different circumstances, this might just be the most common cause.

Another thing I noticed is that you looked at a file named certificate.pem in a directory dedicated to the CLNRest plugin. Which CLN version are you running? It seems like you are not running at least v23.08 since CLNRest is a built-in plugin from this version on. It then stores the certificates at $HOME/.lightning/mainnet/.¹

If you tell me which version you are running, I can check compatibility or if you might used a wrong certificate. certificate.pem is ambiguous since there should also be a server certificate in the same directory. In v23.08, the certificate we need is called ca.pem. It's the certificate of the certificate authority (CA) which establishes the trust chain, commonly called root certificate (yes, SSL/TLS is confusing).

Also, how did you encode the certificate? It might be already stored as base64 or hex in your version, but in v23.08, I have to run xxd -p -c0 ca.pem to get it in hex. My CA certificate starts with -----BEGIN CERTIFICATE----- which means it's not base64 or hex. Is this not the case for yours?

That your node uses "c-lightning" is also an indicator for an old version since they call themselves core lightning now ↩

121 sats \ 11 replies \ @Design_r OP 21 May

Thanks @ek for your response and for sharing your insights.

Regarding the CLN version, I'm running 23.08-hotfix-1 so it should have CLNRest as built-in. And here's the path ~/core-lightning/data/c-lightning-rest/ to the certificate.pem ¹. Also tried to find the ca.pem you mention without success, the only files found in the same folder are access.macaroon, certificate.pem, key.pem and rootKey.key. Any other place I could look for this file?

So I open the certificate and place the content between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- making sure I removed any space between the characters, converted to base64 using an online converter and then inputting in the form everything as a single line.

Anyhow, I think the error is on the first thing you're mentioning, about the SSL. My node run exclusively on Tor and does not use SSL certificate for the connection. When I try to append http:// to the onion address, the input validation script obviously give me error instantly: so are you saying I should run CLNRest over HTTPS? How I can do that?

https://m.stacker.news/31849

You can see I also mentioned in point 3. Get your cert ↩

10 sats \ 10 replies \ @ek 21 May freebie

Anyhow, I think the error is on the first thing you're mentioning, about the SSL. My node run exclusively on Tor and does not use SSL certificate for the connection.

If you don't use SSL, you don't need to give us a certificate. We only use HTTPS with Tor if you give us a certificate. Else we'll try to connect to your node over HTTP for Tor then.

So maybe it will work if you simply leave out the certificate?

So are you saying I should run CLNRest over HTTPS? How I can do that?

No, you don't have to but you could. I assumed you would run it over HTTPS since it's the default of CLNRest:

--clnrest-protocol: Specifies the REST server protocol. Default is HTTPS.

10 sats \ 9 replies \ @Design_r OP 21 May

Yes I tried as well leaving the cert empty and I get a different error:

1s	[cln]	ERROR	could not connect to CLN: invalid json response body at http://hidden.onion:2104/v1/invoice 
reason: Unexpected token < in JSON at position 0
1s	[cln]	ERROR	failed to attach wallet

In the JSON I've multiple runes and the one in position 0 does not have any restriction (and is there by default). The rune I've created and using is in position 1 and has the correct restrictions:

 {
         "rune": "hidden",
         "unique_id": "1",
         "restrictions": [
            {
               "alternatives": [
                  {
                     "fieldname": "method",
                     "value": "invoice",
                     "condition": "=",
                     "english": "method equal to invoice"
                  }
               ],
               "english": "method equal to invoice"
            }
         ],
         "restrictions_as_english": "method equal to invoice"
      }

So is maybe SN script looking at the rune in position 0 only and giving back that error? Should I edit the JSON and switch rune positions? Or what else could I try?

21 sats \ 8 replies \ @ek 21 May freebie

Your rune seems to be fine. We only try to connect when we verified that your rune is properly limited to method=invoice. We then use this rune with the Rune header as mentioned here and as you can see here. We don't do anything else to it.

The error invalid json response body at http://hidden.onion:2104/v1/invoice reason: Unexpected token < in JSON at position 0 means that we connected to your node successfully but it didn't return JSON as expected.

Do you get a valid JSON response when you do a request from the same machine with cURL? Try this:

$ curl -X POST http://localhost:2104/v1/invoice -H "Rune: <your_rune_here>"

110 sats \ 0 replies \ @Design_r OP 21 May

maybe worth to mention I'm using umbrel

100 sats \ 6 replies \ @Design_r OP 21 May

I get the following error:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot POST /v1/invoice</pre>
</body>
</html>

31 sats \ 5 replies \ @ek 21 May

🤨

Something seems to be wrong with your node. Looks like CLNRest is not running? I am not familiar with Umbrel unfortunately. Looking at the Umbrel docker-compose config for CLN, I wonder why they run CLNRest separately. Maybe that's related?

Since v23.08, it's built-in so they should add --clnrest-port during start to enable it which they don't.

10 sats \ 4 replies \ @Design_r OP 21 May

It is maybe using a different port?

Does make sense to edit the docker-compose.yml file and add under command: for example:

--clnrest-port=${APP_CORE_LIGHTNING_DAEMON_IP}: 2104

21 sats \ 3 replies \ @ek 21 May freebie

You can for sure try. But try this:

--clnrest-port=2104

or use 3010 as the port since according to the docs, that's common

view replies

1 sat \ 0 replies \ @ek 21 May

It then stores the certificates at $HOME/.lightning/mainnet/

It might use "bitcoin" instead of "mainnet"

Footnotes

Footnotes