Hello
We have a few Node-Red instances running from AWS cloud
Most runs as a docker in a Fargate instance
One is running on an Ubuntu EC2 VM so we can easily install a couple of things around it
This VM is running NodeRED 3.1.3
Since a couple of days, only on the VM Instance, we get this error from any httprequest:
RequestError: Hostname/IP does not match certificate's altnames: Host: localhost. is not in the cert's altnames: DNS:xxx.xxx.xxx.xxx
and status code: ERR_TLS_CERT_ALTNAME_INVALID
where "xxx.xxx.xxx.xxx" is the domain name of our NodeRed instance
This happens with any url, including for example https://httpbin.org/image/1703030435769_5480a752-9aad-4a7a-af4b-c49719629cbf.jpg
Doing exactly the same in docker based instances, same 3.1.3 version, works as expected
I'm struggling to find what could be the cause.
Is that a config on the VM ? in Node-Red ? on the underlying Ubuntu ?
If I do a curl from a ssh in that VM, I get no error so I would assume more something around Node-RED configuration that got screwed
What is strange is the error is not complaining that the target's certification is wrong but complains about our own DNS name
Any suggestion ?
Thanks
The error is pretty clear. You cannot have a valid certificate for an alt name called "localhost". It isn't allowed since it would be spoofed.
Check the cert you are using for its registered names and use one of those. They will either be publicly routable IP addresses or publicly registered DNS names.
@TotallyInformation
Thanks
so assuming the problem is in the certificate of the machine hosting NodeRED (xxx.xxx.xxx.xxx)
Why does the problem only occurs when the request is made by NodeRed and not from a Curl ?
Also I'm unsure why the host certificate would impact a request to another service
I would understand an error if, in that above example, httpbin.org includes "localhost" in its certificate but here, it is complaining about the DNS of the host making the request, and only if this request is made by Node-RED
Not sure without seeing the details.
But if asked to guess, I'd say that you are trying to offer your cert to the remote (as in client auth) when you don't need to?
Or possibly you just need to turn off certificate checks - which you can only do via a msg property:
Thanks
The TLS box is not checked
Regarding "rejectUnauthorized" it says that it applies to requests to sites that use self-signed certificates. Requests are made to server that have fully qualified certificates.
This is not our case
It is not the remote server's we are requesting which fails.
It is internally our own client's certificate (otherwise it would not be the be host DNS that would be listed)
One difference we found is that the EC2 is using Node v18.12.1 (the one that fails) while the docker has Node v16.20.2
Hmm, not sure then. I'm running v18 and have no problems though I don't run on a VM nor do I use AWS so not saying much.
You may be forced to turn up the logging and may need to turn on the audit log in order to find out exactly where that is coming from.
We found a strange thing
adding in headers of the request : host: xxxx.xxxx.xxx.xxx
makes the problem disapear
I don't understand why adding our own DNS as host solve the things
AFAIK, host should be poart of the HTTP request and should be the same as the server we are targetting. So with the above sample it should be httpbin.org
OK, that implies some kind of proxy or edge security issue. Feels like something at the AWS edge might be checking headers some way.
