lncli-web
lncli-web copied to clipboard
mably
SSL Hansdhake error on running on localhost
I am getting handshake error on running project & my LND node that is on localhost:10001 as mentioned in earlier stage 1 from alice node.
E0224 12:28:38.555136000 140736490542016 ssl_transport_security.cc:979] Handshake failed with fatal error SSL_ERROR_SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure. E0224 12:28:39.472572000 140736490542016 ssl_transport_security.cc:190] ssl_info_callback: error occured.
please provide solution to that, Thanks in advance.
@tyzbit I am having this same issue, and yes, I did regenerate certificates as outlined in the linked resource. Any other solutions?
Just to add to this, I am also getting the same issue, and have regenerated my certs.
Actually, I think I recall reading that in the more recent version of openssl, ssl3 has been disabled. Would it be possible to change the handshake to use TLS instead of SSLv3?
$ openssl version
OpenSSL 1.0.2g 1 Mar 2016
$ openssl s_client -ssl3 -connect google.com:443
140548870466304:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1878:
I think more generally the app/underlying library should be adapted to work with the certs that lnd generates, but that's definitely not a trivial task. I'd recommend trying to re-generate the certs with additional Common Names or trying to connect via 127.0.0.1 instead of localhost or vice versa.
This is the cert I generated that worked, I added localhost to the CN
Data:
Version: 3 (0x2)
Serial Number: 13168852819585109774 (0xb6c129de2ac58f0e)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=localhost, O=lnd
Validity
Not Before: Jan 29 05:19:49 2018 GMT
Not After : Jan 5 05:19:49 2118 GMT
Subject: CN=localhost, O=lnd
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:f6:5e:aa:ee:d4:b0:2f:75:32:1d:2e:62:62:5d:
a1:16:10:31:ce:76:b6:be:37:0d:1b:b0:ca:db:5f:
a2:12:4c:9c:11:4c:69:f5:78:50:ed:cb:6f:c4:27:
ff:9f:4a:38:ef:8f:30:76:49:75:22:ee:12:c2:9f:
a8:44:68:94:ee
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
46:9B:FE:AF:2D:FD:67:1D:53:45:2A:8D:F2:57:27:39:53:C4:DE:C8
X509v3 Authority Key Identifier:
keyid:46:9B:FE:AF:2D:FD:67:1D:53:45:2A:8D:F2:57:27:39:53:C4:DE:C8
X509v3 Basic Constraints:
CA:TRUE
X509v3 Subject Alternative Name:
IP Address:127.0.0.1, DNS:lightning, DNS:lightning.westeros, DNS:localhost
Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:e4:37:35:ba:a9:bf:c5:c7:9a:52:fd:1d:34:
35:fa:be:e2:bf:b1:1b:fd:0c:19:6b:63:5c:6f:ca:c4:4e:50:
ba:02:21:00:ce:72:07:4e:8c:75:ff:36:ed:6b:d2:96:73:39:
d1:ed:e2:8e:9e:63:9e:54:69:4b:f9:b0:6c:9d:51:ca:7e:7d
The relevant command is openssl req -new -sha256 -key tls.key -out csr.csr -subj '/CN=localhost/O=lnd' I believe.
So I ran that command:
openssl req -new -sha256 -key tls.key -out csr.csr -subj '/CN=localhost/O=lnd'
But my certificate doesn't have the Subject Alternative Name line:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12221134739704015645 (0xa99a314ba03e6b1d)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=localhost, O=lnd
Validity
Not Before: Mar 19 01:18:17 2018 GMT
Not After : Feb 23 01:18:17 2118 GMT
Subject: CN=localhost, O=lnd
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:3f:69:27:0d:83:1b:2f:09:67:c7:99:9d:6b:13:
dc:a2:57:35:fb:79:65:28:d6:0b:fe:2f:2e:f9:51:
a0:cf:8e:eb:e5:fc:09:a4:89:a6:40:d8:02:3c:c5:
72:9f:cf:02:12:60:ad:6d:d4:78:55:2f:87:ea:b9:
b6:ed:f8:4a:bc
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
EB:1F:C2:18:0F:16:BA:16:1C:24:3A:0C:B8:2F:ED:96:47:F0:58:37
X509v3 Authority Key Identifier:
keyid:EB:1F:C2:18:0F:16:BA:16:1C:24:3A:0C:B8:2F:ED:96:47:F0:58:37
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:96:0b:ba:f7:d7:8f:f1:9d:43:5f:e0:12:95:
0d:d6:e9:b1:a6:57:c3:86:02:5c:42:f8:eb:9c:49:d0:b2:1c:
a2:02:21:00:f8:18:e9:d9:a0:2e:bc:d0:25:a3:39:08:b9:75:
03:16:c7:6d:91:db:c6:77:ab:c8:fc:47:c1:a5:98:82:01:f6
Just curious why you closed this? @zachgoll and I still have an issue. If you resolved your issue, do you mind explaining the steps you took?
Try the new LND update. http://dev.lightning.community/tutorial/02-web-client/index.html before going to stage 2 you need to set up your LND node as mentioned in stage 1. http://dev.lightning.community/tutorial/01-lncli/index.html This will solve your issue. @ubenmackin
@ubenmackin if that previous command still doesn't work for you, what I did was also added this to the bottom of my /etc/ssl/openssl.cnf file:
[ alt_names ]
IP.1 = 127.0.0.1
DNS.1 = lightning
DNS.2 = lightning.westeros
DNS.3 = localhost
that's what produced the Subject Alternate names. Again, try swapping IP for localhost and vice versa, try the other command, but failing that you can use that previous command again with this additional block in your openssl to produce a cert exactly like the one I posted.
@tyzbit I tried adding what you suggested to /etc/ssl/openssl.cnf and then regenerated certs, but I am still getting a failure. Sorry for the naive question but how are you guys viewing the certificate?
Also, I am using LibreSSL 2.2.7 as Mac High Sierra comes with this updated version. Could this be the issue?
Here are my logs:
Zachs-Air:lncli-web Zach$ node server --lndhost=localhost:10001
{ pubKeyHex: '0315976de23b04f363f6b3a23cb7263c1fe98b5de18e4210fb67c52c810df1b04b',
paymentHashHex: '4e67764598fca6b07f96e706b9e3c3561fbd2f38cc019f97e4c503123b5bfe77',
value: 3 }
yck3q5xn8cnxga9ssqtd3p3g8ox6un47hg8rrr85c9n13yep6garsuu8q3n3t9fgsb93p3agz8thgio9zwzutuybu6m6jtedne7iz9uzyyyyyyyyyyyy8n6fbmso
{ pubKeyHex: '0315976de23b04f363f6b3a23cb7263c1fe98b5de18e4210fb67c52c810df1b04b',
paymentHashHex: '4e67764598fca6b07f96e706b9e3c3561fbd2f38cc019f97e4c503123b5bfe77',
value: 3 }
info: App listening on localhost port 8280
E0321 13:15:53.189838000 140735852200768 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed.
E0321 13:15:54.190823000 140735852200768 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed.
E0321 13:15:55.648036000 140735852200768 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed.
E0321 13:15:58.623306000 140735852200768 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed.
E0321 13:16:02.340334000 140735852200768 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed.
E0321 13:16:09.053113000 140735852200768 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed.
The app connects fine. I just get no data populating all the fields reflecting the node that I am trying to connect to.
UPDATE - I solved this issue and here is what I did:
- Deleted certificates from
$HOME/Library/Application\ Support/Lnd. - Regenerated certificates
- Shutdown all nodes and unlocked them using
lncli-alice unlock,lncli-bob unlock, etc. - Ran the application
@ubenmackin If this works for you we can close the issue?
@zachgoll I'll give this a try. My only question, and being new to lnd, but is it safe to restart my lnd nodes if there are channels open? I'm running my node in autopilot and noticed there are two channels up (one active and one not active).
Before I go and apply these changes, and restart, just want to make sure it won't cause any issues.
@ubenmackin I am not exactly an expert myself but when I restarted the nodes, my channels were still open upon restarting.
It works!
So I think the missing piece, for me at least, was making the change in /etc/ssl/openssl.cnf.
I had tried deleting and recreating the cert twice, but until I added the alt_names section, it wasn't working.
Let's close.
Before we close, I think we should leave open so the documentation can be updated, either to provide this fix as an alternate if the main cert generation doesn't work.
Also, if there's a way to generate a cert with SANs that doesn't require modifying openssl.cnf that would be more preferable.
And then again longer-term, adapt the app to work with the certs LND uses natively without regeneration.
If anyone wouldn't mind re-generating their certs but using this as the middle command instead and confirming it works? if so I'll have a PR open with documentation changes shortly
openssl req -new -sha256 -key tls.key -out csr.csr -subj '/CN=localhost/O=lnd' -config <(cat /etc/ssl/openssl.cnf <(printf "[alt_names]\nIP.1=127.0.0.1\nDNS.1=localhost"))
It's probably platform/OS/... specific as I don't have such configuration parameters in my openssl.cnf file.
@tyzbit I just re-ran the commands to generate new certs from the original documentation and everything worked fine. I think it may have been a user error causing this, but it still may be helpful to add a note in the documentation for troubleshooting. Here are the steps that I took to reproduce (carrying over the syntax reflected in stage 1 tutorial):
- Delete and regenerate certs (from
$HOME/Library/Application\ Support/Lnd/)
Zachs-Air:Lnd Zach$ rm tls.cert tls.key
Zachs-Air:Lnd Zach$ openssl ecparam -genkey -name prime256v1 -out tls.key
Zachs-Air:Lnd Zach$ openssl req -new -sha256 -key tls.key -out csr.csr -subj '/CN=localhost/O=lnd'
Zachs-Air:Lnd Zach$ openssl req -x509 -sha256 -days 36500 -key tls.key -in csr.csr -out tls.cert
Zachs-Air:Lnd Zach$ rm csr.csr
Zachs-Air:Lnd Zach$ cp tls.cert $GOPATH/src/github.com/mably/lncli-web/lnd.cert
- Fire up btcd
btcd --simnet --txindex --rpcuser=kek --rpcpass=kek
- Start Alice node and unlock
Zachs-Air:alice Zach$ lnd --rpclisten=localhost:10001 --listen=localhost:10011 --restlisten=localhost:8001
Zachs-Air:alice Zach$ lncli-alice unlock
- Start application
Zachs-Air:lncli-web Zach$ node server --lndhost=localhost:10001
- Add peers to your network (example: let's add Bob)
Zachs-Air:bob Zach$ lnd --rpclisten=localhost:10002 --listen=localhost:10012 --restlisten=localhost:8002
Zachs-Air:bob Zach$ lncli-bob unlock
After refreshing, you will see the new peer added to the peers section of the application.
Here are my software versions. I am not running docker.
Ubuntu 17.10 OpenSSL 1.0.2g 1 Mar 2016 lnd 0.4-beta Node v6.11.4
@mably Running v8.10.0 and @tyzbit during the time that I was getting the error, docker ps showed no active containers running on my system, so I don't know if that is the conflict?
Ah, so with @ubenmackin reporting he/she needed to add SANs then it seems like Docker is not the common denominator here. @zachgoll awesome, thanks for the positive report. If there are no running containers then it makes sense if the app isn't working.
Could some of you test the suggestion described here:
https://github.com/lightningnetwork/lnd/issues/795#issuecomment-374903140
You just need to update the corresponding env var defined in this file:
https://github.com/mably/lncli-web/blob/master/app/lightning.js#L10
I tried that ENV variable without generating new certificates (in Docker), didn't work. I only set the env var, not updated the code, so I'll try that next.
Actually, I was able to get it working with Docker with that line unchanged and changed and without regenerating certificates for this new instance. My previous issue was just the firewall. I rebuilt this node recently, I wonder if lnd generates different certs now.
Thanks @tyzbit for letting us know how you solved your SSL problem. It will help others.
@tyzbit I just re-ran the commands to generate new certs from the original documentation and everything worked fine. I think it may have been a user error causing this, but it still may be helpful to add a note in the documentation for troubleshooting. Here are the steps that I took to reproduce (carrying over the syntax reflected in stage 1 tutorial):
- Delete and regenerate certs (from
$HOME/Library/Application\ Support/Lnd/)Zachs-Air:Lnd Zach$ rm tls.cert tls.key Zachs-Air:Lnd Zach$ openssl ecparam -genkey -name prime256v1 -out tls.key Zachs-Air:Lnd Zach$ openssl req -new -sha256 -key tls.key -out csr.csr -subj '/CN=localhost/O=lnd' Zachs-Air:Lnd Zach$ openssl req -x509 -sha256 -days 36500 -key tls.key -in csr.csr -out tls.cert Zachs-Air:Lnd Zach$ rm csr.csr Zachs-Air:Lnd Zach$ cp tls.cert $GOPATH/src/github.com/mably/lncli-web/lnd.cert
- Fire up btcd
btcd --simnet --txindex --rpcuser=kek --rpcpass=kek
- Start Alice node and unlock
Zachs-Air:alice Zach$ lnd --rpclisten=localhost:10001 --listen=localhost:10011 --restlisten=localhost:8001 Zachs-Air:alice Zach$ lncli-alice unlock
- Start application
Zachs-Air:lncli-web Zach$ node server --lndhost=localhost:10001
- Add peers to your network (example: let's add Bob)
Zachs-Air:bob Zach$ lnd --rpclisten=localhost:10002 --listen=localhost:10012 --restlisten=localhost:8002 Zachs-Air:bob Zach$ lncli-bob unlockAfter refreshing, you will see the new peer added to the peers section of the application.
I was stuck with this problem for a few days. With the steps above, SSL handshake error has been gone. Thanks so much. @zachgoll
