So, here are the answers in case anyone comes across this in their own journey:
When you're setting SSL up in node, especially with SPDY, it asks for:
var options = {
key: fs.readFileSync(__dirname + '/keys/spdy-key.pem'),
cert: fs.readFileSync(__dirname + '/keys/spdy-cert.pem'),
ca: fs.readFileSync(__dirname + '/keys/spdy-ca.pem'),
};
It seems that you can use the csr (certificate signing request) as the ca in the SSL setup for self-signed certificates. However, doing that on a production server, means that the certificate chain has problems (the certificate you bought, like RapidSSL, is chained to a lower-level certificate, like GeoTrust. The chain needs to go all the way back since GeoTrust is the one trusted by the browser.) If you don't do the ca file (intermediate certificate file) it's ok in most cases - it'll say that the chain is broken in https://www.ssllabs.com/ssltest but the browsers didn't seem to care. But the correct way is to put the intermediate certificate in the ca spot.
As for node and couch, the problem definitely was permissions. I added couchdb user to the deploy usergroup but since the permissions on the key files are 600, the group still doesn't have access. In my case, I just created a self-signed certificate specially for couchDB.
That means that I have to tell node to trust it by using this config flag:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
So now couch and node talk and use SSL.
As for some of the other questions:
Basic openssl usage seems to work fine with couchdb, so no issues with certain certificate types or anything like that I've come across
I cannot seem to turn on certificate verification for couch in this setup. I just get
SSL: hello: tls_handshake.erl:285:Fatal error: internal error
So leaving that set to false works
It seems that you can safely remove the http server from couchdb's couch.uri file (found at /var/run/couchdb/couch.uri
) and just have the https one.
Hope this helps someone out,
Paul
The simplest things are often the hardest to find :)
I solved it with the 1st solution (use only ProxyPass):
<Location /prj/socket/>
ProxyPass http://localhost:12345/a
ProxyPassReverse http://localhost:12345/
</Location>
The only problem was that I was using the ws:// protocol. When I changed to http:// it worked fine. Thanks to anyone who cared to take a look :)
Best Answer
My rudimentary understanding of this issue is as follows (don't quote me on it):
perMessageDeflate
key in your server code the valuefalse
. That is:const wss = new WebSocket.Server({ server:httpsServer, perMessageDeflate: false });
Obviously this isn't a solution for people wanting to compress their messages. But it is worth mentioning that:
Also, some have noted that setting perMessageDeflate: false only reduces the problem, but does not entirely solve the problem. I would direct your attention to this discussion, where it is said that SOME residual and constant (i.e. not increasing) memory use from opening and closing websockets is normal (I'm not necessarily saying this is correct by the way): https://github.com/websockets/ws/issues/804#issuecomment-302612661
As for preloading Jemalloc, it does not seem that this fixes the issue. Although if the above code doesn't work, it is certainly worth looking into (or trying).
So is
preMessageDeflate: false
the best solution right now? From my understanding, I would say yes.If anyone has corrections or more information on this please add.