|
Client nodeRunclient -h to see all available command line switches. Some example ones are:
-t - use Testnet4 (instead of regular bitcoin network)
To run the client on a remote Linux server (via ssh connection), you probably want to get adventage of screen command. TextUIWhen the client is already running you have an interactive, text command based interface, on the console.Type help to see the possible commands.
WebUIThere is also a web interface that you can operate with a web browser.Make sure to have the www/ folder in the location where you execute the client from.The folder contains files that are an essencial part of the WebUI application. WebUI application is tested with Google Chrome, but should be compatible with any modern web browser. By default (for security reasons) WebUI is available only from a local host, via http://127.0.0.1:8833/ Remote serverIn order to use WebUI securely on a remote server, set up ssh tunneling to port 8833.Alternatively, expose the WebUI over an encrypted connection - see WebUI over SSL below. Local networkIf you run the node on a local network and want to have access to its WebUI from different computers:
Read more about the config file at the config file page. WebUI over SSLThe node can also serve the WebUI over an encrypted HTTPS connection.This mode uses two certificates:
Because the access is controlled by the certificate, the SSL server ignores the AllowedIP list and
listens on all the network interfaces, no matter what Interface is set to.
It runs in parallel with the regular HTTP server, which keeps its own settings.Once connected, you get exactly the same WebUI as over HTTP, including the wallet and spending pages. It is therefore a convenient way of reaching your node from the outside world – without ssh tunneling and without exposing the unencrypted WebUI to the internet. Which certificate comes from wheressl_cert/ca.crt is used only to verify the client certificates, so it always has to be
your own CA, generated by yourself. Never use a public CA for that file – it would let anyone
holding a certificate from that CA into your node.The server certificate is independent from it. You can either have it signed by your own CA (self-signed), or use one issued by a trusted party, e.g. Let's Encrypt. In the latter case your browser will trust the node's address out of the box. Generating your own CAopenssl genrsa -out ca.key 4096 openssl req -new -x509 -days 365 -key ca.key -out ca.crtCopy ca.crt into the ssl_cert/ folder. Keep ca.key somewhere safe
– you only need it to sign the certificates below.Server certificateIf you have a certificate from a trusted CA, simply rename its private key toserver.key
and the certificate (or the full chain) to server.crt. Both files have to be in the PEM format.To make a self-signed one instead, first create a v3.ext file:
authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = domain.comReplace domain.com with the hostname (or IP) of your node, then: openssl genrsa -out server.key 2048 openssl req -new -key server.key -out server.csr openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt -sha256 -extfile v3.extWhen asked for the Common Name, give the same value as in DNS.1 above. Place server.key and server.crt in the ssl_cert/ folder.Using a self-signed certificate, also import ca.crt into your browser's Trusted Root CA
list, to avoid security warnings.Client certificateThis one is always signed by your own CA:openssl genrsa -out client.key 2048 openssl req -new -key client.key -out client.csr openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12Import the resulting client.p12 into your browser's Personal certificates.
The browser will ask you which certificate to use when you first open the node's page.Note: the client.p12 file stays on your side only – it is never copied to the node.
Repeat this step for each device you want to give access to.Accessing the nodeThe SSL server starts automatically as soon asca.crt, server.crt and
server.key are all present in the ssl_cert/ folder – there is no config value
enabling it. After restarting the node, look for Starting SSL server at :4433 ... in the console output.Then point your browser at https://your.hostname.or.ip:4433/ The default port depends on the network: 4433 for main net, 14433 for Testnet3
and 44433 for Testnet4. Set SSLPort in the config file to use a different one.To have the WebUI at the standard HTTPS port, redirect it on your nat, e.g.: iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 4433The server certificate is reloaded automatically whenever the server.crt file changes,
so renewing it (e.g. by Let's Encrypt) does not require restarting the node.Security precautionsKeepca.key and all the client.* files secret.
Whoever gets hold of any of them will be able to access your node's WebUI.Your wallets are not exposed this way. The node's wallet is watch-only and it never holds any private keys, while the addresses themselves are kept in the LocalStorage of your own browser – not on the node. A stranger connecting from a different browser simply sees an empty Wallet page, until they add some wallets of their own. What such a person does get is control over the node. With ServerMode disabled they can
shut it down, change its configuration and add or remove network peers.
And even with ServerMode enabled, they still see the memory pool and all the transactions
loaded locally on your node.See also the README in the client's ssl_cert/ folder.
|