On Mon, Feb 13, 2023 at 03:07:51PM -0500, Pierre-Luc Boily wrote:
> Indeed, server cert shows "localhost", but it also shows the ip address :
>
> X509v3 Subject Alternative Name:
> DNS:localhost, IP Address:192.168.230.138, IP Address:127.0.0.1
But the client application/library then has to support IP address SANs,
and some don't.
> By the way, the author of the IXWebSocket c++ library told me :
>
> > This might be a high level SSL stuff, where you actually need a real
> > hostname and can't use an IP.
A disturbingly hand-wavy response. If the author does not know how the
library works, perhaps the library is not a good choice. That said, it
does vaguely seem to suggest that IP address SANs are not supported (and
perhaps not even understood by the author).
> But on the other hand, I have a javascript websocket client that can
> connect to my wss server using the same certificate as the c++ client.
That client supports IP address SANs, or simply does not check the SAN
when using IP addresses.
> All of this is for test purposes, eventually, I will use a domain
> name. But as a workaround, I thought to use a fake domain name that
> points to the server IP address. Maybe this will work?
This is not an OpenSSL issue. Take it up the library authors. OpenSSL
supports validating IP address SANs, when the caller supplies an IP
address to check. OpenSSL validates hostnames when the calling
application or library supplies a hostname to check. If the application
supplies a dotted-quad string as a hostname (e.g. "192.0.2.1"), rather than
an IP address, the validation will fail.
https://www.openssl.org/docs/man3.0/man3/SSL_set1_host.html
https://www.openssl.org/docs/man1.1.1/man3/SSL_get0_param.html
https://www.openssl.org/docs/man1.1.1/man3/X509_VERIFY_PARAM_set1_ip.html
In particular here:
param = SSL_get0_param(ssl);
if (X509_VERIFY_PARAM_set1_ip_asc(param, "192.0.2.1") <= 0) {
/* error */
}
...
--
Viktor.
