IXWebSocket wss c++ client cannot connect to Node.js wss server using an ip address

[Viktor Dukhovni]

On Thu, Feb 16, 2023 at 02:19:52PM -0500, Pierre-Luc Boily wrote:

> Yep, I read the documentation.  The part "*suppresses support for "*" as
> wildcard pattern in labels* " sounds really like that wildcard is not
> accepted at all.  But I have to admit that I don't know what a "label" is.

A label is a single component of a DNS name, which (in presentation
form) is a sequence of "." separated labels.

> With this flag, only "www.feistyduck.com" and "feistyduck.com" are accepted,

No, not only those, also, for example, "ftp.feistyduck.com",
"smtp.feistyduck.com", "xyzzy.feistyduck.com", ... are accepted, because
they match "*.feistyduck.com".

> it seems useless to me to specify "*.feistyduck.com" in the SAN.

Not useless, but not recommended.  Wildcard and multi-name certificates
degrade security.  Use a separate hostname for each protected service,
and put just one name in the certificate.

> Why not just use "www.feistyduck.com"

That would be the best choice for a certificate for the web service.
But if browsers expect to use either "www.feistyduck.com" or just
"feistyduck.com", that'd be one case where both names in the same
certificate are OK, provided you don't also use "feistyduck.com" for
non-HTTP services, or understand and accept the risk of potential
cross-service security issues.

> If I understand correctly, if i want a more open certificate that
> accept my subdomain, I should use X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS
> but then allowing multi-label wildcards can increase the risk of
> attack I guess.

That flag is not recommended, it goes against standard practice and the
issuance policies of public CAs that don't expect the certificates to
apply to hosts in subdomains.  It could be applicable in closed
networks, where clients connect to only a limited set of hosts and trust
only CAs that issue certificates knowing that wildcards could be
interpreted in a non-standard way.

-- 
    Viktor.