You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066 #1237
I am using tedious 6.6.2 in one of my projects, it is a GCP cloud function environment, with nodejs 10, and i am getting a warning related to tedious: "severity":"ERROR","message":"(node:6720) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.\n at Object.connect (_tls_wrap.js:1619:15)\n at MessageIO.startTls
Also when i do a node --trace-deprecation it shows another warning: tedious deprecated The default value for config.options.enableArithAbortwill change fromfalsetotruein the next major version oftedious. Set the value to trueorfalse explicitly to silence this message.
What can/should i do about these warnings?
I think the same issue has risen on the mssql library which uses tedious under the hood. According to the last comment, it could be "a universal issue with cloud DB service providers with SSL connections, and not a problem with this library. Would recommend investigating configuration options on the cloud DB service provider."
Edit:
Can you try to use the Host name instead of the IP Address name? (stackoverflow source)
Another potential work around to silence those messages for now is to run NODE_OPTIONS="--no-warnings" node <...file...> (source)
Also I think this is because TLS/SSL doesn't verify IP address, but by DNS domain names. In this case, I guess you need to use a host server name.
I think I found the official explanation from RFC 6066, which states:
Currently, the only server names supported are DNS hostnames;
...
Literal IPv4 and IPv6 addresses are not permitted in "HostName".
It is RECOMMENDED that clients include an extension of type
"server_name" in the client hello whenever they locate a server by a
supported name type.
A server that receives a client hello containing the "server_name"
extension MAY use the information contained in the extension to guide
its selection of an appropriate certificate to return to the client,
and/or other aspects of security policy.
Sorry you're running into this issue, but I don't think this is an error in tedious driver as I've also seen other people post this same error warning when connecting to other databases like MongoDB. I'm not sure how to solve this issue, but I hope I provided some helpful links for further guidance.
Activity
IanChokS commentedon Mar 15, 2021
Is it possible to update to the latest tedious version
11.0.6?pawelusfr commentedon Mar 22, 2021
@IanChokS I'm getting the same warning on 11.0.6
pawelusfr commentedon Mar 22, 2021
Looks like
servernameis being set when callingtls.connecteven though I've set an IP address as server address.IanChokS commentedon Mar 23, 2021
I think the same issue has risen on the
mssqllibrary which usestediousunder the hood. According to the last comment, it could be "a universal issue with cloud DB service providers with SSL connections, and not a problem with this library. Would recommend investigating configuration options on the cloud DB service provider."Edit:
NODE_OPTIONS="--no-warnings" node <...file...>(source)Also I think this is because TLS/SSL doesn't verify IP address, but by DNS domain names. In this case, I guess you need to use a host server name.
IanChokS commentedon Mar 23, 2021
I think I found the official explanation from RFC 6066, which states:
Sorry you're running into this issue, but I don't think this is an error in
tediousdriver as I've also seen other people post this same error warning when connecting to other databases like MongoDB. I'm not sure how to solve this issue, but I hope I provided some helpful links for further guidance.Closing this for now!
fullmooooon commentedon Oct 29, 2021
Change
to
in your code
for example
fix: omit SNI for IP-based hostnames
fix: omit SNI for IP-based hostnames (#1728)