tlsmanager: fix autocert autogeneration

[sputn1ck]

As the getConfig() function would previously overwrite the GetCertificate function of the tls config, the autocert manager would never be used.

This PR moves the setUpLetsEncrypt func to where it would correctly override the GetCertificate function.

Closes #7734

[hieblmi]

I am trying tACKing this but get stuck at
Debugging from this site: https://letsdebug.net/ however works with all three challange types.

Edit:

tACK
I was able to generate the letsencrypt cert and call rpcs with it.

Setup:

• sub domain pointing to my local WAN IP
• router port forwarding for Ports 80, 443 and local rpcserver port

Question: Is the following letsencrypt flow as it is supposed to be?

On a fresh lnd instance there's only the standard tls.cert available. Hence, to trigger the letsencrypt cert challenge I call:

lncli --macaroonpath=~/.path/to/admin.macaroon --network regtest --tlscertpath=~/.lnd-dev-zane/tls.cert --rpcserver my.domain.com:10019 getinfo

This call fails with the following message...

[lncli] rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority"


$ls -la ~/.lnd-dev-zane/letsencrypt       
drwx------  4 bob  staff   128 Jun 10 17:02 .
drwx------  7 bob  staff   224 Jun 10 17:01 ..
-rw-------  1 bob  staff   227 Jun 10 17:02 acme_account+key
-rw-------  1 bob  staff  5554 Jun 10 17:02 my.domain.com

... while the letsencrypt generation succeeds.

lncli --macaroonpath=~/.lnd-dev-zane/data/chain/bitcoin/regtest/admin.macaroon --network regtest --tlscertpath=~/.lnd-dev-zane/letsencrypt/my.domain.com --rpcserver my.domain.com:10019 getinfo
{
    "version":  "0.16.99-beta commit=",
    "commit_hash":  "f9d4600ff805968426b6d2058293266e7bdcf6f1",
    "identity_pubkey":  "030c22c9184f85d6d73372914c41bac0d40861f2b3f46853355587e121a942f262",
.
.
.
}

[sputn1ck]

@hieblmi I think generally using let's encrypt with lncli is wonky.

The way we can accept a cert using a grpc request is by leaving the tls config empty (e.g. credentials.NewTLS(&tls.Config{})).

AFAIK lncli doesn't support that.

Also

lnd/sample-lnd.conf

Line 84 in cf1f44a

; is only requested and stored when the first rpc connection comes in.

notes that the certificate is only stores once the first rpc connection comes in.

[hieblmi]

I see, I wasn't aware of the difficulty testing this with lncli. Thanks for the explanation.

[khashmeshab]

Sorry for intervening! Can you please fix this issue a little bit faster? I had to update my LND to resolve another problem, and then I lost my Let's Encrypt. Thank you.

[lightninglabs-deploy]

@sputn1ck, remember to re-request review from reviewers when ready

[khashmeshab]

Hi guys. Just trying to remind you that there's a broken piece of your "beta" software that people relied on, and it's been a long time for it to get fixed.

[guggero]

@sputn1ck needs a rebase.

[guggero]

@khashmeshab can you confirm this patch is working for you? The whole Let's Encrypt setup is quite difficult to test in non-production environments.

[khashmeshab]

@guggero I'm on it.

[khashmeshab]

@guggero patched, compiled, and tested both with my old letsencrypt dir and then after I deleted it, and it seems to work flawlessly. You may check: https://maxod.ir:8081

[guggero]

LGTM 🎉

[guggero]

@guggero patched, compiled, and tested both with my old letsencrypt dir and then after I deleted it, and it seems to work flawlessly. You may check: https://maxod.ir:8081

Thank you for testing!