Setting up an httpS wallet

Right, setting up an http wallet is easy enough. What about https? Do we need a tunnel (e.g. stunnel) or apache/nginx+proxypass to handle the https or does the wallet support ssl natively?

Some exchanges now claim they require https wallets for withdrawals (*). I see many https wallets have an uri, not just hostname, e.g. https://grin.foo.com/youhexything … which to me suggests there is a web server in front doing proxypass, am I right?

Cheers

(*) Bitforex recently claims they require https wallets - I call BS. Personally I think it’s another excuse for their continuous failure to handle withdrawals, and the high rate of withdrawal failures. 80% of my withdrawals there last 6-12h in “In Process” then I beg for help on Telegram, then they tell me it failed because my wallet is unstable. SOme work fine, most fail, all to the same http://IP:PORT address (which is hosted on a dedi server in a datacentre, rock solid).

1 Like

You need a domain and a TLS certificate, but the standard grin wallet handles everything.

I have the same problem with BitForex. I know my https wallet works and is online, but withdrawals fail after 1 or 20 hours.

What kind of address are you using? Is it really http://IP:PORT ? no https://? no domain?

1 Like

The wallet itself may handle addresses like https://grin.foo.com but probably not https://grin.foo.com/youhexything, right?

Yes, my wallet’s address is exactly like I specified.

Some bitforex wd’s work, others fail, and the admins blame the users all the time. They are the only exchange whoch still handles wd’s manually (and the tech people have to be on site if anything happens). The whole exchange is buggy (wrong balances etc). It is however more honest than hotbit and bgogo, both which continuously add fake filled orders to the order book (with prices always in between the bid/ask) in order to inflate the volume and influence price … and yes, I have proof. I hope a decent exchange lists Grin so we can get rid of this slimy wild west.

2 Likes

Ok, so for anyone else interested in this, I got my wallet at https://grin.foo.com/youhexything (which allows nice URLs for multiple users on the same host). I set it up via Apache with proxypass, i.e. I let apache handle the SSL and wallet listens only on http:// (the wallet conf is unchanged). Add the following to your ssl virtual host in apache:

SSLProxyEngine On
ProxyPass /abr http://127.0.0.1:3415
ProxyPassReverse /abr http://127.0.0.1:3415

If you want you can restrict the wallet now to listen only on 127.0.0.1 instead of 0.0.0.0 (and also add proxypass for the non-ssl host in apache).

Full Apache site conf:

<VirtualHost *:443>
ServerName grin.foo.com
ServerAdmin webmaster@foo.com

DocumentRoot /var/www/grin.foo.com

<Directory /var/www/grin.foo.com>
Options FollowSymLinks
AllowOverride All
Allow from all
</Directory>

LogLevel notice
ErrorLog ${APACHE_LOG_DIR}/grin-error.log
CustomLog ${APACHE_LOG_DIR}/grin-access.log combined

SSLEngine on
SSLStrictSNIVHostCheck On
SSLCipherSuite ECDH+AESGCM,DH+AESGCM,ECDH+AES256,DH+AES256,ECDH+AES128,DH+AES,ECDH+3DES,DH+3DES,RSA+AESGCM,RSA+AES,RSA+3DES,!aNULL,!MD5,!DSS
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/foo.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/foo.com/privkey.pem

SSLProxyEngine On
ProxyPass /abr http://127.0.0.1:3415
ProxyPassReverse /abr http://127.0.0.1:3415

</VirtualHost>

… and to confirm, I tried to withdraw to it from Bitforex and, surprise surprise, it hung at “In process” again and it’s stuck until the “technician” comes in tomorrow. The usual, same story.

Slums will be slums.

I have a very similar setup for grinpay to allow users deposit on different accounts. Only difference is my server is running on nodejs (request forwarded to local http listener). Although I did not experience any issue with bitforex withdrawals.

1 Like

You can use https://ngrok.com/ as a quick workaround

1 Like

Did you withdraw Grin? How did you do it? Thanks!

Yes withdrawal to my https wallet address worked fine from BitForex. Similar setup as @slate described, users append their address to the url so my backend can send the equivalent amount of Grin to their Stellar account.

image

The routing is done like this:

app.post("*/v1/wallet/foreign/receive_tx", function (req, res) {
    const addr = ...
    if (StellarBase.StrKey.isValidEd25519PublicKey(addr)) {
        req.forward = { target: "http://127.0.0.1:3415/v1/wallet/foreign/receive_tx" };
        forward(req, res, (err, res) => {
            if (!err) {
                ...
            }
        });
    }
});

I’ve just tested sending a couple of grins from BitForex to grinpay.org. After 20 mins BitForex shows the transaction is done, but I didn’t see the grin (or xlm) in Litemint?

Hi, I just updated the other thread and saw your reply here. Basically you provided an address which does not have a trustline to GRIN so the automatic transfer failed. Your stellar account must be valid (minimum xlm balance requirement must be met, and a trustline to GRIN must also be established).

Since you are using our wallet Litemint, we will fund your account with 2 XLM however you must setup the trustline to GRIN yourself (assets tab, click ADD GRIN). When this is done, I will manually transfer the Grin.

Thank you so much for your assistance! Confirmed deposit and withdraw with grinpay.org successfully. Much appreciated!

1 Like

Grin-wallet supports TLS (HTTPS) out of the box https://github.com/mimblewimble/grin-wallet/blob/master/doc/tls-setup.md

1 Like

True, but it can’t run several wallets on the same 443 port and do pretty links without port numbers, like https://domain.com/grin1 and https://domain.com/grin2 and https://grin3.domain.com. You need a web server and virtual hosts and/or reverse proxy for those.

1 Like