fix(nodebuilder): TLS key/cert name variables

[koenmtb1]

Depending on how one generates the TLS certificates it might use different names for the key files.
These are currently hard-coded to cert.pem and key.pem, but for example letsencrypt by default uses keychain.pem which does load correctly into Go TLS.

To prevent having to manually create a symlink using an env variable will resolve that.

One outstanding question that I still have is that if TLS certs are renewed, does the node pick it up automatically? As far as I can tell it currently doesn't, happy to work on that too but a pointer of would be helpful.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 11 lines in your changes missing coverage. Please review.

Project coverage is 44.75%. Comparing base (2469e7a) to head (b32f09a).
Report is 480 commits behind head on main.

Files with missing lines	Patch %	Lines
nodebuilder/p2p/tls.go	0.00%	11 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4203      +/-   ##
==========================================
- Coverage   44.83%   44.75%   -0.09%     
==========================================
  Files         265      312      +47     
  Lines       14620    22959    +8339     
==========================================
+ Hits         6555    10275    +3720     
- Misses       7313    11563    +4250     
- Partials      752     1121     +369     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cristaloleg]

Please run make fmt

[cristaloleg]

SGTM

[vgonkivs]

Generally LGMT. But it makes me think that we don't need TLS_PATH anymore and we can have TLS_KEY_PATH and TLS_CERT_PATH instead. It also covers a case when key and certs can be set in different folders.

UPD: we can do much more with the tls stuff in future, so maybe we can have a separate structure in the node's config for it?
Thoughts @renaynay @Wondertan @walldiss @cristaloleg

[koenmtb1]

The thought behind keeping TLS_KEY_PATH is to not make this a breaking change and retain backwards compatibility, happy to update if deemed helpful.
Happy to update node config for this too, if you think thats a better location.

I've also noticed there's no docs for this (or any requirement for having TLS at all). Is that something worth exploring?

[vgonkivs]

I've also noticed there's no docs for this (or any requirement for having TLS at all). Is that something worth exploring?

do you mean these docs https://docs.celestia.org/how-to-guides/light-node#optional-start-light-node-with-core-endpoint-with-authentication ?

[Wondertan]

do you mean these docs https://docs.celestia.org/how-to-guides/light-node#optional-start-light-node-with-core-endpoint-with-authentication ?

this TLS config is for libp2p's websocket, not for core

[Wondertan]

Hey @koenmtb1, aside from this PR, you may wanna take a look at https://blog.libp2p.io/autotls/. We haven't integrated it yet, but it's targeting this particular struggle of managing TLS certs. This is gonna be super helpful for bootstrapper infra by automating cert issuing. We would appreciate if you can take a look into it and help us and other bootstrappers with integration of this tool.

[koenmtb1]

Hey @koenmtb1, aside from this PR, you may wanna take a look at https://blog.libp2p.io/autotls/. We haven't integrated it yet, but it's targeting this particular struggle of managing TLS certs. This is gonna be super helpful for bootstrapper infra by automating cert issuing. We would appreciate if you can take a look into it and help us and other bootstrappers with integration of this tool.

This is interesting, would be open to adding support for this. Probably a separate PR and keep support for self serving certificates?
Any thoughts on using their default libp2p.direct or setting up a custom service?

[Wondertan]

Probably a separate PR and keep support for self serving certificates?

Yes

Any thoughts on using their default libp2p.direct or setting up a custom service?

We can start with the default one for simplicity