A telnet response is always better than a timeout. That means something is responding. But since you say you already did delete the tls.cert beforehand, I'm wondering what else can be wrong.
If you decode the contents of the tls.cert file using https://www.sslchecker.com/certdecoder for instance, do you see all your IPs and domains?
Another way to check if you can connect is, use Zap Wallet to connect to your node. Zap uses the gRPC interface to connect. It might even give you useful error messages if initially you run into trouble connecting.
no i do not see any of my IPs or domains that is provided, interesting.
however i know that the cert was just regenerated because the issuance date got updated (the last one was yesterday). are the entries form tlsextraip and tlsextradomain supposed to be listed in the decoded dataset somewhere?
reply
Yes your extra IPs and domains you provided in tlsextraip and tlsextradomain config entries should appear in the 'SAN' subject in the certificate. If they are not there, your app will not be able to perform the necessary SSL handshake.
You need to investigate why they are not getting picked up by lnd.
I don't use Umbrel so I do not know if they have hidden config files somewhere that overrides your manual lnd.conf entires. Maybe you can check with them Umbrel folks.
reply
dude, thank you. you helped a lot. i've asked a question on umbrel about this because it actually looks like they ignore the lnd.conf entries when generating the cert. waiting for the reply...
btw. i ended up using voltage.cloud and it works like a charm!
reply
I did some digging, it looks like it is a known issue with Umbrel after upgrade 0.5.0.
reply
How the fuck did i miss this... Well, another argument for using voltage. Imagine being reliant on this for a production app and your certificates becoming void after a restart or update.
reply
Glad to hear it!
reply