Closed richardzyx closed 5 years ago
Some related issues:
@jedireza @richardzyx
you can handle this with $param
directive.
'use strict';
const Fs = require('fs');
const { promisify } = require('util');
const { Store } = require('confidence');
const run = async () => {
const read = promisify(Fs.readFile);
const store = new Store({ cert : { $param: 'tls' }});
const buffer = await read(__dirname + '/package.json' );
store.get('/cert', { tls: buffer });
};
run();
I was working on getting TLS to work with frame that uses Glue+Manifest+Confidence for configuration management. Having tried both key/cert and pfx pattern and days of debugging, I believe the issue of not having TLS config correctly passed to the underlying node createServer was caused by Confidence when converting the config file.
Although hapi's documentation stated that the tls setting should be directly passed to node using fs.readFileSync, Confidence converted these binary file buffer to a strange format that 1. couldn't be read correctly but compiled and didn't throw error or 2. caused failed to create BIO error. The tricky thing is that the buffer will get half read and I could only debug the tls handshake failure using openssl to pinpoint the issue.
The current workaround of encoding the binary buffer to utf8 would only work with key/cert pattern and not with pfx since the converted string would be too large and node will throw a header too long exception.
In addition, this issue was further covered by node's complete conversion to TLSv1+ and wouldn't throw an error when using a SSLv2-3 key/cert. But this only pertains to my own debugging experience.
The apparent solution would be to create a special case for server.connection.tls and pass it without pre-processing. The root cause however I think would be handling raw buffer in general.
Please see this issue on glue to get a better sense of problem. I originally believed that the issue was caused by glue, but after just doing bare-bones testing, which is use only hapi with Confidence and glue separately, I've come to the conclusion that Confidence caused this issue. You can replicate this issue by simply writing a https server with Confidence and hapi, and read in tls key/cert directly without encoding to utf8.
Thanks!