Extend http request node output for https requests

[mailsvb]

Hi,
as per the contribution guidelines, I would like to raise this topic here.

I would like to suggest to extend the ouput of the http request node, when doing https requests, with the peer certificate information (which is provided in the socket object of the response).

Personally, I have a use case where I want to monitor the lifetime of a certificate, when sending requests to specific servers.

[hardillb]

As a concept it sounds OK.

A couple of things we should probably work out up front would be what exactly would be exposed, where and if it should be optional.

• I think it should be optional, but not sure if it should be toggled in the http-request node or in the tls config node (this is shared with other nodes, but getting server details may apply to other nodes as well, but the implementation of the certificate retrieval would still have to be in each node.)
• An object msg.peerCertificate with the output of TLSSocket.getPeerCertifiate()?

Having said all that a really quick test with the got library we use in the http-request node is not promising

const got = require('got')

got('https://www.hardill.me.uk',{})
.then( res => {
        console.log("good")
        console.log(res.socket.getPeerCertificate())
})
.catch(err => {
        console.log(err)
})

returns null implying that the socket has already been destroyed by the time it's passed to the response handler.

[mailsvb]

My suggestion would be to make it pure optional (not configurable). As you said, it would need to be introduced to all nodes that handle a TLS connection.
We could simply add the object to msg.peerCertificate

In regards to how to get the information at all. I was having success when turning got to use the stream API. This way we get notified on the secureConnect event and can store the certificate data.

const got = require('got')

const g = got('https://www.hardill.me.uk',{ "isStream": true })
g.on('response', res => {
  console.log(res.statusCode)
});
g.on('socket', (socket) => {
  socket.on('secureConnect', () => console.log(socket.getPeerCertificate()))
})
g.on('error', err => {
  console.log(err)
});

[TotallyInformation]

This seems like a fairly specialist need and wouldn't likly be needed by everyone - wouldn't it be better as a separate node?

[mailsvb]

I did this a while ago. I used the http request node as a starting point and created a separate node (node-red-contrib-https - npm). Since then, the http request node has evolved. I like the extended features and options the http request node has received.
IMHO it would be simpler to extend the existing node. Especially, since it is only about information that is anyhow available already.

[mailsvb]

I have created a draft of the proposed changes:

extend http request node