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
Generally speaking, there is some room for refactoring of ssl_client and WiFiClientSecure.
When you look at WiFiClientSecure, you'll see that it simply converts IPAddress to string, passing it to the start_ssl_client function.
Mentioned bug from additonal context has been fixed by #7351 , it will skip host translation logic when it's an IP address, but still some operations are not necessary (redundant string conversions and calls).
Why start_ssl_client uses const char* hostname? I suspect that the idea was to have a proper hostname for certificate validation (parameter of mbedtls_ssl_set_hostname).
The solution is simple - introduce another optional (NULL by default) sslHostname parameter and replace current hostname parameter with IPAddress. You'll then have to translate hostname on your own, but it's not a big deal. It should be done also in WiFiClientSecure.
Added another connect variant in WiFiClientSecure that can take both IP and hostname from the user.
All other connect methods ('higher level') will call that underlying function. Hostname is now translated to IP in WiFiClientSecure, not in ssl_client code.
Related area
WiFiClientSecure
Hardware specification
Any
Is your feature request related to a problem?
The function
uses
host
to resolve the ip and use the it as expected CN. In some cases the CN information is provided by other meansDescribe the solution you'd like
Provide a mean to set the CN when it is different.
Describe alternatives you've considered
No response
Additional context
#7350 is tangentially related.
I have checked existing list of Feature requests and the Contribution Guide
The text was updated successfully, but these errors were encountered: