As pointed out in my answer to Hostname / IP doesn't match certificate's altname Node.js does successfully verify TLS certificates on host names when the requested host name is given as the Common Name (CN) of the certificate.
Request : localhost
Common Name: localhost
=> Success
Now when I try the same for an IP address, verification fails:
Request : 192.168.178.31
Common Name: 192.168.178.31
=> Fail
It only works if I specify the IP address as Subject Alternative Name (SAN):
Request : 192.168.178.31
Common Name : 192.168.178.31
Subject Alternative Name: 192.168.178.31
=> Success
As described in the answer to IP address as hostname (CN) when creating a certificate? (HTTPS hostname wrong: should be <ipAddress>),
using IP address in certificates is not recommended [...].
As an alternative it is suggested in the answer to How are SSL certificate server names resolved/Can I add alternative names using keytool? to add IP addresses as SANs (which in turn works in Node.js).
Now my question is: Not recommended does not mean wrong or forbidden. Is there any specific reason except being not recommended that Node.js does not support IP addresses in CNs, or why it would be a risk (security, whatever, ...) if it did?
The implementation is merely compliant with the HTTPS specification:
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
When I said "not recommended" in the answer you quote, it was more about using IP addresses in general when using HTTPS. Some browsers let you get away with it, but I also quoted the spec there, which does use the word "must". Needless to say the RFC is more authoritative than any answers you'll find here.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With