CERTIFICATE_VERIFY_FAILED on startup

[ripper234]

I'm following the lnd tutorial, I'm now at stage 2, using lncweb.

I'm using Windows 10 and latest lnd/btcd.

I setup a cert file according to the tutorial. Getting CERTIFICATE_VERIFY_FAILED errors.

node server -l localhost:10001
{ pubKeyHex: '0315976de23b04f363f6b3a23cb7263c1fe98b5de18e4210fb67c52c810df1b04b',
paymentHashHex: '4e67764598fca6b07f96e706b9e3c3561fbd2f38cc019f97e4c503123b5bfe77',
value: 3 }
yck3q5xn8cnxga9ssqtd3p3g8ox6un47hg8rrr85c9n13yep6garsuu8q3n3t9fgsb93p3agz8thgio9zwzutuybu6m6jtedne7iz9uzyyyyyyyyyyyy8n6fbmso
{ pubKeyHex: '0315976de23b04f363f6b3a23cb7263c1fe98b5de18e4210fb67c52c810df1b04b',
paymentHashHex: '4e67764598fca6b07f96e706b9e3c3561fbd2f38cc019f97e4c503123b5bfe77',
value: 3 }
info: App listening on localhost port 8280
E0506 16:38:29.877000000 9388 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
E0506 16:38:30.884000000 9388 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.

How should I proceed to debug this?

[ripper234]

FYI I generated the certificate on Git Bash using '//CN=localhost\O=lnd' as stated in the docs.

[mably]

Just regenerated my lnd certificate on my Windows machine using Git Bash and everything works fine 🤔

What shows openssl x509 -in lnd.cert -text -noout ?

Do you have a line saying: Subject: CN=localhost, O=lnd ?

May be you specified a custom rpchost different from localhost ?

[ripper234]

I didn't specify a custom rpchost.
Will check this later this week (sorry for delayed response).

[ripper234]

Do you have a line saying: Subject: CN=localhost, O=lnd ?

Yes it does:

>openssl x509 -in tls.cert -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e8:95:23:01:d9:f7:9f:8d
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=localhost, O=lnd
        Validity
            Not Before: May  6 13:38:17 2018 GMT
            Not After : Apr 12 13:38:17 2118 GMT
        Subject: CN=localhost, O=lnd
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:92:e6:23:0b:7c:8b:f6:8f:6d:65:0f:1c:e7:4a:
                    51:1f:98:37:e7:22:95:8b:1a:42:a3:e5:c7:0d:84:
                    6d:0c:49:50:b0:8c:3c:db:e1:43:3c:a2:58:b5:9d:
                    fe:26:cd:51:be:e8:13:c1:d8:20:f6:5d:86:79:ba:
                    93:32:d8:6f:ab
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                B4:1F:40:15:EE:E7:AB:F1:A2:E2:76:75:85:52:2F:85:28:9D:70:03
            X509v3 Authority Key Identifier:
                keyid:B4:1F:40:15:EE:E7:AB:F1:A2:E2:76:75:85:52:2F:85:28:9D:70:03

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:21:00:83:6a:7d:46:23:2a:ed:bd:0b:9f:7b:c9:18:
         f6:18:bd:64:d7:2d:9a:ae:db:7a:33:12:e2:34:e7:5a:fb:74:
         41:02:20:20:f3:68:bd:ad:68:67:e5:e1:a3:08:37:40:07:24:
         da:02:6d:0e:27:17:93:de:be:ea:de:fa:90:9e:1f:64:0d

[k9ert]

I've a similiar issue but probably a little bit more complicated setup: I'm trying to run lnd and lncli-web in docker. So here are some questions which might also help to clarify this case (and maybe others):

lnd has a --rpclisten switch which i set like --rpclisten=0.0.0.0:10009. This resulted in the lnd-logs like such:

2018-06-19 19:28:03.709 [INF] RPCS: RPC server listening on [::]:10009
2018-06-19 19:28:03.710 [INF] RPCS: gRPC proxy started at 127.0.0.1:8080

Question: lncli-web is using the grpc-interface, can you confirm? At least the logs look like this. To me that means that i have to make lnd also listen port 8080 on 0.0.0.0 which i could not find a switch yet on lnd.

Also i see these log-messages:

debug:   tail stderr tail: cannot open '/root/.lnd/logs/bitcoin/testnet/lnd.log' for reading: No such file or directory
tail: cannot watch parent directory of '/root/.lnd/logs/bitcoin/testnet/lnd.log': No such file or directory
tail: inotify cannot be used, reverting to polling

Question: I don't have to provide that directory, can you confirm? Would be difficult (although doable) in a docker-setup but i couldn't find any hint that this is strictly necessary.

[mably]

lncli-web is connecting directly to the lnd grpc interface which defaults to 10009, lncli-web doesn't use the we proxy.

Providing a valid lnd log configuration settings (lndLogFile) in your config/defaults.js file is not required, just discard those error messages.

[shocknet-justin]

adding tlsextraip= to my lnd.conf and regenerating the certs resolved a number of certnaming issues in trying to run lncli-web remotely.

per lightningnetwork/lnd#835

[k9ert]

Great, i have it working. The solution was simple but i couldn't see the forest because of too many trees.
tlsextraip= is imho misleading here. We can't use the lnd-certificate and that switch is only used for creating a lnd-cert.

In my case i'm running both in docker. I'm connecting them by "--link alice". So as the SET_LNDHOST=alice:10009 obviously the cert to generate needed to be:
--subj '/CN=alice/O=lnd'

[mably]

Thanks for sharing your solution 👍

[k9ert]

Unfortunately it's not finished. Replacing the subject with alice results in a problem if you want to use the lncli from within the lnd-container. So what's needed here would be a subjectAltName "localhost".

I tried it with https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command-line

but that works only for the csr. The cert which is based on the csr is somehow missing the subjectAltName. This is clearly out of scope for this ticket but maybe it helps someone:

export LND_OWNER=alice
    if [ ! -f /rpc/${LND_OWNER}-tls.key ]; then
        echo "Found LND_OWNER=$LND_OWNER ... creating certificate ..."
        openssl ecparam -genkey -name prime256v1 -out ${LND_OWNER}-tls.key
        openssl req -new -sha256 \
            -key ${LND_OWNER}-tls.key \
            -subj "/CN=${LND_OWNER}/O=lnd" \
            -reqexts SAN \
            -config <(cat /etc/ssl/openssl.cnf \
                <(printf "\n[SAN]\nsubjectAltName=DNS:localhost")) \
            -out csr.csr
        openssl csr -in csr.csr -text -noout # contains the subjectAltName
        openssl req -x509 -sha256 -days 36500 \
            -key ${LND_OWNER}-tls.key \
            -in csr.csr -out ${LND_OWNER}-tls.cert \
            -reqexts SAN \
            -config <(cat /etc/ssl/openssl.cnf \
                <(printf "\n[SAN]\nsubjectAltName=DNS:localhost"))
        openssl x509 -in ${LND_OWNER}-tls.cert -text -noout # no longer contains the subjectAltName
        rm csr.csr
        echo "done"
    fi

That's a snippet from your init.sh which i'm messing with. The solution is quite ugly as i need to modify the lnd-startup-script as well (and have to restart the alice-container afterwards as well) but i want to have that fully automated for reference-reasons.

I'd be happy to create a PR if i get that to work.

[k9ert]

I've solved this. The problem with some investigation and the solution is here: https://gist.github.com/k9ert/9f549ea46b3b70b6cbcd4c1abac27d8c

In short: subjectAltName=DNS:localhost,DNS:${LND_OWNER}